平均 180 毫秒，客户还说慢

一次交付，报告里平均耗时一百八十毫秒，看着挺漂亮。客户回了一句：我们那边还是慢。我当时还觉得是对方网络问题。

把结果按地区展开才发现，有几个省的节点接近一秒。平均值把它们平均掉了，也把我自己的判断带偏了。

平均数会盖住什么

平均数和最慢值，本来就是两个用途，硬要二选一，怎么选都不对。

平均是除法，节点越多，单个异常越容易被稀释，三五十个节点里混一个坏的，几乎看不出来。

十个节点九个快、一个特别慢，平均依然好看，可那一个省的客户天天在骂。

最慢节点正好相反，它会把偶发的一次抖动放大成「全局故障」，容易让人过度反应。

所以两个数要一起看：平均看整体水平，最慢看风险敞口，两者缺一个判断都会偏。

真正能定位的是五段

这五段不是学术划分，是排查顺序，按它走能少绕很多弯。

DNS：解析花了多久，这一段的耗时跟服务器性能没关系，长就是解析链路或缓存的问题。

TCP：建连耗时，长说明网络绕行，或者服务端 accept 队列排满了。

TLS：握手耗时，长说明证书链不完整、加密套件不匹配，或者机器算力跟不上。

TTFB：首字节时间，这是最能指向服务端的一段，长就说明在排队、在查库、在处理。

下载：内容传输耗时，长说明带宽不够、资源太大，或者中间链路在丢包重传。

五段加起来不一定等于总耗时，中间还有排队和重定向，但哪一段异常，一眼就能看出来。

我的判断顺序

先具体，再分布，最后看影响面，这个顺序我用了几年，基本没失手。

先看最慢的那个节点卡在哪一段，这是最具体、最不容易被误导的信息。

再看这段异常是不是集中在某些运营商或地区，分布比单个数字有说服力。用宝塔拨测的网站测速按运营商和地区分组，分布一目了然。

最后看平均有没有被拖累：平均也高了，说明影响面大；平均没变，基本是局部问题，别按全局故障处理。

别急着改，先复测

不复测就动手，多半是在赌运气，赌输了还要重来一遍。

多节点结果本身有波动，单次最慢可能是抖出来的，尤其是跨运营商的那几个节点。

连续复测两三次，确认那个节点每次都慢，才算稳定现象，一次的结果没法当证据。

改完一处，再用同一组节点测同一段耗时。不然改了半天，也不知道是改动起效，还是波动刚好过去了。

这两件事想明白，测速报告才不是摆设。