打开慢的原因，落到测速报告上只有五个位置：解析、连接、握手、等首字节、下载。段外的原因，多半是这五段里某一段被别人的数据摊平了。

同样是打开慢，五种原因怎么分开？

先拿一条命令把五段打出来：

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

五个数是累计时间点，段耗时要相减：DNS 段就是第一个数，连接段是第二个减第一个，握手段是第三个减第二个，首字节段是第四个减第三个，下载段是第五个减第四个。

减完，最长的那个就是主因。剩下四段不是没毛病，是还没轮到。

解析慢，和服务器有关系吗？

没有。解析这一步，请求还没到你的服务器。

验证方式是对比两家 DNS 的结果：

`` dig @223.5.5.5 你的域名 A +short dig @8.8.8.8 你的域名 A +short ``

两家一致、但解析段仍然长，问题在解析链路或本地出口，改服务器没用。

两家不一致，先按解析被拦或未生效处理，也别动服务器。

这一条最容易白干：解析慢的时候重启服务器、换机房，全是无效动作。

连接和握手慢，换机房有用吗？

有用，但要先确认是不是所有地区都慢。

只在一两个省慢：换机房解决不了，那是那几条链路的问题。

所有地区都慢、连接和握手两段都长：换机房或换线路值得试，改代码没用。

握手段特别长、还伴随证书告警：先看证书链是否完整，别急着搬机器。

用宝塔拨测的网站测速跑多地区多运营商节点，按地区和运营商分组看这两段，比只看平均分准。

首字节慢，是代码的问题还是数据库的问题？

这一段只能靠分段改、分段测，一次动一处。

先看有没有缓存：同一个页面连开两次，第二次首字节明显变短，说明缓存有效，问题在首次生成。

再看接口：把页面拆成几个请求分别测，哪个接口的首字节长，问题就在那个接口。

数据库慢查询、外部接口串行调用，都会落在这段里，但改法完全不同，所以要拆到接口级别再动手。

下载慢，是带宽不够还是页面太重？

看两个数：页面总字节数和请求数。

前四段都短、只有下载段长，先压体积、减请求，不用加带宽。

下载段长、同时首字节也长，可能是服务端在边生成边输出，回去查后端。

带宽不够的典型特征是所有资源都慢、且并发一多就更慢，这种情况才轮到扩容。

每段都不长，页面还是转很久，是哪里在拖？

测速测到的是传输，测不到浏览器排版、脚本执行、资源排队。

五段加起来一秒、体感五秒（举例），差的四秒在渲染侧。

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

两边对不上时，以用户体感为准去做前端的排查，别拿测速报告去反驳用户。

我现在的取舍是：只改测得出证据的那一段，剩下三段的假设先用对照实验排掉，不靠猜。