一句话「都慢」，先拆开

客户说整个网站都慢。我问他：哪个页面最慢。他说都慢。

后来分开测，首页正常，列表页两秒，详情页五秒，登录接口八秒，差别大得离谱。

为什么必须按路径分

不同页面的代码路径、数据库查询、缓存策略都不一样，慢的原因自然也不同。

首页可能纯静态，详情页要查三张表，登录还要同步调外部服务，重量差好几倍。

混在一起看，只能得到一个平均值，而平均值恰恰会把最严重的那一页抹平。

分诊怎么做

方法很土，但非常有效，比重构一遍便宜太多。

先列出四条关键路径：首页、列表、详情、登录，覆盖大多数用户的操作。

每条单独测一次，用同一组节点，条件一致结果才有可比性。

用宝塔拨测的网站测速分别跑这几个地址，看 DNS、TCP、TLS、TTFB、下载五段是否一致，差异往往一眼就出来。

结果怎么读

四条对比着看，答案基本就出来了，也不用再猜。

四条路径 DNS 和连接都很快，只有 TTFB 差异大：问题在后端逻辑，不在网络。

只有详情页慢：去看那条查询和关联数据量，慢查询大多藏在这里。

只有登录慢：先看外部调用和会话锁，这两处最容易卡出几秒钟。

四条路径下载段都很大：资源体积是共性问题，先做压缩和懒加载。

分组再确认一次

范围不清，优先级就排不出来，团队也只能瞎忙。

按地区和运营商分组，确认慢是不是只出现在某些用户那边，这一步能定范围。

共性的慢，全网都会中；局部的慢，只是某些链路，改法完全不同。

这两类的处理优先级完全不同，混起来做容易两头不到位。

复测与动作

一次只改一条路径，效果才看得清，也方便回退。

改一处就复测同一路径，别拿别的页面来证明，那样等于自欺欺人。

连测三次，稳定改善才算有效，一次可能是刚好不忙。

把「路径、耗时、改动」记成一列，下次同类问题能照着做，不用重新摸索。

分路径这一步做对，后面全是顺着走。

顺着走，比乱试省时间。

省下的时间，可以多测两条路径。

多测两条，覆盖就更全。

覆盖全了，漏掉的概率就低。

漏得少，用户投诉就少。

投诉少了，优化才有意义。

有意义的事，才值得重复做。

重复下来，判断就练出来了。

练出来，就不用每次都试错。

不试错，效率自然高。

效率高了，团队就好过。

好过，才有人愿意留下。

留下的人多了，经验才留得住。

留得住，就不用反复踩坑。