改完了，谁也说不清有没有用

去年做了十几项优化，季度复盘时被问：到底哪几项起作用了。

大家面面相觑，因为当时都是「改完感觉快了」，没留数据，也没法回退。

把优化当成实验

换个说法，做法就变了，争论也会少很多。

实验要有假设：我猜慢在 TTFB，因为接口在同步调用外部服务，先把猜测写下来。

要有指标：TTFB 的耗时要降到某个区间，而不是「整体变快」这种没法证伪的说法。

要有对照：改前一组数据，改后同一组条件再测一次，两边才可比。

指标从五段里选

五段就是现成的仪表盘，不用另造指标。

优化连接层的改动，就看 TCP 和 TLS 两段，别被总分干扰。

优化后端，就看 TTFB，别看总分，总分里混着网络和资源。

优化资源体积，就看下载段和首屏耗时，两个一起看更准。

指标选错，改得再对也证明不了，最后只能靠嘴说。

一次只改一个变量

这条最反人性，也最有用，忍住一次只改一样。

同时改三样，结果好了不知道是谁的功劳，坏了更不知道该回退哪个。

想一次做三件事，就排成三次实验，一次一次来，慢一点但清楚。

每轮之间留出稳定期，让缓存和连接状态回落，不然数据会串。

复测怎么设计

复测是为了排除偶然，不是为了凑一个好看的数。

用宝塔拨测的网站测速固定一组节点，改前改后各测三次，条件一致才有可比性。

按地区、按运营商分组看，确认改善是不是普遍的，别只看自己那一台。

只在某个地区变好，说明这次改动只解决了一部分问题，剩下的还得查。

记录与复盘

记录是团队的复利，比任何单次优化都值钱。

一行一条：假设、改动、指标变化、结论，四列就够，别搞复杂模板。

没起效的改动要回退，别留在代码里当「历史遗留」，那是最贵的负债。

积累几十条之后，你会发现自己判断瓶颈的速度明显变快，也不用每次从头摸索。

把优化做成实验，效果就能积累。

积累久了，判断就成了直觉。

直觉准了，少走弯路。

弯路少了，效率就高。

效率高了，优化才做得完。

做完之后，复盘才有料。

有料，团队才进步。

进步了，客户才满意。

满意了，复购就有了。

复购来了，业务就稳。

稳住业务，团队才踏实。

踏实做事，效果才长久。

长久看，方法比技巧重要。

方法对了，谁来做都不会太差。

做好了，才算真正的方法论。

论站得住，才值得推广。

值得推广，团队就一起用。