前端性能优化知识地图

前端性能优化知识地图

1. 性能优化先回答什么

性能优化不是把所有技巧都应用一遍，而是用可复现的证据降低某个用户路径的成本。一个完整的回答应包含：

1. 用户路径：首屏、搜索、列表滚动、编辑器输入，还是提交/支付。
2. 问题信号：哪个指标、哪个设备和网络、哪个版本发生了退化。
3. 原因定位：网络等待、主线程长任务、布局/绘制、内存增长或构建产物。
4. 改动与权衡：采用什么手段，是否增加请求、内存、复杂度或一致性风险。
5. 验证与回滚：实验条件、对照组、现场数据和失败时的恢复方式。

不要用“加载快了很多”替代基线。至少保留版本、页面、设备/网络、样本量、P75/P95 和优化前后值。

2. 学习和排查顺序

用户感知
  -> 字段指标（RUM）与实验指标（Lighthouse/DevTools）
  -> 网络与资源关键路径
  -> 主线程、布局、绘制和内存
  -> 框架更新边界
  -> 构建产物、依赖与发布治理

阶段	要回答的问题	进入专题
指标与诊断	用户在哪里感到慢？证据如何采集？	指标与诊断
网络与资源	请求、缓存、压缩和关键资源是否合理？	网络与资源加载
渲染与运行时	主线程为何阻塞、掉帧或内存上涨？	渲染与运行时
框架	哪些组件/状态被不必要地更新？	React 与 Vue
构建治理	首屏包、依赖和 CI 构建如何持续受控？	体积与性能治理

3. 指标口径

3.1 Core Web Vitals

截至目前，Core Web Vitals 主要关注加载、交互和视觉稳定性：

指标	含义	良好（通常看 P75）	说明
LCP	最大内容绘制	<= 2.5s	首屏主要内容何时可见
INP	交互到下一次绘制的延迟	<= 200ms	已取代 FID，更能覆盖整个页面生命周期
CLS	累积布局偏移	<= 0.1	衡量无预期的视觉跳动

阈值是分析分段的参考，不是所有业务的硬性 SLO。表单、图表和低端设备场景可能需要单独定义预算。

3.2 辅助指标

• FP/FCP：第一次绘制/第一次内容绘制，适合观察白屏和早期内容反馈。
• TTFB：从请求开始到收到响应首字节，包含连接、服务端处理和网络传输等阶段；它是诊断信号，不单独代表页面可用。
• TBT：实验室环境中长任务阻塞主线程的总时间，常用于 Lighthouse；它不是现场用户的 INP。
• TTI：历史上的“可交互时间”指标，在现代评估中不再是 Core Web Vital，阅读旧资料时要和 INP、TBT 区分。
• 资源耗时：DNS、连接、TLS、请求等待、下载、解码和执行；可用于定位瀑布图中的瓶颈。
• 业务指标：搜索完成率、表单提交成功率、错误率、任务完成时间。性能改动最终应能解释对业务路径的影响。

3.3 P75、实验室和现场

同一页面在高速桌面网络和低端移动设备上的结果可能完全不同：

1. 实验室（Lab）：固定设备、CPU 限制和网络，便于回归和定位，但不能代表全部用户。
2. 现场（Field/RUM）：真实设备、网络、地区和版本，适合 SLO 和发布监控，但要处理采样、隐私和数据偏差。
3. 分位数：平均值会掩盖慢用户；通常查看 P75，事故或极端长尾再看 P95/P99。
4. 分组：至少按路由、版本、设备类别、网络类型和地区切分，避免把不同人群混在一起。

4. 优化闭环

建立基线 -> 找到最慢路径 -> 录制/采集证据 -> 提出最小改动
    -> 对照验证 -> 灰度观察 -> 固化预算、告警和回滚

4.1 建立基线

记录以下信息后再动手：

• 提交版本和构建配置；
• 页面 URL、入口操作和数据规模；
• 浏览器版本、视口、CPU/内存限制；
• 网络延迟、吞吐、缓存状态；
• LCP/INP/CLS、FCP/TTFB、首屏 JS/CSS/图片字节数；
• 主线程长任务、请求瀑布、堆快照或录制文件。

4.2 选择工具

目标	工具	证据
请求和缓存	DevTools Network、Resource Timing	请求状态、优先级、瀑布、缓存命中
渲染和交互	DevTools Performance、Long Tasks、Event Timing	主线程火焰图、帧、布局/绘制、交互延迟
页面评分	Lighthouse 或 CI Lighthouse	受控环境中的指标和建议
现场数据	PerformanceObserver、web-vitals、RUM SDK	按版本和人群聚合的 P75/P95
产物	Source Map Explorer、webpack-bundle-analyzer、Rollup visualizer	chunk、重复依赖、模块来源
内存	Memory 面板、Heap Snapshot	detached DOM、监听器、闭包和增长曲线

工具输出是线索，不是原因本身。比如 Lighthouse 报告“减少未使用 JavaScript”，仍需在 bundle 分析和运行时录制中确认是哪一段代码、哪些用户路径受益。

5. 常见错误

5.1 只背阈值，不说测量条件

“LCP 小于 2.5 秒”必须说明是哪个页面、哪个版本、哪个分位数和哪类用户。否则数字不能比较。

5.2 把单一技巧当万能药

• React.memo 不能修复昂贵计算、错误的状态所有权或过大的 Context；
• preload 会提高资源优先级，预加载错误资源反而会抢占关键请求；
• will-change 和 translateZ(0) 会创建图层，滥用会增加 GPU/内存压力；
• 合并文件在 HTTP/2/HTTP/3 下不必然更快，缓存粒度和请求并发要一起衡量；
• 删除“未使用依赖”的正则脚本可能漏掉动态导入、插件配置、CLI 和副作用。

5.3 只在本地验证

本地开发环境通常没有真实 CDN、缓存、第三方脚本、低端设备和发布版本差异。优化完成后，应把关键指标和错误率接入现场监控，并为超预算设置告警。

6. 本项目的阅读建议

1. 先看本文，建立指标和证据口径。
2. 顺着指标与诊断学会从瀑布图、火焰图和 Performance Entry 定位问题。
3. 再看网络与资源加载和渲染与运行时。
4. 需要回答框架面试题时，阅读React 与 Vue 运行时优化。
5. 最后用体积与性能治理把一次性优化变成发布流程。

相关既有专题：CSS 性能优化、JavaScript 加载机制、前端监控 SDK 设计。

7. 资料来源与取舍

本篇综合 前端性能优化（上）.pdf、前端性能优化（下）.pdf 和 前端性能优化详解.pdf 中关于用户感知、指标、工具和优化闭环的技术部分。课程推广、机构信息、薪资案例和无法复核的收益百分比未纳入；旧资料中的 FID/TTI 以当前 INP 口径补充说明。