自建 RUM 和 CrUX 对不上：三处口径差异，以及该信哪一个

2026-10-24 约 1,845 字预计阅读 5 分钟 yiyunkj

做性能优化的人大概都经历过这个时刻：本地跑 Lighthouse 是 95 分，自己埋点看真实用户数据是 1.8 秒，结果 Search Console 里的 Core Web Vitals 报告一片黄。

第一反应通常是「数据错了」。但三套数据都没错，它们测的是不同的东西。

自建 RUM 数据与 CrUX 报告的三处口径差异对照示意图

图片来源：网络，版权归原作者所有，侵权请联系删除

先把三套数据的定位说清楚

实验室数据是单次模拟，重复跑几次取中位数就能稳定，适合用来发现问题和验证改动。后面两套都是真实用户数据，但对不上。

CrUX 报告的是第 75 百分位（p75），而且是滚动 28 天的汇总。你自建 RUM 如果看的是平均值或者中位数，数字必然会低。

p75 的意思是：75% 的访问比这个数快，25% 比它慢。平均值会被大量快速访问拉低，中位数（p50）则直接砍掉尾部那 25% 的慢用户——而那 25% 恰恰是 CrUX 判定「不达标」的依据。

这是最常见的一处差异，也是最容易自己查出来的。把自建 RUM 的看板改成 p75，时间和范围也对齐 28 天滚动，两边通常能靠近一大截。

CrUX 只包含满足条件的 Chrome 用户。几个具体限制：

你的自建 RUM 统计的是所有访问：全浏览器、全地区、包含那些装着一堆插件、用着老机器、连着弱网的用户。

反过来说，CrUX 的样本也可能包含你 RUM 里没有的东西：比如从 Google 搜索结果点进来的那批用户，设备分布和你站内的老用户不一样。入口不同，人群就不同。

这一处最隐蔽，也最容易被忽略。

LCP 元素可能不同。你埋点采的是页面上最大的那个元素，浏览器采的也是。但如果页面有懒加载、有延迟插入的内容，两边的判定时间点会不一样。官方的 web-vitals 库和浏览器原生 API 在这一点上是一致的，但自己手写的采集逻辑未必。
跨页面导航的处理。LCP 应该在页面隐藏或首次交互时停止采集并上报。如果你的代码在页面卸载时才上报，会漏掉一批。
预渲染和后台标签页。页面在后台标签页打开时，LCP 的计时起点不同。开了预渲染的话，实际渲染时间可能被算到之前。
INP 需要真实交互。没有交互的访问不产生 INP。如果你的 RUM 把「无交互的访问」当成 0 填进去了，平均值会被严重拉低。

修法很直接：别自己写采集逻辑，用官方的 web-vitals 库。它处理了上面这些边界情况，也和 CrUX 用的是同一套定义。自己手写省下的那点代码量，抵不上后面排查口径的时间。

不是二选一，是两个用在不同地方：

判断「达标不达标」，看 CrUX。它是被 Core Web Vitals 报告采用的那个口径。你的 RUM 说 1.8 秒，但 CrUX 说 3.2 秒，那在报告里就是不达标。
定位和修复问题，看 RUM。CrUX 只给一个汇总数字，不给维度。你想知道「是不是某个地区的用户特别慢」「是不是某个分类页拖了后腿」，只能靠 RUM 的细分维度。
验证改动有没有效果，看实验室数据加 RUM 短期对比。Lighthouse 跑三五遍取中位数，看单次改动的相对变化；RUM 看改动上线后一周的 p75 趋势。CrUX 要等 28 天滚动才会完全反映，不适合用来快速验证。

两边差太多的情况下，按这个顺序查：

先把 RUM 的统计口径改成 p75，对齐 28 天窗口，看差多少。
再看分组：把 RUM 按浏览器分组，只看 Chrome，数字会往 CrUX 靠。
再看页面级 vs 来源级：CrUX 有页面级和整站（origin）两种粒度，Search Console 里是按页面组展示的。别拿整站 p75 去对某个页面的数据。
最后查采集逻辑：换成官方 web-vitals 库，对比一周。

三处都对齐之后，两边通常能收敛到 10% 到 20% 以内，剩下的差异来自样本本身，不用再追。

CrUX 数据有 28 天的滞后，意味着你今天做的优化，最快也要一个月才在报告里完全体现。所以别指望改完第二天 GSC 就变绿——那段时间里，RUM 是你唯一能用的实时反馈。