DevTools Waterfall 与 Timing
Waterfall 与 Timing 用来拆解单个请求和整批资源的耗时分布，判断慢在排队、连接、等待还是下载。
#concept
#growing
#frontend
#browser
#chrome-devtools
[!info] related notes
- 所属 MOC: DevTools Network MOC
- 前置概念: Network 面板
- 并列概念: 请求与响应检查, Performance 面板
- 关系笔记: 首字节时间 TTFB, 页面加载性能排查
DevTools Waterfall 与 Timing
一句话定义
Waterfall 与 Timing 用来回答“这次请求到底慢在链路哪一段”。
核心内容
典型耗时区段
- Queueing / Stalled
- DNS / Initial connection
- Request sent
- Waiting (TTFB)
- Content download
适合处理的问题
- 首屏慢到底是哪个资源拖住了
- 接口慢是服务器慢还是下载慢
- 是不是连接复用、并发限制或排队导致的延迟
边界与易混淆点
- 单个请求慢不一定就是整体体验慢，要放回整体 Waterfall 看关键路径
- Waiting 很长通常指服务端或上游慢，但也可能是代理链路、缓存策略或队首阻塞
学习检查
不看正文回答：
- Queueing/Stalled、DNS、Initial connection、SSL、Request sent、Waiting(TTFB)、Content Download 分别意味着什么？
- 为什么 TTFB 很长不能直接推出“数据库慢”？
- 同一 origin 大量请求排队时，应该先考虑协议/连接限制还是 JavaScript 执行？
- cache hit 为什么可能让 Timing 中很多网络阶段直接消失？
- Waterfall 能证明网络时间分布，但为什么不能单独证明后端内部哪个函数慢？
- 给一个“DNS 很快、TTFB 2s、下载 20ms”的请求，列出下一步应收集的服务端证据。
Digital Biome