[!info] related notes

• 所属 MOC: DevTools Performance MOC
• 指标体系: 性能指标体系
• Lighthouse: Lighthouse
• 专项: Layout Shift 调试, 长任务调试

DevTools Web Vitals 调试

先分清指标与根因

LCP / CLS / INP
= user-centric symptoms / metrics

resource / JS / layout / rendering / server
= possible root causes

指标告诉你哪类用户体验慢，不直接告诉你哪行代码错。

LCP 调试

先确认：

• 哪个元素成为 LCP candidate/final LCP；
• 它什么时候被发现；
• 资源什么时候开始/完成；
• render 是否被 CSS/JS/主线程阻塞；
• TTFB 是否已经很高。

不要看到 LCP 慢就默认“图片太大”。

CLS 调试

转到 Layout Shift 事件与 screenshots：

• 哪次 shift 贡献最大；
• 哪些元素发生移动；
• 是加载期还是交互期；
• 根因是尺寸缺失、动态插入、字体还是布局逻辑。

详见 Layout Shift 调试。

INP 调试

找到慢 interaction 后，把延迟拆成：

input delay
→ event processing
→ presentation delay

再看是否由：

• 主线程繁忙；
• event handler 太重；
• render/layout/paint 太重；
• 同步第三方工作；

主导。

Lighthouse 与 Performance 的关系

Lighthouse 适合给出实验室评估与问题入口。

Performance 更适合沿时间线解释：

这个指标为什么在这次运行里变差。

不要把 Lighthouse suggestion 本身当作根因证明。

Lab 与 Field 的边界

本机 DevTools trace 只是实验室样本。

真实用户可能有不同：

• device；
• network；
• cache state；
• geography；
• session length；
• interaction pattern。

因此重要产品最终仍应结合 RUM / field data。

迁移检查

给三个场景：

A. LCP 4s。
B. CLS 0.3。
C. 某按钮 INP 很差。

分别回答：

1. 在 DevTools 首先找哪类证据；
2. 为什么指标本身不是根因；
3. 哪一种需要进一步看 Network，哪一种需要 Layout Shift，哪一种需要 Long Task/Flame Chart；
4. 为什么实验室修好后还需要 field validation。