清单二十条，先做哪条

接手一个慢站，前人留下一张优化清单，列了二十项，从图片压缩到换机房都有。

我一条条往下做，做到第八条才发现，前面那些对这次的瓶颈根本没用，白忙了三天。

先测，把假瓶颈排掉

这一步做完，清单能短一半，剩下的也更值得做。

没测过的优化都是猜测，猜测最容易浪费的不是钱，是人，还有本来能用在别处的时间。

一次多节点测速加分段耗时，能直接告诉你时间花在哪一段，状态码还能顺手排掉跳转问题。

剩下那些不在瓶颈上的清单项，可以先划掉，别惦记，也别为了做完而做完。

用两个维度排序

两个维度一起看，才叫优先级，只看一个都会排偏。

一个维度是成本：几分钟的配置、几天改代码、几周的迁移，完全不是一个量级，混着排就会排错。

另一个维度是收益：这一段占总耗时多少，改完最多能省多少，收益要看分段数据，不能凭感觉。

成本低收益高的先做，成本高收益低的往后放，这是最朴素也最有效的排序。排序之前先用宝塔拨测的网站测速在同一组节点各测一次，收益才有数可依。

三类的相对成本

成本差异很大，不能放在同一张日程表上，否则永远在等最长的那一项。

资源体积和压缩：改动小，收益直接，几乎总是值得先做，也是最快能验证的。

缓存策略：配置层面的事，一次做对能长期受益，配错却会让人误以为「优化没用」。

节点和线路：成本最高，往往要等前两类做完才轮到它，除非问题明显是局部的。

一次只改一处

这样改完，功劳和锅都清清楚楚，复盘也方便。

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

哪一段没动，就说明那一项没起效，别在下一次继续保留，也别写进总结里。

什么时候停

知道停在哪，才叫专业，一直加功能不叫专业。

收益递减是正常现象，最后那一点时间往往要花几倍成本，值不值得看业务。

先把业务能感知的部分做掉，剩下的等有明确需求再说，不用一次做完。

优化是为了好用，不是为了把报表做到极致，这两件事经常被搞混。

排序这件事，比堆功能更能体现判断。

判断对了，时间才花得值。

花得值，团队才愿意继续投入。

投入有效，优化才不是一次性动作。

长期看，排序能力比技巧更值钱。

值钱的东西，往往不能速成。

所以先从排瓶颈开始，别急着写方案。

先测一次，方案自然就少了。

少了，执行起来也快。