看到「网站访问慢」，很多人的第一反应是买更大带宽。

带宽只影响最后一段。前面四段慢的时候，加带宽一点用都没有。

所以先记一次基线，再按段挑动作：

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

五个数是累计值，段耗时要相减。这份结果就是你的基线，改完要拿它比。

没有基线就动手，改完也不知道有没有用

基线要固定三样：同一个 URL、同一组节点、同一时段。

少一样，改完的数字就没法比。

很多人改完看着「好像快了」，其实是换了测速时间，正好赶上低谷。

基线记一次不够：改前一次，改后同组节点再测三次。

解析段能优化的只有 TTL 和 DNS 服务商

解析段长，能动的只有两处：TTL 设多长、用哪家 DNS。

TTL 短，改记录生效快，但解析请求更频繁；TTL 长，反过来。

换 DNS 服务商之前，先在同一时刻比对两家结果：

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

两家结果一致、解析段还是长，换服务商大概率也没用，问题在链路或本地出口。

要确认是「你这台」还是「一片」，用宝塔拨测的网站测速选几个地区同一分钟跑一轮。

解析段长的时候加带宽、换服务器，都是白做。

连接与握手段，能改的都是入口而不是代码

这两段慢，先按地区分组看范围。

只有几个省慢：找接入商核对，改代码没用。

全国都慢：考虑换线路、上 CDN、调整入口。

握手段还伴随证书告警：先看证书链完整不完整，再看协议与套件。

把慢的地区按省份和运营商列出来，再决定动哪一处。

这两段跟业务代码无关，先别改程序逻辑。

首字节段要按接口分开改，一次一处

这一段是服务端在算，改法最多，也最容易一起上。

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

再看接口：把页面拆成几个请求分别测，只改最长的那一个。

改完一处就测一次，别同时改数据库和模板，否则下次测速说不清是谁起的作用。

拆接口这件事没有捷径：先把页面按请求拆开，逐个测，逐个改，再整体测一遍确认。

下载段先减请求数，压缩是第二步

顺序别反：先看有多少个请求，再看单个体积。

合并能从源头去掉的资源，再谈压缩，最后才考虑带宽。

前四段都短、只有下载段长，这类不需要碰服务器，也不用加带宽。

体积能减的先减：首屏大图、没用的第三方脚本、反复重试的 404 资源，这三样最常见。

现在先做一件事：把改前的这次测速结果截图存下来，标上时间和节点组，再动手改。