真正模拟弱网异步加载瓶颈需提前启用节流并禁用缓存，验证Stalled与TTFB是否显著拉长，配合CPU节流复现端到端压力，避免仅依赖Slow 3G预设导致测试失真。
要真正模拟弱网下的异步加载瓶颈，不能只点一下 Slow 3G 就刷新——节流本身不等于“卡顿可见”，关键在排除干扰、抓准信号、关联主线程行为。
必须提前启用 + 彻底禁用缓存
节流策略仅对刷新后新发起的请求生效，已发出或缓存中的资源完全不受影响。常见误操作是先刷新页面，再点 Slow 3G，结果所有资源走内存缓存（memory cache）或磁盘缓存（disk cache），Waterfall 时间几乎不变。
- 务必在刷新前设置好节流模式（如 Slow 3G）并勾选Disable cache
- 可配合清空 Application → Clear storage → “Clear site data” 彻底重置缓存状态
- 验证是否生效：看每个请求 Waterfall 中的Stalled（排队等待连接/队列）和Waiting (TTFB)（首字节时间）是否明显拉长，比如从 20ms 增至 300ms+；总耗时受解码、执行等影响，不可靠
选对预设或填准自定义参数
Chrome 内置预设虽方便，但部分参数与真实弱网偏差较大。例如默认 Slow 3G 的延迟为 400ms、下行 400Kbps，而实测城市边缘 3G 常见 RTT 是 200ms、下行约 400Kbps（即 50KB/s）。
- 若用自定义配置，注意单位：Download/Upload 单位是 KB/s，不是 Kbps；400Kbps ÷ 8 = 50KB/s
- Latency 填的是往返延迟（RTT），不是单向；电梯、地下车库等场景建议设为 2000–3000ms
- Upload 值过小（如设为 1KB/s）会导致 POST 请求长期卡在 “Sending” 阶段，影响表单提交、图片上传类异步逻辑验证
识别“假快真卡”：节流不等于渲染卡顿
Network 节流只压制网络传输层，JS/CSS 文件下载变慢 ≠ 页面一定白屏。如果 main.js 仅 60KB，在 Slow 3G 下约 1.2 秒下完，但后续同步执行可能触发强制 layout、大量 DOM 插入或未拆分的长任务，导致主线程阻塞超过 500ms——此时 Waterfall 看似“已加载完成”，用户却看到长时间白屏或卡死。
- 配合 Performance 面板录制操作，重点观察Main 线程是否有 >100ms 的长任务
- 检查异步资源是否被阻塞：未加
async/defer的 script、跨域且无 preload 的字体、含@import的 CSS 都会在节流下显著拖慢 CSSOM 构建 - 懒加载图片或模块若依赖
IntersectionObserver，节流下滚动事件触发频率下降，也可能造成“本该加载却没动”的假象
进阶：组合 CPU 节流复现端到端压力
真实弱网用户往往也使用中低端设备。仅网络节流无法暴露 JS 解析慢、布局重排多、框架 diff 效率低等问题。
- 在 Network 节流启用的同时，打开 Performance 面板 → 点击右上角 ⚙️ → 启用 CPU Throttling（如 4x slowdown）
- 这样能同时压测网络带宽 + 主线程计算能力，更贴近千元机 + 3G 网络用户的实际体验
- 特别适合验证骨架屏是否及时渲染、loading 状态是否准确更新、错误 fallback 是否及时触发
