Core Web Vitals：Search Console 提示数据不足

“使用情况数据不足”是什么意思

Search Console 里的 Core Web Vitals 报告，展示的是真实 Chrome 用户访问你页面时的体验。只要有人用 Chrome 打开你的某个页面，而且设置符合条件，这次访问的 LCP、INP 和 CLS 就会发给 Google，最后进入一个公开数据集：Chrome 用户体验报告（Chrome User Experience Report），简称 CrUX。Search Console 从这个数据集读数据，再展示给你。所以和大多数人以为的不同，Search Console 不会去访问你的网站来测量。它只是收集真实用户数据。

如果你的页面这类访问不够，就没东西可展示。这时你会在移动端或桌面端看到“过去 90 天内此设备类型的使用情况数据不足”，有时两个都有。

有人把这当成坏信号。但没有数据，说明不了你的网站是快是慢。只是 Google 看到的访客太少，下不了结论。

为什么 CrUX 没有你网站的数据

主要原因是流量。CrUX 只报告“足够热门”的页面或源（origin，即协议加域名，例如 https://www.example.com）。具体标准是什么，Google 没说。方法论页面只说，阈值高到足以保证分布数据可信。

而且你的访客里，本来就只有一小部分能计入这个阈值。CrUX 只收集这样的 Chrome 用户：开启了使用情况统计，同步了浏览历史，没有设置同步密码。也就是桌面版 Chrome 和 Android 版 Chrome。iPhone 上的 Chrome 不算（它底层是 WebKit，和 Safari 一样）。Safari 本身、Firefox、Edge，还有 Instagram 应用内置的浏览器，也都不算。如果你的网站 iPhone 流量很大，大多数访客根本进不了这个数据集。移动端和桌面端也是分开统计的。所以可能桌面端有数据、移动端没有，也可能反过来。哪个设备的 Chrome 流量最少，哪个就先变空。

然后页面本身也要符合条件。重定向之后返回的不是 200，就会被跳过。带 noindex meta 标签或 X-Robots-Tag: noindex 响应头的页面，同样会被跳过。Search Console 在这之上还有自己的规则：只有真正被索引的 URL 才会出现在报告里。

如果你刚把这个资源添加到 Search Console，本来也会有一段时间什么都不显示。这个不用管，等 Google 处理完就好了。

没有数据的页面，用的是源的分数

Search Console 也不按单个页面报告，而是把相似的 URL 归成一组。如果某个组自己的数据不够，Search Console 会 fallback 到源，也就是同一协议、主机和端口下的所有 URL。所以一个 CrUX 从没见过的页面，照样可能在你的报告里显示为“良好”或“较差”。因为它借用的是网站其他部分的数字。

实际情况是，首页和博客拿走了大部分流量，源的数字就由它们决定。你的产品页或结账页可能慢得多，你在 Search Console 里永远看不到。这也是我从不把全站 CrUX 数字当目标的原因。它按流量加权，由最繁忙的页面决定，而这些页面不一定是你关心的。

Lighthouse 在这里帮不上忙

到处都能看到同一条建议：反复跑 PageSpeed Insights 或 Lighthouse，直到 CrUX 数据出现。我理解为什么有人这么说，但这给不了你需要的东西。Lighthouse 跑一次，就是在一台模拟手机上，用限速网络和空缓存，把你的页面加载一遍。用来找页面本身的问题没问题，但它反映不了你的访客实际拿到的体验。

比如 INP，需要真人在真实设备上点击和触摸。Lighthouse 什么都不点。再比如 CLS，Lighthouse 在页面加载完就不看了。晚到的广告把内容往下推，访客滚动时有东西跳动，这些都不会出现在报告里。LCP 取决于手机、网络，以及访客离你的 CDN 有多远。一次测试，这三样各只有一种。

只有流量在增长，等待才有用。CrUX 看的是最近 28 天的访问（顺便说一句，实际延迟比大家以为的短得多，见为什么 28 天延迟是个误解）。这个月符合条件的 Chrome 访问不够，下个月多半也不够。

用 RUM 测量你自己的访客

另一个办法是自己测。真实用户监控（Real user monitoring，RUM）会在每个访客的浏览器里运行一个小脚本，测量这次访问的 Core Web Vitals，然后把数字发给你，而不是发给 Google。和 CrUX 一样是 field data，只是不再有阈值要达到，也不局限于 Chrome 用户。

一个月只有 50 次访问的页面，也有数据。你的 iPhone 访客也一样：从 Safari 26.2（2025 年 12 月）开始，Safari 能测量 LCP 和 INP，所以这些访客会出现在 RUM 里，而 CrUX 仍然把他们排除在外。你还能看到是哪个元素造成了糟糕的数字：哪张图片是 LCP，哪个按钮响应慢。部署之后，几分钟内就能看到效果，而不是埋在某个 28 天平均值里。

Core/Dash 就是我为此做的 RUM 工具。一个 script 标签，或者装上 WordPress 插件，第一次页面浏览就开始有数据。它不设置 cookie，不收集个人数据，所以不需要同意弹窗。对小网站来说这很关键。放在同意弹窗后面的 RUM 脚本，只能测到点了“接受”的人，你又回到了只覆盖一小部分访客的局面。套餐每月 16 美元起（按年付费），14 天试用无需信用卡。

CrUX 开始收录你的网站之后，也要继续跑着。Search Console 只显示 URL 组，永远不会告诉你是哪个页面、哪个元素让一个组变慢。

现在就查查 CrUX 里有你的什么数据

改任何东西之前，先查一下 CrUX 里到底有没有你的源。corewebvitals.io 上的 CrUX History 工具可以查任何网站的 CrUX 历史数据。如果那里移动端是空的，Search Console 里也会是空的。

另见：安装 Core/Dash；浏览器维度，查看 CrUX 漏掉的访客；设备类型维度，区分移动端和桌面端。

来源：Search Console 帮助：Core Web Vitals 报告、CrUX 方法论、Safari 26.2 新增 LCP 和 INP。