前端性能定位 Playbook：从指标到归因

一句话结论：建立一套从核心指标（LCP/INP/CLS）异常发现，到使用 Profiling 工具（React Profiler/Performance/Network）层层钻取，最终定位到具体代码或资源问题的标准化流程，是保障前端性能的系统性方法。

1. 核心性能指标 (The Metrics)

不要陷入指标的汪洋大海。对于现代 Web 应用，关注 Google 的 Core Web Vitals 和其他关键指标就足够了。

指标关系：TTFB → FCP → LCP。TTFB 是所有加载指标的起点。INP 则独立衡量交互后的响应能力。

2. 定位工具箱 (The Profiling Tools)

有了指标，下一步就是用正确的工具来定位问题。

1. React Profiler (DevTools)
   • 用途：专门分析 React 组件的渲染性能。找出哪个组件渲染耗时过长，以及哪些组件发生了不必要的重渲染。
   • 何时使用：当怀疑 INP 问题、UI 卡顿或交互响应慢时。
   • 关键视图：
     • 火焰图 (Flamegraph)：可视化渲染耗时，宽的条形代表耗时长的组件。
     • 排行榜 (Ranked Chart)：按渲染耗时对组件进行排序，快速找到瓶颈。
     • "Why did this render?"：勾选此项，可以看到每次 commit 中组件重渲染的原因（props/state/hooks 变化）。
2. Chrome Performance Panel (DevTools)
   • 用途：最强大的性能分析工具，提供对浏览器主线程活动的全面洞察。
   • 何时使用：分析 INP、长任务、动画掉帧和页面加载全过程。
   • 关键部分：
     • Main Thread 轨道：核心区域。寻找红色的长条，即长任务 (Long Tasks)。点击长任务，可以在下方的 Bottom-Up 标签页中看到任务耗时的具体归因（哪个函数调用、脚本执行等）。
     • Timings 轨道：显示 LCP, FCP, DCL 等关键指标的时间点。
     • Network 轨道：查看资源加载瀑布流。
3. Chrome Network Panel (DevTools)
   • 用途：分析所有网络请求，包括资源加载速度、大小、优先级和时序。
   • 何时使用：分析 LCP、TTFB 慢，或页面整体加载慢的问题。
   • 关键检查点：
     • 瀑布图 (Waterfall)：是否存在请求链过长？是否有并行度不足的问题？
     • Size 列：资源是否过大？是否启用了 Gzip/Brotli 压缩？
     • Time 列：TTFB 是否过高？（服务器问题）Content Download 时间是否过长？（资源大或网络差）

3. 性能定位 Playbook (The Workflow)

这套流程旨在将“感觉慢”变成可量化、可归因的问题。

Playbook 1: 分析慢 LCP

1. 识别最大内容元素：
   • 在 Performance 面板中，找到 Timings 轨道的 LCP 标记。
   • 将鼠标悬停在上面，浏览器会高亮显示对应的元素。
2. 分析 LCP 资源加载：
   • 如果是图片：去 Network 面板找到该图片的请求。
     • 检查大小：是否过大？是否可以压缩或使用 WebP 格式？
     • 检查优先级：是否因为其他资源阻塞导致加载延迟？是否需要使用 fetchpriority="high" 提升优先级？
     • 检查时序：请求是否过晚发起？（例如，由某个 JS 逻辑触发）
   • 如果是文本：通常与字体文件加载（Web Font）有关。
     • 检查字体文件是否过大，是否阻塞了文本渲染（FOIT）。考虑使用 font-display: swap。
3. 分析渲染路径：
   • 查看 LCP 资源请求前的瀑布流。是否存在阻塞渲染的 CSS 或 JS？（<link rel="stylesheet"> 和 <script> 默认阻塞）
   • 考虑异步加载非关键 CSS/JS。
4. 检查 TTFB：
   • 在 Network 面板查看主文档的 TTFB。如果过高，说明是服务器端瓶颈，需要后端或运维介入。

Playbook 2: 分析高 INP

1. 复现慢交互：
   • 打开 Performance 面板，点击录制。
   • 执行导致卡顿的用户操作（例如，在输入框中打字、点击一个复杂的按钮）。
   • 停止录制。
2. 寻找长任务：
   • 在 Main Thread 轨道中，寻找与你交互时间点对应的红色长任务。所有超过 50ms 的任务都是长任务。
3. 归因长任务：
   • 点击该长任务。
   • 查看下方的 Bottom-Up 或 Call Tree 标签页。这里会列出该任务中所有函数的耗时排行。
   • 通常你会发现是某个事件处理函数（Event: click）、定时器 (Timer Fired) 或 React 渲染周期 (Perform work on root) 占用了大量时间。
4. 深入 React Profiler：
   • 如果 Performance 面板指向 React 的渲染过程，下一步就是使用 React Profiler。
   • 重复上述操作，但在 React Profiler 中录制。
   • 查看火焰图/排行榜，找到渲染最慢的组件。
   • 分析 "Why did this render?"，检查是否存在不必要的重渲染。常见的元凶是：
     • 传递了新的对象/函数字面量作为 props。
     • Context 的值发生变化，导致所有消费者重渲染。
     • 状态设计不佳，一个微小的变化导致整个组件树刷新。
5. 优化：
   • 根据原因进行优化：使用 useMemo/useCallback、拆分组件、优化 Context、对长列表进行虚拟化等。

4. 观测与验证 (Observability)

• 本地开发：使用 DevTools 进行即时分析和验证。
• 线上监控：集成真实用户监控 (RUM) 工具，如 Sentry, Datadog, Vercel Analytics 等。这些工具会收集真实用户的 Core Web Vitals 数据，并与版本、地域、设备等维度关联，让你能发现开发环境中未曾预料到的性能问题。
• 性能预算：在 CI/CD 流程中集成 Lighthouse 或其他工具，设置性能预算（例如，LCP < 2.5s, JS bundle < 200KB）。如果 MR 超出预算，则阻塞合并，强制开发者在上线前解决性能问题。

5. 关联阅读

• React Profiler 官方文档: Profiling React Apps
• Google Web Vitals: web.dev/vitals
• 渲染优化: (指向 notes/14/02-rendering-optimization.md 的链接)