总时长这个数，参考价值最低

页面慢的时候，很多人第一反应是「测一下多少毫秒」，然后盯着那个总数看。我以前也这样，后来才发现，总时长只告诉你「慢」，不告诉你「哪慢」。

一次请求从解析域名到收完内容，中间要过五道关口。总时长是这五段的和，任何一段出问题都会把它拉长，从总数上根本分不出来。

宝塔拨测的网站测速在这件事上的价值，就是把五段分开列出来，让你知道时间花在哪。

第一个该看的其实是状态码

慢和错是两件事。状态码异常的时候，先处理错误，别急着优化速度。5xx 是后端处理失败，4xx 是请求或权限问题，3xx 是跳转。跳转还会额外多一轮请求，看起来像慢，实际是多走了一趟。

状态码正常，再往下看时间。这一步能省掉很多无效排查。

TTFB 最能分出前后端

五段里我最先看首字节时间。它大致是请求发出到收到第一个字节，包含服务端处理的时间。TTFB 大，说明后端在拖：程序、数据库、缓存没命中，或者上游接口慢。

反过来，TTFB 很小、总时长却长，问题基本不在服务端，往下看下载段和资源体积就对了。一个纯静态页面如果 TTFB 也很高，基本可以把范围收到服务端处理这一段。

DNS 和 TCP 决定起点顺不顺

DNS 段长，查解析服务商、记录配置和权威服务器响应。有些域名挂了好几个 NS，解析链路本身就绕。本机改过 hosts、或者用了公共 DNS，看到的解析结果也可能和节点不一样，别拿本地的一次解析当全网结论。

TCP 段长，看线路、丢包、防火墙和端口。这一段是纯网络层面的，跟你的程序没有关系，改代码改到天亮也没用。

TLS 段单独聊过，证书链、协议版本、往返次数都会影响。它慢的时候，症状和线路慢很像，得靠节点分布去分。

下载段要看内容和带宽

下载段慢有两种：内容太大，或者带宽不够。图片没压缩、JS 打包过大、视频直接回源，都会把这一段拉长。这时候优化方向是资源和 CDN，不是服务器配置。

顺序上我一般放到最后看。前面几段都正常，才有必要细究下载。

分组和复测才算闭环

单节点的五段只能说明一条路。用多地区多运营商节点跑一遍，再看平均、最快、最慢：所有节点都在同一段慢，是源站问题；只有部分运营商慢，是链路问题。

改完再连测三次，对着同一批节点的同一段比较，才算验证过。不然你只是换了个时间点，看到了另一个随机结果。