CoreDash vs CrUX 和 Search Console
做性能，所有人都该从 Google 的免费 field data 开始。本文讲清 CrUX、PageSpeed Insights 和 Search Console 擅长什么，以及什么时候才值得为真实用户监控付费。
Trusted by market leaders · Client results
拿 CrUX 来对比其实有点奇怪，因为它根本算不上竞争对手。CrUX、PageSpeed Insights 和 Search Console 本质上是同一份 Google 免费数据集在三个地方的呈现，每个站长都该看。我看任何网站第一件事都是查它，哪怕已经用了 CoreDash 的网站也不例外。
真正的问题在于，这些免费数据对你的网站到底够不够用。CoreDash 是我做的，先说明这点。但 Google 的数据确实出色，我们先从它讲起。
Google 免费 field data 擅长什么
它完全免费，而且无需安装。Chrome 会收集授权用户的 LCP、INP、CLS、FCP 和 TTFB，Google 再把结果汇总发布为 Chrome UX Report。PageSpeed Insights 会把这份数据展示在 Lighthouse 运行结果上方。Search Console 将数据归入 URL 分组，并为修复提供 28 天的验证流程。CrUX Vis 则展示过去 40 周的周趋势。它替代了 Looker Studio 仪表盘（Google 已于 2025 年 11 月底将其下线），可读性要好得多。
developer.chrome.com，2026 年 10 月。
CrUX 也是 Google 搜索在考察 Core Web Vitals 时所用的数据集。所以当客户问“我们达标了吗？”，所有人看的都是它，连他们的 SEO 代理机构也不例外。没有任何 RUM 工具能替代这一点，CoreDash 也没打算去替代。（Google 也说过分数好不保证排名，这话值得转告客户。）
它适用于任何公开网站，包括你的竞争对手。花一下午时间，你就能拉出所在赛道每家店铺的数据。RUM 工具只能测量植入了脚本的网站，因此做竞品对标和潜在客户调研时，CrUX 显然是不二之选。
BigQuery 的数据可追溯至 2017 年，提供每个 origin 的按月数据。History API 提供 40 周的历史周期。2026 年 8 月发布的数据覆盖了 1830 万个 origin。
而且 Google 一直在追加新功能。自 2025 年 1 月起，CrUX 将 LCP 拆分为多个子阶段（TTFB、resource load delay、resource load duration、element render delay），并告诉你 LCP 到底是图片还是文本。2026 年 9 月又新增了实验性广告指标。官方 Chrome DevTools MCP server 现在默认会将 CrUX field data 注入 performance trace，让 AI agent 在查看 lab trace 时直接看到 Google 的 p75。CrUX API 完全免费，每个 Google Cloud 项目每分钟可查询 150 次，大量第三方工具都构建于其上。
先从这里起步，再测自己的访客
如果你还没有任何真实用户监控，CrUX 就是你的 field data。光凭这一点，你就已经领先于那些只盯 Lighthouse 分数的团队了。我见过有团队为 PageSpeed Insights 拿到 98 分欢呼雀跃，而他们产品页的 field INP 实际上表现极差。Lighthouse 只加载一次页面，中途什么都不点；任何真实用户数据，能告诉你的都远比它丰富。
另外，有 RUM 工具总比没有强。如果你已经在用，而且它能解答你的疑惑，那你不必读这篇文章。本文是写给两类人的：免费数据已无法满足需求的人，以及网站根本没有进 CrUX 的人。
CoreDash 与 Google 免费数据横向对比
价格与功能核对时间为 2026 年 9 月。
| CoreDash | CrUX、PageSpeed Insights、Search Console | |
|---|---|---|
| 价格 | 年付每月 16 美元起（7.5 万次 pageview）。14 天试用期，免信用卡 | 免费。BigQuery 在每月免费额度内免费 |
| 接入方式 | 一个 script 标签或 WordPress 插件 | 无需安装。Search Console 需要验证网站所有权 |
| 测量对象 | 只要加载了脚本的每位访客都会统计，支持所有兼容相应指标的浏览器 | 桌面端和 Android 端授权同意的 Chrome 用户。不包含 iOS、Safari、Firefox 或 Edge |
| 最低流量 | 无 | “足够热门”的页面和 origin。阈值未公开 |
| 时效性 | 几秒内即可看到 pageview | 每日更新的 28 天滑动 p75（API、PSI）。History API 按周更新。BigQuery 按月更新 |
| 最细粒度 | 每个 URL，以及单次 pageview | 流量足够时精确到单个 URL，否则退化为 origin。Search Console 展示 URL 分组 |
| LCP 归因 | 具体元素、元素类型、图片 URL、preload 与 priority 状态、四个阶段 | p75 下的四个子阶段，且仅包含完整页面加载时的图片 LCP。无元素信息 |
| INP 归因 | 具体元素、输入类型、加载状态、LoAF 脚本 URL、三个阶段 | 无 |
| CLS 归因 | 发生偏移的元素、原因及发生时机 | 无 |
| 细分维度 | 25+ 个维度，包括页面标签、登录状态、A/B 测试版本、国家和设备性能 | 设备形态（手机、桌面端、平板）。国家维度仅在 BigQuery 月度表中按 origin 提供 |
| 历史数据 | 6 个月到 8 年，视套餐而定 | History API 提供 40 周。BigQuery 可追溯到 2017 年的 origin 月度数据 |
| 告警通知 | 支持通过邮件和 Slack 发送自定义告警与 AI Auto Alerts | Search Console 会就新增的 Core Web Vitals 问题给站长发邮件。无自定义阈值 |
| API 与 MCP | 基于你自身数据的 API 和只读 MCP server，统一接口 | 免费的 CrUX API 和 PSI API。Chrome DevTools MCP 可将 CrUX p75 注入 lab trace |
| 他人网站 | 不支持，仅限运行了脚本的网站 | 支持，任何公开的 origin |
CoreDash 补充了什么
免费数据非常擅长告诉你是否达标。可一旦开始动手修复，你就需要另外一些答案：哪个元素慢、哪个脚本阻塞了点击、昨天的 deploy 有没有让情况变糟。CrUX 根本就不是为了解决这些问题设计的。它是一套公开、匿名的 p75 数据集，也正因如此，Google 才能免费向数百万个 origin 开放。
CrUX 漏掉的访客和页面
CrUX 只统计桌面端和 Android 上的 Chrome 用户，且要求用户开启使用统计、同步浏览历史且未设置同步密码短语。iPhone 上的 Chrome 不算在内，Safari、Firefox 或 Edge 同样不算。不仅如此，页面还必须公开、可被索引，且访问量足够大。需要登录的页面直接被排除在外；而对于自身数据不够的 URL 分组，Search Console 会 fallback 到 origin 的分数。对很多网站来说，这意味着屏幕上只会显示“使用情况数据不足”（我写过文章解释为什么会这样）。
developer.chrome.com 上的 CrUX 方法论，2026 年 10 月。
只要运行了脚本，CoreDash 会测量每一次 pageview。月访问量只有 50 次的页面能拿到数据，iPhone 访客和已登录的用户也一样。它默认不设置 cookie，也不收集个人数据，因此你不需要授权弹窗，测到的也不会只是那些点了“同意”的人。
该修复哪个元素
这也是我平时工作中最需要的。CrUX 会告诉你某个 URL 的 LCP 在 p75 时是 3.4 秒；2025 年起，它还能告诉你大部分时间花在 resource load delay 上。确实有用。但它不会告诉你具体是哪张图片、在哪个模板上，也不会告诉你是不是又有人在 hero 图上加了 loading="lazy"（这种事我每隔几周就会碰到一次）。
至于 INP，CrUX 只给你一个数字就完事了。点的是哪个按钮？哪个脚本在运行？点击发生时页面是不是还在加载？全不知道。绝大多数 INP 优化就卡在这里：明知道指标差，却根本无从下手。
CoreDash 会记录每一次 LCP、INP 和 CLS 背后的具体元素。针对 LCP，你还能拿到元素类型、图片 URL 以及 LCP 优先级（preloaded、fetchpriority high、未 preload 还是 lazy loaded）。针对 INP，你能获取输入类型、加载状态以及阻塞了 main thread 的 Long Animation Frame 脚本。所有这些数据，你都可以按页面标签、登录状态、A/B 测试版本、国家或设备性能自由拆分下钻。Diagnosis 视图会检测 14 种 LCP 反模式，并针对你的技术栈给出修复建议。
上线当天就能看到变化
CrUX 数据其实只滞后一两天（所谓的“28 天延迟”纯属误解）。但它算的是 28 天的 p75，所以上线修复后，数字每天只能挪动一点点，整整四周后才能完全显现。单个模板上的性能衰退，会被全站数据直接抹平。Search Console 确实会发邮件提醒新问题，但前提是 28 天的综合数字变化幅度足够大，以至于改变了某个 URL 分组的状态。
在 CoreDash 中，一次 deploy 的影响几小时内就会体现在时序图里。通过 CI 配置 Release tagging，可以直接把每次 release 的 p75 与上一版本并排对比。AI Auto Alerts 每天巡检数百个细分维度，只有当性能衰退波及至少 2% 的流量时才会报警，同时列出具体指标、受影响的维度以及波及的用户数。
让 AI agent 读取你自己的 field data
CrUX API 很适合写脚本，Chrome DevTools MCP server 也能让 agent 在查看 lab trace 时拿到 Google 的 p75。但说到底，这依然只是来自授权 Chrome 用户的页面级或 origin 级数字。
CoreDash 的 MCP server 与 API 共用同一个接口，且设为只读。Claude、Cursor 或任何其他 agent 都可以查询 p50 到 p95 之间的任意指标，并按任意维度过滤与分组。“德国移动端产品页上哪个 LCP 元素最慢”，只需一次调用就能拿到。CWV Superpowers 是一个基于 MIT 协议开源的免费 agent。它以这份 field data 为起点，开启移动端模拟、Fast 3G 和 4 倍 CPU 降速录制 Chrome trace，最终输出代码修复方案（具体到文件、行号和 diff）或 HTML 报告。完全不看 Lighthouse 分数。用 AI agent 修复 INP记录了一次真实运行过程。
代理机构可以使用 Agency API，凭一把主密钥即可创建客户项目，并通过同样的三款工具读取全部数据。价格仅随流量增加，所有套餐都能使用全部仪表盘；代理商 Studio 套餐年付每月 71 美元，可覆盖 10 个客户网站。
什么时候只用免费数据就够了
- 你想知道 Google 如何看待你的网站。从定义上讲这就是 CrUX，无论你还上了什么监控，都该一直关注它。
- 你在做竞品或潜在客户对标。对于非自己所有的网站，CrUX 是你唯一能拿到的 field data。
- 你要跨站点或跨年份做宏观研究。BigQuery 能追溯到 2017 年的数据无可匹敌，且在免费额度内完全免费。
- 网站在移动端和桌面端都已达标，核心页面都有各自独立的数据，而且前端极少变动。
- 你无法在网站中植入脚本。
- 完全没有预算。CrUX 加上在待修复页面上跑一次 Lighthouse，是非常合理的配置，远比瞎猜强得多。
两者都用
我建议两者都用。CoreDash 提供了 CrUX 交叉对照功能，把 Google 的数字与你自己的 RUM 数据并排展示，让你既能看到 Google 看到的结果，又能查明背后的成因。你也可以在 corewebvitals.io 上通过 CrUX History 工具免费查看任何网站的 CrUX 历史走势。
试用期 14 天，无需信用卡，从第一次 pageview 开始就有数据。想先看看仪表盘可以体验 demo，或者按你的流量核算价格，也可以查看所有对比。
资料来源：CrUX 方法论、CrUX 指标、CrUX API、CrUX History API、BigQuery 上的 CrUX、CrUX 发布说明、CrUX Dashboard 废弃说明、CrUX 广告指标、关于 PageSpeed Insights、Search Console 的 Core Web Vitals 报告、Google 搜索与 Core Web Vitals、Chrome DevTools MCP server。