Chrome DevTools Network按请求阻塞原因定位加载变慢

页面“加载慢”时，先别急着把锅甩给服务器。打开 Chrome DevTools 的 Network 面板，选中 Waterfall 中总耗时最长、又影响首屏或关键交互的请求，再进入 Timing 拆分 Queueing、DNS Lookup、Initial connection、Waiting (TTFB) 和 Content Download，通常就能把体感问题落到一个可处理的阶段。

官方地址：https://developer.chrome.com/docs/devtools/network/

先建立一轮可复现的 Network 记录

打开目标页面，按 F12 或右键选择“检查”，进入顶部的 Network。点击清空按钮删除旧记录，再刷新页面。若要观察完整跳转链路，可勾选 Preserve log；若要减少缓存命中对结果的影响，可在 Network 面板中勾选 Disable cache，但它只在 DevTools 打开时生效。

1. 确认左上角录制圆点处于启用状态。
2. 点击清空，再执行一次页面刷新或触发目标操作。
3. 在筛选框输入接口名、文件名或 Fetch/XHR 类型，缩小候选范围。

成功的可见标志是：请求表从同一轮操作开始出现，状态码、Size、Time 和 Waterfall 均有值。不要把旧请求和新请求混在一起比较。

用 Waterfall 先锁定真正拖慢页面的请求

先看请求表的 Time，再看右侧 Waterfall。长时间不一定等于服务器慢：一条请求可能在浏览器排队很久，另一条则是响应体很大。优先选择总耗时长、会影响关键渲染或用户操作的请求，并记下 Name、Status、Size、Time 和 Initiator。

例如图中的 api/orders 虽然返回 200，但总耗时为 1.84 秒，等待段明显长于下载段。这只能说明“它值得看”，还不能直接证明是后端代码问题，下一步必须打开 Timing。

在 Timing 面板拆分 DNS、连接、TTFB 与下载

单击请求名称，切换到右侧详情中的 Timing。Chrome DevTools 会把请求拆成多个阶段，读取方法如下：

如果 Waiting (TTFB) 占大头，先把请求时间、服务端日志和数据库耗时对齐；如果 Content Download 长，检查响应是否返回了不必要字段、是否能压缩或分页。DNS 和连接阶段偶发变长时，先用同一网络条件多测几次，避免把一次代理抖动当成稳定结论。

结合 Initiator 判断是谁触发了慢请求

在请求详情中查看 Initiator，它能帮助你判断请求来自 HTML 解析器、脚本还是重定向。再结合 Headers 的请求 URL、缓存状态与响应头，以及 Preview 或 Response 的返回结构，区分三种常见情况：

• 接口本身慢：同一请求多次复测仍是 TTFB 长，且响应体并不大。
• 资源传输慢：下载阶段长，Size 明显偏大，压缩或拆分可能更有效。
• 触发顺序不合理：请求由某个脚本串行触发，前一个请求完成后才开始，Waterfall 会呈现明显的接力排列。

这里的验收点不是“看到了红色或黄色提示”，而是能说清楚哪个请求、哪个阶段、由哪个 Initiator 触发，以及下一步由谁处理。

按主导阶段选择修正动作并复测

完成一次修正后，回到相同页面和相同操作，重新清空记录并复测。可以用下面的清单避免只凭体感下结论：

• 排队长：减少同一时刻无关资源，检查请求优先级与并发竞争。
• DNS 或连接长：检查域名解析、代理和连接复用；不要只改接口代码。
• TTFB 长：把服务端日志、数据库查询和上游调用按请求 ID 对齐。
• 下载长：比较 Size，考虑压缩、分页、字段裁剪和缓存策略。

建议记录一行简短结果：api/orders | 200 | 48 KB | 1.84 s → 0.62 s | TTFB 680 ms → 210 ms。如果要交给其他同事，可从 Network 导出 HAR，但先确认其中没有 Cookie、授权头或业务敏感数据。

常见问题

Time 很长就一定是服务器慢吗？

不一定。Time 是从请求开始到收到最后一个字节的总时长，排队、DNS、连接、TTFB 和下载任一阶段都可能贡献时间，必须看 Timing。

为什么同一个请求每次 Timing 不一样？

缓存、连接复用、代理、网络波动和服务端负载都会影响分段耗时。固定测试页面和操作，多次记录同一请求，再看稳定的主导阶段。

TTFB 低但页面仍然慢，下一步看哪里？

检查 Content Download、Initiator 以及请求之间是否串行；如果 Network 并不慢，再转到 Performance 面板分析主线程和渲染任务。

Chrome DevTools Network 的价值不在于给出一个“慢”字，而在于把慢拆成可行动的阶段。先用 Waterfall 选请求，再用 Timing 定位阶段，最后用 Initiator 和复测数据确认修正是否真的生效。