Chrome DevTools 模拟慢网络验证前端加载的操作步骤

想知道页面在慢网络下为什么变慢，最稳妥的做法不是凭打开速度猜测，而是在 Chrome DevTools 的 Network 面板固定同一套条件，再比较两轮请求。核心是先确定缓存策略，再切换 Throttling，最后同时看请求的 Time 列和 Waterfall。

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

只要两轮测试使用相同页面、相同缓存开关和相同记录方式，Slow 4G 与 No throttling 的请求耗时就能形成可复核对照；如果不先处理缓存，结果很容易把“命中缓存”误判成“网络很快”。

先建立一组可比较的加载基线

打开待测页面后按 F12，进入 Network。点击工具栏中的清除按钮，确保请求表只保留本轮记录。第一次基线建议先选择 No throttling，并明确决定是否勾选 Disable cache。

如果要模拟首次访问，勾选 Disable cache；如果要观察已有缓存对重复访问的影响，则保持它关闭，但两轮比较必须保持一致。DevTools 的该选项只在开发者工具打开期间生效，关闭 DevTools 后不要把这次状态当成普通浏览器访问结果。

点击页面刷新，等待本轮请求记录稳定。重点保留主文档、首屏脚本、样式和主要图片，后续只比较同一批资源，避免一轮看主文档、另一轮看异步接口而失去可比性。

切换 Slow 4G 并重新加载

在 Network 工具栏找到 Throttling 下拉框，选择 Slow 4G。如果当前版本没有现成配置，可以进入 Custom，新增一个带下载速度、上传速度和延迟的配置；文章只需要固定配置名称，不必为了对照频繁改变参数。

确认工具栏仍保留与基线相同的 Disable cache 状态，然后再次点击刷新。限速开启时，Network 面板通常会显示提醒图标；这能帮助你避免忘记恢复网络条件。不要在这一轮同时修改设备模拟、请求拦截或用户代理，否则观察到的差异就不再只来自网络。

从 Time 和 Waterfall 读出慢在哪里

先观察主文档请求。如果它的等待阶段明显变长，说明首个响应本身受网络延迟影响；如果主文档很快，但首屏脚本或字体的下载条很长，则应继续看这些资源是否过大、是否串行依赖，或是否在缓存关闭后才暴露真实下载时间。

可以按下面的表格记录两轮结果：

如果想看某一类资源，可以用请求表的类型筛选器只保留 JS、CSS 或 Img。筛选只改变展示，不改变网络条件；因此每次对比时要记录筛选范围，避免误把“筛掉了请求”理解成“请求没有发生”。

恢复环境并整理一份可复核记录

对照结束后把 Throttling 切回 No throttling，按需要恢复 Disable cache，再清空一次请求记录。记录页面地址、测试时间、缓存开关、限速配置、主文档 Time、首屏资源的 Time 和异常资源名称。

若两轮差异很小，先检查是否误用了缓存、页面是否已有 Service Worker、是否每次都加载了同一入口；若只有某个资源变慢，优先打开该请求查看响应大小和 Waterfall，而不是直接把整个页面判定为网络问题。

常见疑问

为什么勾选 Disable cache 后结果变化很大？

它会让开发者工具打开期间的资源不再从浏览器缓存直接取用，更接近首次访问场景。要比较网络速度，关键不是一定要勾选，而是两轮使用同一状态。

Slow 4G 能代表真实用户的全部网络环境吗？

不能。它适合做可重复的实验对照，不等于真实用户的运营商、设备性能和网络波动。发布前仍应结合真实用户指标或现场网络做补充判断。