ping 二十毫秒，页面三秒

有个站的 ping 值一直很漂亮，用户却抱怨页面要等。我把两件事放在一起看，才意识到它们之间隔着一整条链路：ping 测的是一个包，页面是一连串请求。

延迟低只说明「路近」，不说明「事少」。

打开页面要先等三件事

第一件事是解析。浏览器要先知道域名对应哪个 IP，本地没有缓存就得问一圈。

第二件是建立连接，TCP 三次握手。第三件是 TLS 握手，尤其第一次访问、没有会话复用时最明显。

这三步走完，请求还没发出去。ping 一个都不包含。DNS 要跨网络查、TLS 用了老协议多一个往返，这里的等待都会被放大。

网站测速：多站点分段耗时与状态码

网站测速：多站点分段耗时与状态码

请求发出后还要等

服务器收到请求，处理、查库、拼页面，然后返回第一个字节，这就是 TTFB。后端慢的时候，这一段的等待可能是页面耗时的大头。

接着是下载响应体。HTML 本身不大，但如果压缩没生效，或者走的是慢链路，也会拖时间。重定向也算在这一段里，一次 301 就多一整轮请求。

页面不是一个请求

HTML 下载完之后，浏览器还要去拿 CSS、JS、图片、字体。这些资源可能来自不同域名，每个新域名都要重新走一遍解析、连接、握手。

JS 如果是阻塞渲染的，页面就得等它下载并执行完才显示内容。第三方统计、客服插件、字体服务，任何一个慢，首屏都会跟着慢。

HTTP/1.1 下同一域名的请求还可能排队，连接数有限，后面的只能等。

这些时间叠起来，才是用户感知的「打开慢」。

哪些能用拨测看见

用宝塔拨测的网站测速跑多地区多运营商节点，DNS、TCP、TLS、TTFB、下载五段分开列。

DNS 段长，说明解析慢；TCP 和 TLS 长，说明连接成本高；TTFB 长，说明后端在拖；下载长，说明带宽或资源体积有问题。

但它只看一次主请求。页面上那些子资源，拨测看不见。只测首页，结论也只能代表首页那一次请求。

剩下的交给浏览器

服务端分段都正常，就去浏览器开发者工具里看资源瀑布图：哪个文件最大、哪个请求最晚、有没有阻塞渲染的脚本。

改完之后，拨测复测确认服务端这一段没退化，浏览器再确认首屏有没有变快。两边都看，才不会把「服务端很快」当成「用户很快」。

这些等待里，只有一部分能靠改服务器解决，其余的得回到前端。记录里保留分段数据，下次对比才有依据。