直接查看瀑布流中脚本请求的ttfb、content download和queueing/stalled三段耗时可快速定位加载慢根因；结合js筛选、initiator分析、时间排序及缓存禁用等方法精准诊断网络、服务端、体积与并发问题。
直接看瀑布流（Waterfall）里的脚本请求条，重点盯住 TTFB、Content Download 和 Queueing/Stalled 这三段耗时，就能快速定位模块脚本加载慢的根因。
识别关键脚本请求
模块脚本通常以 .js 结尾，可能带版本号或 hash（如 chunk-vendors.a1b2c3.js）。在 Network 面板中：
- 用 Filters → JS 筛选出所有 JavaScript 请求
- 结合 Initiator 列，确认是否由
Script或Parser发起——前者是动态 import 或 script 标签插入，后者是 HTML 解析时自然加载 - 按 Time 降序排列，优先排查耗时最长的几个 JS 请求
逐段解读瀑布流时间轴
点击任一 JS 请求，在下方 Waterfall 图中观察各阶段颜色块，重点关注：
- DNS Lookup + Initial Connection + SSL：若总和 > 300ms，说明网络基础链路有延迟，可能是 CDN 节点远、证书配置不当或 DNS 不稳定
- Waiting (TTFB)：这是服务端响应首字节的时间。超过 500ms 很可能后端构建产物未预编译、SSR 渲染卡顿、或 CDN 未缓存静态 JS
- Content Download：下载时间长 ≠ 网络差，更可能是脚本体积过大（比如未做 code-splitting 或未启用 gzip/brotli）
- Queueing / Stalled：常见于同域名并发超限（HTTP/1.1 最多 6 个连接），尤其当多个模块脚本共用一个域名时；也可能是高优先级资源（如关键 CSS）抢占了连接
排除缓存与并发干扰
真实瓶颈常被浏览器缓存掩盖，务必开启精准测试环境：
- 勾选 Disable cache（功能区第二排第10项），确保每次都是真实网络加载
- 勾选 Preserve log，避免页面跳转/刷新后丢失模块加载前的上下文（例如路由懒加载触发前的初始化请求）
- 若怀疑并发阻塞，可临时将脚本域名拆成 sub1.example.com / sub2.example.com，观察 Queueing 是否减少
关联分析辅助线索
单看瀑布流不够，需联动其他字段交叉验证：
- 查看 Size 列：若脚本显示 “from ServiceWorker” 或 “from disk cache”，说明没走网络，此时 Time 不反映真实加载性能
- 检查 Response Headers：确认是否含
content-encoding: br或gzip；缺少则压缩未生效 - 比对 Initiator 和调用栈：点击 Initiator 值（如某行 script 标签），能直接跳转到源码位置，确认是不是冗余的
import()或重复加载
