网站测速看3个数，比跑分总分更实在

跑分网站给的那个总分，说白了就是个平均数大礼包：服务器响应、图片加载、脚本执行、CDN 命中率全塞进一个数字里，最后给你一个看着很舒服的分。舒服完呢，用户点进去还是转圈。我的看法很直接——网站测速看3个数比跑分总分更实在：首字节时间、首屏可见时间、还有最慢的那一次。这三样难看，总分再高也白搭。

网站测速看3个数比跑分总分更实在，先说清是哪3个

第一个是 TTFB，首字节时间。浏览器发出请求到服务器吐出第一个字节，中间那段等待。它基本把服务器、数据库、网络链路一次性暴露出来。有人拼命压图片、合并 JS，结果首字节一直在半秒以上，那前面那些活儿基本等于白干。这个数不用测太多次，在服务器本地用 curl 加 -w 参数打印 time_starttransfer 就能看到，具体写法各家文档里都写着，照抄注意半角引号就行。

第二个是首屏看到东西的时间。跑分工具爱算整页加载完成，包括底部没人翻的懒加载图、统计脚本、评论插件。用户判断快慢的标准很粗糙：点进去，屏幕上有没有像素。所以首屏这个数才对应体感，整页加载完成更多是给工具自己看的。

第三个最容易被跳过：最慢的那一次。测十次算平均，抖动就被吃掉了。真实用户里总有一部分人走烂链路、弱信号、老安卓机，你要盯的是那 10% 的尾巴，不是中位数。那一批人恰恰是骂得最响的。

同一个地址多点几次，波动比数值更要紧

单次测速没什么参考价值。缓存刚预热、CDN 节点就在你家隔壁、自己网络又是千兆，测出来当然好看。我的做法是换网络、换时段、换浏览器，至少三轮，看的是波动。波动大一般意味着系统不稳：数据库慢查询忽高忽低、某个节点抽风、或者同服务器上别的站把带宽吃掉了。测的时候记得开无痕，不然你测的是本地缓存命中，跟服务器没关系。

首字节慢，先别急着加带宽

一看 TTFB 高，很多人的第一反应是加带宽、换机房。先等等。这个数高最常见的原因在应用层：首页查了几十次数据库、查询缓存没开、模板里塞着远程请求、某个插件每次访问都去拉第三方接口。这些跟带宽一分钱关系没有，加多少都不见效。排查顺序我一般这么走：在服务器本地直接请求一次，把 DNS、CDN、外层全绕开，看裸机多久返回。裸机快、外网慢，问题在链路或 CDN；裸机也慢，那就是代码或数据库。这一步能省掉一大半瞎猜，比泡在跑分报告里强。

首屏那一下，常是图片和脚本拖的

首屏慢，多半是这几样：头部轮播原图直出、字体文件阻塞渲染、几个统计脚本排在 head 里同步加载、CSS 里层层 @import。处理办法不复杂——首屏图压一压或者换渐进式格式，非关键脚本挪到页面底部或加 defer，字体用系统字体兜底。这类改动花不了多少工夫，体感变化却很直接。我不太赞成上来就搞重度工程化，先把明显浪费的地方砍掉，比折腾花哨的构建方案有用得多。移动端尤其明显，弱网下几百 KB 的差别就是能看和白屏的差别。

最慢的那批样本，才是你真正在服务的用户

跑分工具喜欢报平均，我喜欢拉长尾。翻请求日志里响应最慢的几条，看地区分布——是不是某些省份一直慢？看设备——是不是老机型一加载脚本就卡住？这些东西综合评分里一个字都不会提。见过一种情况：整体跑分挺漂亮，但部分地区访问一直转圈，根子在 CDN 回源配置，那几个节点老是回源到源站、不走缓存。总分能反映这个吗？反映不了。

别把工具的红线当验收标准

还有一种误区，把某个工具的红线当法律，非得多少分以上才敢上线。工具给的是合成结果，不同平台算法不同，同一站在两个工具上差出十几分很常见。合理用法是把它当体检表：哪一项拖后腿，点进去看具体是哪个请求、哪个资源、哪段服务端耗时，然后回到那三个数上验证有没有改善。测速是为了改，不是为了看分数开心。

一张能照着走的检查单

顺序不复杂：一，服务器本地请求，看裸的首字节耗时；二，挂上 CDN 再测，对比差多少；三，无痕模式测首屏，看第几秒出像素；四，换两三个网络和时段重复，记下波动幅度；五，翻日志挑最慢的十几条，看有没有地区或设备的规律。走完这五步，问题基本能定位到一段代码、一个节点或者一条链路。剩下就是改，改完用同样的项目再对一遍。

分数这东西看着爽，用户不看那张报告。他只知道点进来三秒没反应就退了。把首字节、首屏、最慢样本这三个数记在本子上，每次改动前后对一遍，你会发现能动的地方比想象中多，也更清楚哪些压根不值得动。