Web 性能分析与优化关注用户何时看到内容、能否及时交互，以及布局是否稳定。优化应先测量，再根据瓶颈选择措施。
用户指标与实验室测量
截至 2026 年 10 月，Core Web Vitals 包括 LCP、INP 和 CLS，分别衡量主要内容加载、交互响应和视觉稳定性。良好阈值分别为不高于 2.5 秒、200 毫秒和 0.1，通常以实际访问的第 75 百分位评估，并区分移动与桌面。
实验室测试适合复现与定位，真实用户数据用于观察实际设备和网络分布。单次本机测试不能代表全部用户，也不能用某个综合分数代替具体问题分析。
参考：Web Vitals 官方说明。
从瀑布图到主线程
首屏慢可能来自重定向、服务端等待、关键资源发现过晚、下载体积、脚本执行或渲染工作。接口已经返回也可能因长任务而无法及时显示。
经验上，先固定页面、设备和网络条件，记录基线；再检查 Network 与 Performance 中的时间线，选定占主要成本的阶段。修改后使用相同场景比较，同时检查交互和视觉稳定性是否退化。
常见措施及边界
以下为结合瓶颈选择的实践建议：
- 图片采用合适尺寸和编码，预留展示空间；首屏关键图片不宜盲目延迟加载。
- 代码按用户路径延迟加载，减少首屏无用工作，同时关注后续请求瀑布。
- 长列表可分页或虚拟化；虚拟化减少 DOM 数量，但不会自动减少下载的数据量，并需处理焦点与可访问性。
- DOM 读取与写入尽量分批，避免交错操作造成强制同步布局。
- 组件缓存与记忆化应基于测量，稳定引用本身不等于用户体验改善。
内存泄漏
内存持续增长需要结合重复操作、垃圾回收后的保留量与引用链判断，不能只看某个瞬间的总占用。堆快照和分配记录可帮助找到仍被持有的对象。
典型排查对象包括未取消的定时器、长期存在的全局事件监听、无界缓存和被引用的脱离文档 DOM。闭包本身不是泄漏；问题在于无需保留的数据仍然可达。
CSR、SSR 与 hydration
CSR 主要在客户端生成界面；SSR 在服务端生成 HTML，客户端再通过 hydration 接管交互。SSR 可能改善内容呈现与抓取条件，但仍有服务端成本及客户端脚本成本，不保证交互一定更快。
服务端与客户端首次渲染需保持可匹配的结构与数据；随机值、时区差异或仅浏览器可用的状态可能造成 hydration 不匹配。服务端请求之间还必须隔离用户状态，避免跨请求污染。
参考：Vue 官方 SSR 指南。