关键是要拆分网络与本地耗时：Network面板Timing标签显示DNS、TCP、TLS、TTFB、下载等网络阶段；Performance面板火焰图分析Loading、Scripting、Rendering、Painting等本地处理；TTFB与FCP/LCP时间差反映本地工作量；Navigation Timing API可编程获取各阶段精确耗时。
要区分网络加载耗时和本地处理耗时，关键不是看“总时间”，而是拆开浏览器实际执行的每个环节——网络请求阶段（DNS、TCP、TLS、TTFB、下载）和本地阶段（解析、脚本执行、样式计算、布局、绘制）各自独立可测。
看 Network 面板里的 Timing 标签
在 Chrome 开发者工具 Network 面板中点击任意资源，打开 Timing 标签页，就能清晰看到网络链路各阶段耗时：
- DNS Lookup：纯域名解析，不涉及本地 JS 或 CSS 处理
- Initial connection 和 SSL：建立 TCP 和加密连接，属于网络往返，与页面逻辑无关
- Waiting (TTFB)：从请求发出到收到第一个字节，反映后端响应速度，仍是网络侧指标
- Content Download：带宽受限下的文件传输时间，也属网络范畴
用 Performance 面板定位本地处理瓶颈
Network 只管“拿到数据”，Performance 面板才告诉你“拿到后干了什么”：
- 选中一段页面加载时间段，查看下方火焰图中的颜色区块：Loading（HTML 解析）、Scripting（JS 执行）、Rendering（样式+布局）、Painting（绘制）
- 若 Scripting 占比高，说明 JS 初始化、框架挂载或大量计算拖慢了渲染
- 若 Rendering 持续卡顿，可能是强制同步布局（如读取 offsetHeight 后立即改 style）、过多重排重绘
- Idle 时间少、持续满载，往往意味着主线程被长任务阻塞，需拆分或移交 Web Worker
结合 TTFB 与 FCP/LCP 判断问题归属
首字节时间（TTFB）和首次内容绘制（FCP）、最大内容绘制（LCP）之间的时间差，基本就是本地处理耗时的窗口：
- TTFB 200ms + FCP 1200ms → 中间约 1s 是 HTML 解析、CSS 计算、JS 执行、布局绘制等本地工作
- 如果 TTFB 正常（ 3s，问题大概率出在资源解码（大图未压缩）、JS 执行阻塞、字体加载延迟或渲染路径过长
- 反之，若 TTFB > 2s，即使本地处理很快，用户感知仍是“页面打不开”，这时优化重心应在服务端、CDN 或 API 层
用 Navigation Timing API 做自动化归因
在代码中调用 performance.getEntriesByType('navigation')，可程序化提取各阶段精确毫秒值：
-
connectStart到responseEnd：覆盖 DNS、TCP、TLS、TTFB、下载 → 网络总耗时 -
domContentLoadedEventStart减responseEnd：HTML 解析 + 内联脚本执行 → 关键本地处理起点 -
loadEventStart减domContentLoadedEventStart：外部资源加载与执行 → 易被忽视的 JS/CSS 延迟点
