优化的顺序应该由测出来的数字决定，不由你熟悉什么决定。大多数人一上来就压缩图片，结果真正慢的是解析和握手，压了也没有变化。

所以先把五段打出来：

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

五个数是累计值，段耗时要相减。减完最长的那段，才是第一件要动的事。

优化从最便宜的那一段开始，不是从最熟的那一段开始

便宜指的是改动小、可回滚、不影响别人。

排序大概是：先查不改（看数字、比对结果），再改配置（TTL、缓存头、证书链），最后才动代码和机器。

跳过前两档直接上代码，最常见的结局是改完没变快，还多了一个变量。

解析段能做的只有三件事

查记录对不对、查 TTL 设多长、查两家 DNS 结果是否一致。

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

两家一致、解析段仍长，就不要在这里继续投入，去下一段。

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

连接段能改的是线路和入口，不是代码

连接段长，说明握手前的路不好走。

先按地区分组看是不是局部：只有几个省慢，去找接入商核对，改代码没用。

全国都慢，再考虑换机房、上 CDN、调入口线路。

这一步之前，先用宝塔拨测的网站测速跑多地区多运营商节点，把慢的地区和运营商列出来，别凭印象动手。

握手段先看证书链，再谈协议版本

握手段长，最常见的两个原因：证书链不完整、中间设备拦了某些协议。

先看证书张数：

`` echo | openssl s_client -connect 你的域名:443 -servername 你的域名 -showcerts 2>/dev/null | grep -c "BEGIN CERTIFICATE" ``

返回 1 张，先把中间证书补上再测。

返回 2 张以上、握手仍然长，才轮到试协议版本和加密套件。

首字节段只能一处一处改

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

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

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

数据库慢查询、外部接口串行、模板渲染，都可能落在这段，但改法不同，必须拆开。

下载段先减数量，再考虑压缩与带宽

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

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

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

改完必须有对照，否则等于没改

同一组节点、同一时段、连测三次，改前改后各一次。

只动一处，否则说不清是谁起的作用。

三次都降才算改对；一次降一次升，先记下来，别写进汇报。

反过来，如果你只在办公室测了一次，看到数字变好就宣布优化完成——那台机器的网络、缓存、时段全都可能变了，这个结论站不住。