Lighthouse 98 分，Search Console 还是红的：到底该信哪个数据
L
几乎每个做过性能优化的团队都会吵一次这个架。开发说我本地跑出来 98 分，SEO 说 Search Console 里一片红。两边都没撒谎，只是看的不是同一个东西。
图片来源：网络，版权归原作者所有，侵权请联系删除
两个数据源的本质区别
实验室数据（Lighthouse、PageSpeed Insights 下半部分、WebPageTest）是一次模拟加载。固定的设备档位、固定的限速、清空的缓存、没有真人操作。它可重复，所以适合放进 CI 里防回归。
现场数据（CrUX，Chrome 用户体验报告）是真实 Chrome 用户过去 28 天的访问记录，取 75 分位。它不可控，但它是 Search Console 里 Core Web Vitals 报告的数据来源，也是页面体验信号真正看的东西。
Google 自己的说法很直接：如果一个页面同时有现场数据和实验室数据，优先看现场数据。而 Lighthouse 的性能总分"经常跟现场的 Core Web Vitals 不相关"。
为什么会打架
最常见的原因有四个。
INP 在实验室里压根测不出来
INP 是交互到下次绘制的延迟，它需要一个真人真的去点一下。Lighthouse 里没有真人，所以它用 TBT（总阻塞时间）当替代品。这两个指标相关但不相等，一台设备上 TBT 180ms、真实用户 INP 520ms 是很常见的事。
你的用户设备比模拟器差
实验室测的是一台模拟的中端机配限速 4G。真实用户里有相当比例用的是更老的机器、更差的信号。而且现场数据看的是 75 分位——不是平均值，是最慢的那四分之一。中位数好看没用，尾部难看就是不合格。
第三方脚本在实验室里不真实
实验室加载页面时，统计、广告、客服挂件虽然也会请求，但累积起来的主线程占用跟真实环境差得远。真人的浏览器里往往同时跑着五到十几个第三方脚本，中低端机上每一个都能吃掉几十毫秒。
页面级和整站级是两回事
很多工具默认给的是整站（origin）级别的聚合值。这个值通常好看得多——有研究统计过，按单个页面算通过全部三项 Core Web Vitals 的只有约 21%，而按整站算有约 33%。整站通过不代表你那个最慢的分类页通过了。
目录站该看哪个
结论是：判断优先级看现场，找问题看实验室。
具体流程这样走：
- 打开 Search Console 的 Core Web Vitals 报告，看是哪一组 URL、哪一项指标不达标。报告会按 URL 分组，移动和桌面分开
- 拿到出问题的那组 URL，挑两个代表页面进 PageSpeed Insights，同时看上半部分的现场数据和下半部分的实验室诊断
- 用实验室数据定位到具体元素（哪个是 LCP 元素、什么在阻塞渲染、哪段 JS 占主线程），改
- 改完先在实验室里验证，然后等 28 天看现场数据变化
最后一步最容易让人放弃。现场数据是滚动 28 天窗口，今天上线一个优化，一个月后才能完整反映出来。很多团队两周看不到动静就判定"没用"，实际上只是数据还没滚过去。
流量不够就没有现场数据
这是个现实问题。CrUX 对单个 URL 有流量门槛，大约每月一千次访问左右，达不到就不给页面级数据，回退到整站级；整站也不够的话，就完全没有 Core Web Vitals 信号。
目录站恰好容易踩中这个情况：条目页成千上万个，流量摊薄之后每个页面都不够门槛。这时候有两个办法：
- 按 URL 分组看。Search Console 会把相似的 URL 归成一组，组内的聚合数据通常够用
- 自己做 RUM。用
web-vitals这个库在前端采集真实指标，上报到你自己的统计里。几行代码的事，比等 CrUX 快得多
三个常见误解
移动和桌面分开评估。只看桌面数字会给自己一个虚高的印象，两个是独立判定的。
三项全绿才算通过。LCP、INP、CLS 里有一项落在"需要改进"区间，整体就是不合格。
实验室分数不进排名。它只是诊断工具。把优化目标设成"Lighthouse 跑满 100 分"，方向就已经偏了——应该盯的是现场 p75。