从 30 秒到 4 秒：网站加载慢的系统排查与优化方法
“网站打开很慢”是一个症状，不是一个结论。 它可能是 DNS 解析慢、TLS 握手慢、后端首字节慢，也可能是页面一次下载了几 MB 的 JavaScript；还可能是资源已经下载完，却被串行依赖、超大 JSON 或主线程长任务拖住。不同原因的修复方法完全不同。 最近我对一个登录后的 Web 应用做了一次完整排查。优化前后的结果如下： 指标 优化前 优化后 冷加载传输量 4.57 MB 1.14 MB FCP 4.33 秒 1.34 秒 LCP 30.67 秒 3.90 秒 load 事件 30.46 秒 3.54 秒 热加载传输量 — 22.7 KB 热加载 LCP — 0.83 秒 这是一组代表性的单次测量：使用 Chromium 无头模式、1440×1000 视口；冷加载会清空并禁用缓存，热加载则启用缓存。表中为浏览器记录的 encoded bytes，沿用“传输量”这个易读称呼，但它不等于 TLS 帧和网络包层面的全部字节。因此，冷加载的改善不能归因于浏览器缓存，热加载结果才用于验证缓存效果。 这次已经实施并验证的改动包括文本压缩、内容指纹缓存，以及普通请求与 SSE/WebSocket 的代理分流。其中，压缩直接减少了冷加载传输量，缓存让热加载只需传输约 22.7 KB；代理分流通过协议与回归测试验证正确性，但没有做单变量性能对照。一个会话历史 API 原本单次传输 4.25 MB，开启压缩后降到了约 369 KB。 source map 的 gzip 与 5 分钟私有缓存也已经实施，但普通页面在未打开 DevTools 时不会请求它，所以没有计入上表。超大 JSON 的结构治理、非关键请求延迟与增量聚合、CDN 和带宽升级则是进一步优化方向，同样没有被写成已经发生的结果。 ...