后端同事说"接口 50ms 就返回了"，你说"我这边要 3 秒才拿到数据"——然后两人面面相觑，谁也没说错，但问题悬在空中。
这种对话之所以卡住，是因为你们在用"总耗时"对话，而没有把一次请求拆开看。Chrome DevTools 的 Timing tab，就是用来解决这个问题的。
一次 HTTP 请求不是一个黑箱，它有 7 个阶段，每个阶段对应不同的瓶颈归属。
一、一次请求的完整生命周期
打开 DevTools → Network 面板 → 点击任何一个请求 → 切到 Timing 标签页，你会看到这样一条时间线：
Chrome DevTools Timing 标签页，展示一次请求的完整时间分段
从左到右，一次请求走过的路：
| 阶段 | 在干什么 | 谁的锅 |
|---|---|---|
| Queueing | 浏览器排队等待（同域最多 6 个并发） | 浏览器调度 |
| Stalled | 排完队了但还没开跑（等资源分配） | 浏览器/代理 |
| DNS Lookup | 把域名翻译成 IP 地址 | DNS 服务器 |
| Initial Connection | TCP 三次握手 + SSL/TLS 协商 | 网络延迟 + 证书验证 |
| Request Sent | 请求字节从浏览器出发 | 几乎为零 |
| Waiting (TTFB) | 等待服务器返回第一个字节 | 网络往返 + 服务端处理 |
| Content Download | 从第一个字节到最后一个字节全部到达 | 带宽 + 资源体积 |
这就像寄快递的物流追踪：揽收 → 分拣 → 运输 → 派送。快递慢了，你不会直接骂快递员——你会看物流卡在哪个节点。总耗时是结果，分段才是线索。
二、三个最值得关注的阶段
7 个阶段里，日常排查 80% 的问题集中在这三个：
Initial Connection — 连接成本
这一段包含 TCP 握手和 SSL/TLS 协商。对于首次访问且没有连接复用的请求，这个数字可能高达 100-300ms（跨国甚至更多）。
如果这里很长：
• 服务器物理距离远 → 上 CDN
• 每次请求都在重新建连 → 确认 HTTP/2 连接复用生效
• 提前建连：<link rel="preconnect" href="https://api.example.com">
Waiting (TTFB) — 最被误解的指标
TTFB 的全称是 Time To First Byte——从请求发出到收到第一个字节的时间。
很多人以为 TTFB 就等于"后端处理时间"，但它其实是一个组合信号：
TTFB = 网络往返时间（RTT） + 服务器处理时间
如果 TTFB 高，不要立刻甩锅给后端。先看 Initial Connection——如果连接阶段也很长，说明网络延迟本身就高，TTFB 里有一大截是"路上耗时"而非"后端处理时间"。
Google 的建议阈值：
• ✅ ≤ 800ms（良好）
• ⚠️ 800ms ~ 1.8s（需改进）
• ❌ > 1.8s（不良）
Content Download — 资源体积的照妖镜
如果 TTFB 很短但 Content Download 很长——恭喜，问题清晰：资源太大或网络太慢。
对策：开启 gzip/brotli 压缩、图片走 WebP/AVIF、代码分割减小 JS 包体积。
记住这条判断链：TTFB 高 → 查服务端或网络延迟；Content Download 高 → 查资源体积或带宽。两者都低但总时间长 → 查排队和连接阶段。
三、Waterfall 瀑布图：全局视角
Timing tab 看的是单个请求，而 Waterfall 列看的是所有请求的时间关系。
Network 面板的 Waterfall 列，展示请求的时间线全貌
| 视觉特征 | 含义 |
|---|---|
| 条形位置（左右） | 请求发起的时间点 |
| 浅色部分 | 等待时间（排队 + 连接 + TTFB） |
| 深色部分 | 实际下载字节的时间 |
| 多条请求"阶梯式"排列 | 串行阻塞，可能有依赖链 |
| 多条请求"重叠"排列 | 并行下载，正常现象 |
将鼠标悬停到任意条形上，可以快速预览时间分段：
悬停 Waterfall 条形，预览请求的 Timing 分段数据
排查技巧：先按"总时长"排序找出最慢的请求，再点进 Timing tab 看慢在哪个阶段。这比盲目看瀑布图高效得多。
四、一张排查决策表
下次遇到"接口慢"，按这张表走：
| 你看到的现象 | 瓶颈归属 | 行动 |
|---|---|---|
| Queueing/Stalled 很长 | 并发连接打满 | 升级 HTTP/2；延迟非关键请求；用 preconnect |
| DNS Lookup 很长 | DNS 解析慢 | <link rel="dns-prefetch">；减少跨域数量 |
| Initial Connection 很长 | TCP/SSL 握手慢 | CDN；preconnect；确认 HTTP/2；升级 TLS 1.3 |
| TTFB 很长 + Connection 短 | 服务端处理慢 | 优化后端（DB 查询、缓存、减少重定向） |
| TTFB 很长 + Connection 也长 | 网络延迟高 | CDN 就近节点；减少重定向跳数 |
| Content Download 很长 | 资源太大 / 带宽不足 | gzip/brotli；图片优化；代码分割 |
五、三个实战技巧
1. 模拟真实用户网络
Network 面板顶部有网络节流（Throttling）下拉框。把网络切到 "Slow 3G"，你会发现平时看不见的 Timing 问题全部暴露出来。
2. 勾选 Disable Cache
不禁用缓存看到的 Timing 是"最理想情况"——DNS 被缓存、连接被复用。勾上 Disable cache 才是首次访问用户的真实体验。
3. 用 isSecureContext + Timing API 做线上监控
// 在线上代码中采集真实 TTFB
new PerformanceObserver((list) => {
const nav = list.getEntriesByType('navigation')[0];
const ttfb = nav.responseStart; // 毫秒
// 上报到你的监控系统
reportMetric('ttfb', ttfb);
}).observe({ type: 'navigation', buffered: true });
DevTools 是本地排查工具，但线上用户的网络环境千差万别。真正的性能优化需要实验室数据 + 真实用户数据双线并行。
六、思维转变：从"感觉慢"到"哪段慢"
很多前端遇到性能问题的第一反应是"后端接口慢"或"我代码写得太重了"——这都是在猜。
水管漏水时，工程师不会挖开整条路查，而是分段测水压，找到压力骤降的那一截。Timing tab 就是你的"分段水压计"。
性能排查的核心能力不是"发现慢"——谁都能发现慢。核心能力是"定位慢在哪一段"，然后给出对应的优化手段。
如果你只想带走一句话，我建议记这个：
看到请求慢，不要直接下结论。先打开 Timing tab，把 7 段时间看清楚——连接慢、等待慢、下载慢，是三个完全不同的问题，对应三套完全不同的解法。
参考原文：
• Chrome for Developers — Network features reference
• web.dev — Time to First Byte (TTFB)
