chrome devtools network面板本身不优化加载，而是精准定位慢因：必须开启disable cache、preserve log和红色录制按钮，通过瀑布图分段颜色（stalled/blocking/下载）、xhr过滤、size/time排序及initiator列分析，才能发现dns慢、资源过大或阻塞等问题。
Chrome DevTools 的 Network 面板本身不直接“优化”加载，而是帮你精准定位加载慢的原因——找到问题，才能有效优化。核心是用对配置、看懂数据、聚焦关键瓶颈。
基础配置必须开全
没开关键开关，看到的数据就不可靠：
- Disable cache：勾选它，才能排除缓存干扰，看清真实服务端响应速度和资源体积
- Preserve log：SPA 页面跳转、登录重定向时，它能留住完整请求链，否则一刷新就清空
- Recording 按钮为红色实心●：灰色=暂停监听，刷新也白刷；快捷键 Ctrl+E（Win/Linux）或 Cmd+E（macOS）可秒切
- 刷新用 Ctrl+R 或地址栏回车：点页面内链接跳转不会触发完整重载，Network 面板记录不全
重点看瀑布图里的“分段颜色”
Time 列数字只是总耗时，真问题藏在瀑布图柱子的颜色分区里：
- 左侧浅灰（Stalled）长→ 浏览器排队：同域名并发连接数超限（HTTP/1.1 默认6个），或代理/TLS 握手卡住
- 中间红段（Blocking）长→ DNS 查询慢、TCP 连接建立慢，可能是本地 hosts 异常或网络质量差
- 深蓝下载段占比过高→ 资源本身太大，比如未压缩图片、未拆分的 JS 包
- 后续请求明显被推迟→ 前置资源阻塞了关键路径，比如 render-blocking CSS 或同步 script
快速筛出接口类请求
fetch/XHR 请求默认混在大量静态资源里，容易漏掉：
- 点顶部预设按钮：XHR 或 Fetch，一步过滤掉 HTML/CSS/图片等干扰项
- 在过滤框输入：/api/（匹配路径）、method:POST（限定方法）、status-code:500（查报错）
- 若只看到灰掉的 OPTIONS 请求 → fetch 的预检失败，主请求根本没发，得先查服务端跨域配置
结合 Summary 和排序找大头
底部 Summary 显示总请求数、传输量、LCP 时间，是宏观判断依据：
- 按 Size 列降序，一眼找出体积最大的几个资源（比如一张 4MB 的 banner 图）
- 按 Time 列降序，挑出耗时最长的请求，再点开看详情里的 TTFB（首字节时间）是否异常高 → 高则说明服务端响应慢
- 关注 Initiator 列：标为 Script 的请求，说明是 JS 主动发起，可回溯代码确认是否必要、是否可延迟
不复杂但容易忽略
