2026 年 10 月我们做了一组弱网测试，同一个页面，三种配置，首屏时间从 1.8 秒到 4.1 秒。差异不是页面本身的问题，是测试条件不同。只用 DevTools 的 3G 降速，会漏掉一半真实问题。
DevTools 降速只模拟了两件事
它限制了带宽和往返延迟，就这两件。
它不会模拟丢包。真实弱网环境下丢包率能到 1% 到 3%，一次丢包触发重传，时间就多出好几百毫秒。
它也不会模拟手机的 CPU 压力。真机上页面在加载，还有其他应用在后台，CPU 不是满血状态。
真实弱网的三个特征
第一，高延迟。4G 在信号弱的地方，往返延迟能到 200 到 400 毫秒。
第二，丢包。基站的负载、电梯、地铁、地下车库，都会造成间歇性丢包。
第三，带宽波动。同一个位置，人一多，速度掉一半。
我们用的三种配置
第一种，3G 快速，带宽 1.6 兆，延迟 150 毫秒。用来测基本可用性。
第二种，4G 弱信号，带宽 1 兆，延迟 400 毫秒，丢包 1%。这个最接近地铁和商场。
第三种，自定义慢速，带宽 400KB，延迟 600 毫秒。用来测极端情况，看页面会不会直接崩。
我们的验收标准是第二种通过即可，第三种只做参考。
用真机做真实弱网
DevTools 的模拟再准，也比不上真实环境。
最简单的办法：手机开热点，笔记本连上去，用系统工具给热点限速。测出来的数据比 DevTools 更接近实际。
更真实的做法是走到地铁、电梯、商场这些地方打开页面，录屏。看哪一步卡住。这种方法不能量化，但能发现一些数据里看不出的问题。
弱网下先看什么
先看请求数量。弱网下每个请求都要一个来回，请求少的页面天然占优。
再看首屏资源体积。超过 1 兆的首屏资源，弱网下基本要等三秒以上。
最后看有没有串行依赖。CSS 里有 @import、JS 里动态加载 CSS，这类串行在弱网下会被放大好几倍。
一个成本很低的改进
请求数是弱网下最敏感的因素。我们给一个站把首屏的七个图标字体合成一个 SVG 精灵图，请求从七个变成一个，弱网首屏快了 400 毫秒。
这个改动一天能做完，不用改设计。弱网优化里，减少请求的收益通常比压缩体积大，因为每个请求都要一次来回。
一个态度
弱网测试的意义不是追求极端环境下的完美，是知道自己的页面在什么条件下会崩。
大部分软件公司的客户里，有一部分人就是在弱网环境下访问的，可能是出差、可能在客户现场。
对这些用户来说，首屏晚两秒可能就关掉页面了。这个损失在报表里看不到，但真实存在。
元析智能
为软件公司做 SEO 和 GEO 优化