动作全做了，还是慢

一个项目做了压图、开缓存、换高配机器，响应时间从 3.2 秒降到 3.0 秒，几乎没动。

花的钱不少，效果几乎没有，因为瓶颈压根不在这三处，方向错了再多动作也没用。

一个原则：动作对证据

原则简单，执行最难，因为大家都想一次解决。

先测，拿到五段耗时，再决定动哪一处，这一步省不得。

每一段都有对应的动作，做错段等于白做，还容易引入新问题。

做完立刻复测，只比同一段，别拿总分下结论，总分里变量太多。

四组动作对应四段证据

对上了，就不会做无用功，也容易跟老板解释。

DNS 段慢：换解析服务、检查线路和 TTL，别动服务器，动也没用。

TCP 和 TLS 段慢：看连接复用、证书链、协议版本，必要时调节点，这三项改动都很快。

TTFB 段慢：查排队、慢查询、外部调用，这一段只能动应用，加带宽完全无效。

下载段慢：压缩、转格式、减少请求数，前端就能解决大半。用宝塔拨测的网站测速固定一组节点，改前改后各测三次，是唯一可靠的验证方式。

常见白做的动作

这三种，我全干过，每次都是因为没先测。

没测就加带宽，结果下载段本来就不大，钱花得最冤。

没测就换机房，结果瓶颈在数据库，换十次也不会变快。

没测就全站上 CDN，结果 TTFB 依然长，因为回源那一跳没变。

怎么验证动作有效

验证方式要固定，否则数据不可比，也容易得出相反结论。

固定一组节点，改前改后各测三次。

按地区、按运营商分组，确认改善是普遍的还是个别的，这决定下一步要不要扩大范围。

只改善一个地区，说明这次只解决了一部分场景，剩下还得继续查。

复测与记录

记录完整，下次才快，不用重新推理一遍。

一次只改一处，改完等缓存稳定再测，急着测容易被旧数据骗。

记录假设、动作、指标变化，三样对齐，复盘时才知道该保留什么。

没效果的动作要回退，别把无效改动留在线上，那是给自己埋雷。

动作对得上证据，响应时间才降得下来。

降下来，用户才愿意留下。

留下了，转化才有机会。

有机会，生意才做得成。

做得成，团队才有底气。

底气足，才能持续投入。

投入持续，效果才稳。

稳了，就少返工。

返工少了，时间就省出来。

省出来，可以多做一次复盘。

复盘一次，判断就更准。

判断准，响应时间才会真降。

真降了，才算解决问题。

解决问题，用户才会说好。