网站优化查询工具！先查这4个指标

网站优化查询工具这东西，浏览器里搜一下能翻出一大堆，评分从 A 到 F，红黄绿三色条拉满，看着挺专业。我早些年也天天盯着那个总分看，后来发现同一个站扔进两家工具，一个说你优秀，一个说你危险，权重算法压根不是一套东西。总分是给别人看的，那四个指标才是给自己看的。把这几项拉出来扫一遍，问题基本就锁定在哪个环节了，剩下的都是顺藤摸瓜的事。

网站优化查询工具里最该先看的一个数：TTFB

TTFB，首字节时间。说人话就是浏览器发出请求之后，服务器磨蹭了多久才吐出第一个字节。这个数难看，后面全都白搭——资源压得再小、前端写得再漂亮，用户还是在那儿干等。业内常用的参考线大致是几百毫秒以内算舒服，超过一秒就得回去查后端了，不同工具的口径不太一样，以它自己的说明为准。

命令行怎么测，一条就够：curl -o /dev/null -s -w “%{http_code} %{time_starttransfer}\n” https://你的域名/ ，跑个五六次取中间那几次看，别跑一次就下结论。如果数值忽高忽低，多半不是代码问题，是带宽或者线路在抖，这种情况你改代码改到天亮也没用。

TTFB 偏高的时候，很多人第一反应是上缓存、上 CDN。方向不算错，但顺序不对。先看数据库有没有慢查询，看 PHP 进程是不是被占满，看是不是有个接口在同步调外部服务。这些东西不解决，缓存只是把慢的东西提前存了一遍，命中率一掉照样原形毕露。

首屏资源体积和请求数，手机用户感受最直接

查询工具一般都会给一张资源瀑布图，密密麻麻那一排就是请求。请求数多不怕，怕的是每一个都又大又慢。最典型的就是图片——后台直接上传原图，一张三四千像素宽的照片原封不动挂在列表页上，桌面看还行，手机走 4G 就是煎熬。压一下、转成 webp、按显示尺寸裁剪，这三步做完往往立竿见影。

还有一个容易被忽略的是字体文件。中文站用自定义字体，一个文件动不动就几 MB，为了几个标题字加载一整套字库，这笔账怎么算都不划算。第三方脚本同理，统计、客服、地图、弹窗，每一个都在抢带宽和主线程，数量一多，工具里的评分再好看也没用。

跳转链和状态码，一次点击别跑三趟

http 跳 https 一次，裸域跳 www 再一次，末尾少了斜杠再跳第三次。每多一跳就多一个来回，用户没感觉，但对移动端和弱网来说这几百毫秒是实打实的。查询工具里的 redirect chain 那一栏，正常应该是一跳到位，出现两条以上就该去服务器配置里捋一捋了。

顺便看下有没有 404 的内链和死链。这个不光是体验问题，搜索引擎爬到一堆 404 也不是什么好事。工具里一般会单独列一页，处理起来不费劲，就是得有人去做。

核心网页指标，LCP 好看不代表就没事

LCP 是大内容渲染时间，也是最常被拿出来说的那个。但它好看不代表整体就顺，CLS 布局偏移这个数经常被忽略——图片没写宽高、广告位和弹窗后插进来，页面在加载过程中上下窜，用户手指刚要点上去，元素跑了。这种体验上的膈应，评分可能只扣几分，转化上的损失却实打实。

还有 INP，衡量交互响应。按钮点下去半天没反应的站点，多半是主线程被一堆脚本占住了。这个靠前端优化能解决一部分，靠减少第三方脚本能解决一大半。

缓存命中率和回源，别让 CDN 白挂

挂了 CDN 不等于万事大吉。看回源请求比例，看静态资源的缓存时长设置。图片、CSS、JS 这类带版本号的资源可以放长缓存，HTML 就得短一些，不然改了内容用户看不到。有些站点命中率一直上不去，查到最后是 URL 上带了随机参数，每次请求在 CDN 眼里都是新资源，等于白挂。

另外一个坑是回源带宽。缓存没命中的那部分请求，全砸在源站上，高峰期源站一卡，前面所有的优化都抵不过这一次雪崩。这块建议盯着监控看一段时间，别凭感觉。

查完先别动手，按这个顺序改最省力

顺序错了，力气全白费。先动服务器和数据库，把 TTFB 里的水分挤掉；再动资源，压缩、合并、懒加载；然后才是前端渲染和布局；第三方脚本放最后，能砍的砍，砍不掉的异步加载。反过来先改前端，后端该慢还是慢，用户感知不到任何变化，改的人还挺累。

改完别急着庆祝，隔一天再拿同一套工具跑一遍，对比着看。有变化就说明改对了，没变化就说明前面判断错了——这种情况不丢人，返工比一直猜要快。

最后还是那句话，查询工具给的分只是个参考坐标，它不知道你的业务是卖货还是展示，也不知道你的用户是刷手机还是坐办公室。四个指标看下来，真正要动手的地方你自己心里就有数了。工具是拿来用的，不是拿来刷分的。