页面加载时间线计算器

本地处理

页面加载是一条串行的接力赛：DNS → TCP → TLS → 等待首字节 → 下载资源。任何一棒慢，后面全部顺延。拆开看每一段花了多少，才知道该优化哪里。

DNS 解析 (ms)

TCP 建连 (ms)

TLS 握手 (ms)

等待首字节 TTFB (ms)

资源数量

并发连接数

平均资源大小 (KB)

带宽 (Mbps)

首字节耗时(ms)

单资源下载(ms)

资源总下载(ms)

总加载(ms)

阶段	本段耗时	累计	占比

首字节耗时 = DNS + TCP + TLS + TTFB；单资源下载 = 资源大小(KB) × 8 ÷ 带宽(Mbps)；资源总下载 ≈ ⌈资源数 ÷ 并发数⌉ × 单资源下载；总加载 = 首字节耗时 + 资源总下载。这是稳态近似模型，未计入连接复用、缓存命中与优先级调度带来的优化。

首字节之前发生了什么

用户输入网址到看到第一个字节，中间有四段完全串行的过程。任何一段都可以成为瓶颈，而且它们的成因与优化手段完全不同：

注意第三段几乎全部是「往返次数 × 网络延迟」的函数。跨洋链路的单次往返约 150–250 ms，而 TLS 1.2 需要两次往返、TLS 1.3 只要一次——一个协议版本升级，首屏就能省下几百毫秒。这也是 CDN 的价值所在：把服务器搬到离用户几十毫秒的地方，所有往返都变短。

浏览器对同一域名的并发连接数有上限（HTTP/1.1 通常为 6）。把 30 个资源塞给 6 条连接，就要分 5 批下载。理论上把并发提到 30 会快 5 倍——但实际上会带来三个问题：

真正的解法不是加并发，而是减少请求：合并资源、用雪碧图、开启 HTTP/2（多路复用彻底绕开并发限制）、把首屏非关键资源延迟加载。

通常是关键样式表与首屏图片、以及阻塞渲染的同步脚本；把关键样式前置或内联、其余资源异步加载，首屏改善最明显。

新协议下多路复用可并行拉取，但连接数与依赖顺序仍会造成等待；把无依赖的资源尽早并行发出，是缩短时间线的关键动作。

用同一网络条件与设备多次测量取中位数，对比优化前后的时间线；只测一次容易被抖动误导，并注意区分冷缓存与热缓存结果。