一次请求其实只有五段耗时：DNS、TCP、TLS、TTFB、下载。加起来是总时间，任何一段变长，页面就慢。

大多数「优化清单」的问题，是不管哪段慢都上同一套动作。

打开慢，到底是哪一段慢？

在能连外网的机器上跑一条：

`` curl -o /dev/null -s -w '%{time_namelookup} %{time_connect} %{time_appconnect} %{time_starttransfer} %{time_total}\n' https://你的域名 ``

五个数依次是：解析结束、连接建立、TLS 握手完成、首字节到达、全部传输完成。

这些是累计时间点，不是段耗时。段耗时靠相减：TLS 段 = 第三个减第二个，等首字节那段 = 第四个减第三个，下载段 = 第五个减第四个。

正常情况前四段都在几十毫秒量级，下载段取决于页面体积，没有统一定值。

减下来某一段明显大于其他段，就是这一段慢。

只在自己这台机器上测，看到的还是这一条线路。要一次看多个地区落在哪一段，用宝塔拨测的网站测速选多地区多运营商节点跑一轮，按地区分组看五段分布。 在本机跑和在服务器上跑，结果会不一样：本机带上你自己这段网络，服务器上跑更接近源站真实处理时间。两个都记，别混着比。

五段里哪一段最值得先看？

最长的一段 常见位置 先动哪里
DNS解析链路、TTL 设置先比两家 DNS 的结果，别动服务器
TCP线路、机房出口、防火墙换地区节点复测，看是不是局部
TLS证书链、握手配置、中间设备先看证书链是否完整
TTFB（等首字节）后端处理、数据库、缓存先查接口耗时与慢查询
下载页面体积、请求数、带宽先看大图与第三方脚本

表里「先动哪里」那一列有个共同点：都是从最便宜的动作开始。DNS 换一家成本最低，改后端最贵，顺序别反。

四段都短、只有下载段长，这类最好办：图片和脚本能压就压，能减就减，不用碰服务器。

前两段长、后两段短，先想线路，不要先优化代码。

抓到数字之后，怎么知道改对了没有？

一次结果不算数，改前改后各测三次，同一组节点、同一时段。

三次都降，才算真的改了；一次降一次升，多半是波动。

再比改前改后的同一批节点。分组结果比平均分有用，平均会把一个省的异常摊薄。

改的时候只动一处：同时改 CDN 和代码，下一次测速说明不了是谁起的作用。

有时候测着不慢，用户还是说慢，怎么算？

测速测到的是传输，测不到浏览器排版、脚本执行、第三方请求排队。

五段加起来一秒，用户体感五秒，差的那四秒在渲染侧。

这种先去浏览器的网络面板看资源瀑布：哪些资源在排队、哪个脚本阻塞了解析、有没有第三方域名在等。

两边对不上，就不要拿测速结果去反驳用户，各说各的层。

有一点我没确认：这套五段拆法对纯静态页够用，对单页应用里接口串行调用的情况能覆盖多少，我手上没有对比样本，只能先按最长的那个接口单独测。