页面加载性能排查
从 Navigation/TTFB、关键资源发现与下载、主线程执行、渲染关键路径到 LCP/首屏呈现分层排查页面加载慢，要求用 Network 与 Performance 证据定位真正瓶颈。
#debug
#growing
#frontend
#browser
[!info] related notes
- 所属 MOC: 浏览器开发者工具 MOC, 前端性能优化 MOC
- 工具: Network 面板, Performance 面板, Lighthouse
- 指标: 性能指标体系, LCP
- 相关: 关键路径优化, Resource Hints
页面加载性能排查
症状先具体化
“页面加载慢”至少可能是：
- 首字节慢；
- HTML 快但 JS/CSS 下载慢；
- 资源下载完成但主线程长期忙；
- LCP 资源发现太晚；
- 页面已可见但 hydration/交互很晚；
- 只有弱网/弱机慢。
先明确用户感知的是哪一种。
第一层：Navigation / TTFB
用 Network 的 document request 看：
- DNS / connection / TLS；
- request sent；
- Waiting / TTFB；
- content download。
如果 TTFB 已经占绝大部分时间，前端 bundle 优化不是第一优先级。
继续结合服务器 trace、CDN/cache、后端依赖判断。
第二层：关键资源发现与下载
检查：
- render-blocking CSS；
- JS bundle 数量和体积；
- LCP 图片/字体什么时候被发现；
- request priority；
- 是否有串行依赖；
- cache hit/miss；
- third-party origin connection。
需要时再考虑 preload/modulepreload/preconnect，而不是先盲加 Resource Hints。
第三层：主线程执行
资源下载完并不代表页面会立刻显示。
Performance 中检查：
- parse/compile/execute JS；
- Long Tasks；
- framework initialization；
- hydration；
- layout/paint。
如果 JS 执行 1.5s，继续减 20KB 图片通常不是主矛盾。
第四层：LCP / 首屏元素
找到实际 LCP element，问：
- 什么时候知道它存在？
- 资源什么时候开始下载？
- 下载慢还是开始太晚？
- 下载完成后为什么还没 paint？
这比只看最终 LCP 数字更可行动。
第五层：真实设备与缓存状态
本地开发机很快并不能代表用户。
用：
- CPU throttling；
- Network throttling；
- cold/warm cache 对照；
- field/RUM data；
验证问题是否只存在于弱机、弱网、特定地域或首次访问。
证据矩阵
| 证据 | 优先方向 |
|---|---|
| Document TTFB 高 | CDN / server / backend |
| CSS/JS waterfall 长 | resource delivery / bundling / cache |
| Network 已完成但首屏晚 | main thread / render |
| LCP request 很晚才开始 | discovery / priority |
| 本机快、低端机慢 | CPU / JS / rendering |
| 首访慢、二访快 | cache / cold path |
修复后复测
使用相同：
- URL；
- device/network condition；
- cache state；
- interaction/measurement window；
重新录制。
否则前后对比没有意义。
迁移检查
场景：LCP 4.5s，Network 显示 HTML TTFB 200ms、LCP 图片 300KB，但图片直到 2.8s 才开始请求。
不看正文：
- 为什么不应首先压缩后端响应时间？
- 为什么只压图片大小也可能收益有限？
- 应优先检查哪些资源发现/优先级链路？
- 怎样用修复后的 waterfall 证明问题真的解决？
Digital Biome