优化清单全做完了，页面没快多少

去年给一个站点做提速，压缩、合并、开缓存、换镜像，一套做完，前端同事说感觉差不多。

回头补测才发现，慢的那一段一直在 TTFB，后端接口在等数据库，前面那些改动根本没碰到它，等于白忙一场。

先测，再决定改什么

顺序换了，成本差好几倍，效果还不一定出得来。

优化最贵的不是手段，是选错手段之后浪费的工期，还有反复返工消耗的信任。

一次多节点的网站测速，加上分段耗时，成本比改代码低得多，先把方向定了再动手。

先知道瓶颈在哪一段，再挑对应的手段，才谈得上「最快」，否则只是「做得多」。

分段和手段的对应关系

对应关系错了，努力就白费，还会让人以为「优化没用」。

DNS 慢：先看解析链路和缓存，命中率上不去，后面所有请求都跟着慢一拍。

TCP 慢：问题在链路上，考虑节点调度、线路质量，换机房有时比换代码有效，这很反直觉但确实如此。

TLS 慢：证书链精简、会话复用、协议版本，都是低成本手段，改完立刻能测出来。

TTFB 慢：后端排队、慢查询、缓存命中率，这一段只能动应用，前端怎么压缩都没用。

下载慢：资源体积、压缩、图片格式、并发数，前端能做的事最多，收益也来得最快。

用分组决定改哪一层

范围决定手段，不是反过来，全站慢和局部慢用的根本不是一套办法。

只有部分地区慢，优先考虑 CDN 和线路，源站改了也没用，用户在那边感受到的还是慢。

所有地区、所有运营商一起慢，先动后端和资源体积，这时候换线路是花钱买安慰。

用宝塔拨测的网站测速跑多地区多运营商节点，五段耗时和状态码都在，按地区、按运营商分组一对比，方向就定了，平均最快最慢节点也能一起看。

一次只改一处

可回退的改动，才叫优化，不可逆的改动叫赌博。

同时改三样，快了你也不知道是哪一样起效，慢了更不知道该回退哪个。

改完用同一组节点、同一时段复测，只比同一段耗时，条件变一个结论就不成立。

没变化就回退，别把无效改动留在代码里，越堆越难维护，也容易掩盖真正的问题。

什么时候该停

知道在哪停，比知道怎么加更重要，也更能体现判断力。

优化有边际效应，最后那一点时间往往要花几倍成本，值不值得看业务。

先看业务能感知的差别，再决定要不要继续投入，用户感知不到就是自我感动。

测速是尺子，别把尺子当成目标，数字好看而体验没变，那只是报表好看。