Chrome DevTools Network Throttling 能真实暴露弱网下资源加载、阻塞与超时全过程，关键在于正确启用（强制刷新+禁用缓存）并精准解读 Waterfall 中 Stalled/TTFB 阶段，结合 Performance 面板定位渲染或执行瓶颈。
直接用 Chrome DevTools 的 Network Throttling 功能就能排查，关键不是“开了没”，而是“开得对不对、看得准不准”。它本身不改代码，但能暴露真实弱网下资源加载、阻塞、超时的全过程。
先确保节流真正生效
很多人点了 Slow 3G 却没看到 JS 加载变慢，问题往往出在三处：
- 没刷新页面：节流只影响启用后发出的新请求，已加载的资源不受限，必须按 Ctrl+R / Cmd+R 强制刷新；
- 缓存没关：勾选 Network 面板顶部的 Disable cache，否则浏览器从内存或磁盘直接返回 JS，根本走不到网络层；
- Waterfall 没看对地方：重点盯每个 JS 请求的 Stalled 和 Waiting (TTFB) 时间——这两个阶段拉长了，才说明节流起效；光看总耗时可能被缓存或本地执行掩盖。
用预设档位快速定位典型瓶颈
Chrome 内置的 Slow 3G（1.6 Mbps 下行、150 ms RTT）最贴近城市移动弱网。启用后刷新，重点关注：
Wjs Uploading Video
下载
将一个或多个视频上传至YouTube。当用户想“上传到YouTube”“发YouTube”“批量上传”“upload to YouTube”“post videos to YouTube”或发布到YouTube时使用此技能。
-
首屏 JS/CSS 是否 render-blocking：如果 main.js 加载完才开始渲染，且它体积大、没加
async或defer，Waterfall 里会看到后续 HTML 解析长时间挂起； -
字体或第三方脚本是否拖垮 TTFB：比如跨域字体 CSS 含
@import，或统计 SDK 在 slow-3g 下首字节等待超 3s，直接卡住 CSSOM 构建； - 接口请求是否批量超时：多个并发 fetch 在 Slow 3G 下 TTFB 普遍 >1.2s，结合后端响应慢，容易触发前端 timeout 逻辑失效或重试风暴。
自定义配置还原真实现场问题
当预设档位复现不了“信号满格但卡死”的现象（比如用户反馈地铁进隧道时支付失败），就得手动建模：
- 单位别填错：Download/Upload 填的是 KB/s，不是 Mbps（例如 400 Kbps = 50 KB/s）；Latency 是往返延迟（RTT），不是单向；
- 高延迟场景要调高 Latency：填 1800 ms + Download 150 Kbps，比单纯降带宽更能复现“按钮点了没反应、表单提交卡在 Sending”的问题；
- 上传受限会影响 POST：Upload 设太小（如 5 KB/s），会导致图片上传或表单提交长时间停在 “Sending” 阶段，这不是后端问题，是前端节流参数失真。
结合 Performance 面板看完整链路
Network 面板告诉你“网络慢”，但页面白屏或卡顿可能另有原因：
- 在启用 Slow 3G 并 Disable cache 后，打开 Performance 面板 → 点录制 → 刷新页面 → 停止；
- 看 Main 轨道里是否有长任务（>50ms 的黄色块），尤其是 JS 下载完成后立即出现的大块执行——说明解析编译或同步 DOM 操作成了新瓶颈；
- 检查 Timings 区域的 FCP、LCP 时间是否远超网络耗时，如果是，问题不在加载，而在渲染或 JS 执行。
