CoreDash 对比 Cloudflare Web Analytics
Cloudflare Web Analytics 免费提供真实用户的 Core Web Vitals 数据，总比没有强。但一旦开始排查问题，CoreDash 能做的事多得多。下文会讲清楚具体差异，以及什么时候继续用 Cloudflare 就足够。
Trusted by market leaders · Client results
CoreDash 是我做的，先说明这一点。但我其实挺喜欢 Cloudflare Web Analytics。它免费、不写 Cookie，而且在很多接入 Cloudflare 的网站上，可能根本没人主动配置，它就已经在运行了。
如果它已经在跑，而且能满足需求，继续用就行。你已经在测量真实访客了，很多网站连这都做不到。等你开始遇到它回答不了的问题时，这篇文章才用得上。
Cloudflare Web Analytics 做得好的地方
首先显然是价格。无论用什么 Cloudflare 套餐，Web Analytics 都完全免费，网站甚至不用走 Cloudflare 代理。在走代理的域名上，Cloudflare 会在边缘自动注入 beacon（并附带 SRI）。在 Cloudflare Pages 上，只要点一个开关就行。
cloudflare.com，2026 年 10 月。
测量本身做得很规范。beacon 封装了 Google 的 web-vitals 库，Cloudflare 更新也很及时（更新日志显示 2026 年 9 月 2 日升级到了 v6.2.1）。单页应用先用 Chromium 的 Soft Navigations API，接着是 Navigation API，最后拿 History pushState 做 fallback。一个免费 beacon 能对 SPA 支持到这种程度，出乎我的意料。
Debug View 也很实用。每个指标下都会列出影响最大的前 5 个元素，直接给出 CSS 选择器，并附带各自的 P50、P75、P90 和 P99。对于 LCP，能看到资源 URL 和大小；对于 CLS，能看到发生偏移的元素以及移动前后的位置。你可以按导航类型（包含 bfcache、prerender 和 soft navigations）筛选，过滤 bot 也只需一个开关。GraphQL API 提供的数据比 dashboard 更多：LCP 各子阶段（资源加载延迟、加载时间、渲染延迟）、INP 各阶段（输入延迟、处理、呈现）、LCP 资源的 fetchpriority，以及高达 P99.9 的分位数。
隐私保护同样到位。根据 Cloudflare 文档，它不使用 Cookie、不写入 localStorage，也不做设备指纹追踪，所以通常不需要挂在 consent banner 后面。
比只看 Lighthouse 和 Search Console 强得多
我审计过的大多数网站，平时只看 Lighthouse 和 Search Console。Lighthouse 只是在模拟手机上把页面加载一次，全程没有任何点击，根本测不了 INP。CrUX 只统计同意共享数据的 Chrome 用户，而且只有页面积累了足够的样本才会展示数据（参见 Search Console 数据不足）。Cloudflare Web Analytics 测量的则是实实在在的真实访客。所以如果只能在 Cloudflare Web Analytics 和完全不测之间选，直接打开它。
CoreDash 与 Cloudflare Web Analytics 逐项对比
价格与功能核对时间为 2026 年 9 月。CoreDash 价格为按年计费的月均单价（美元）。
| CoreDash | Cloudflare Web Analytics | |
|---|---|---|
| 产品定位 | Core Web Vitals 监控与调试 | 以隐私为先的流量分析，附带 Core Web Vitals |
| 价格 | 16 美元起（7.5 万次页面浏览，1 个站点），14 天试用 | 所有套餐均免费 |
| 安装方式 | 小于 2 KB 的 script 标签，或使用 WordPress 插件 | 代理域名自动注入，Pages 上一键开启，或手动插入 snippet |
| Cookie | 默认不使用，追踪回访访客时可选 | 无 |
| 指标 | LCP、INP、CLS、FCP、TTFB | dashboard 中展示 LCP、INP、CLS，API 中提供 FCP 和 TTFB |
| LCP 与 INP 各阶段拆解 | 支持，dashboard 与 API 均提供 | 支持，仅在 GraphQL API 中提供 |
| 元素归因 | LCP、INP 和 CLS 元素，LCP 元素类型与优先级，INP 输入类型与加载状态 | 各指标前 5 个元素（含 P50 至 P99），LCP 资源 URL 及大小，CLS 偏移区域（shift rects） |
| INP 脚本归因（LoAF） | 支持 | 不支持 |
| 自定义分群（页面类型、A/B 测试、登录状态、query string） | 支持 | 不支持，不记录 query string |
| 历史数据保留 | 6 个月至 8 年，视套餐而定 | 7 天内未采样，之后聚合至约 10%。dashboard 可查看 6 个月 |
| 欧盟访客 | 所有 RUM 数据均在欧盟境内处理并存储 | 免费代理域名自动开启 RUM 时默认排除 |
| Core Web Vitals 告警 | 自定义告警与 AI 自动告警（AI Auto Alerts），支持邮件和 Slack | 无。仅每周发送一封邮件，汇报访问量、页面浏览量及中位数加载时间 |
| API | JSON-RPC，提供三个工具：metrics、time series、histograms | GraphQL Analytics API，每 5 分钟 300 次查询 |
| MCP | 专属只读 MCP server，与 API 共用端点，所有套餐均包含 | 通过 Cloudflare 通用 API MCP，Agent 需自行编写 GraphQL |
| AI Agent | CWV Superpowers：免费且采用 MIT 协议，根据 field data 直接编写代码修复方案 | 无针对 Core Web Vitals 的工具 |
| 合成测试（Synthetic tests） | 在 CI 中对照性能预算做部署前检查 | Observatory（测试版），付费套餐提供 Lighthouse 测试 |
| 多站点支持 | Agency 套餐支持 10 至 50+ 个客户站点，提供 Agency API | 非代理站点软限制 10 个，代理站点无限制 |
如果你在欧洲网站上跑 Cloudflare Web Analytics，有件事一定要查清楚：当 Cloudflare 在免费的代理域名上自动开启 RUM 时，会直接漏掉来自欧盟、欧洲经济区、英国和瑞士的访客。而且它是按处理请求的数据中心判定的，不管访客实际在哪个国家。我理解他们这么做的原因，但欧洲本地的商家很可能会对着一个丢了大半访客数据的 dashboard 发呆。在相信这些数字之前，先检查这项设置。
Cloudflare Web Analytics 配置文档，2026 年 10 月。
CoreDash 强在哪里
Cloudflare Web Analytics 回答的是“真实访客打开网站到底有多快”，这确实是首先要搞清楚的问题。但用上几个月后，你就会开始问更多问题：哪个脚本拖慢了 INP？上周二发版有没有搞出问题？登录用户的结账流程是不是更慢？今年 11 月和去年 11 月相比怎么样？这些问题，Cloudflare 大多数都给不出答案。
告警
Web Analytics 唯一的通知，就是每周一封汇报访问量、页面浏览量和中位数加载时间的邮件。它没有任何 Core Web Vitals 告警。想发现性能退化，要么碰巧有人打开 dashboard 看一眼，要么等一个月后 Search Console 飘红了才察觉。
CoreDash 提供 两类告警。自定义告警可以按设备、国家、浏览器或页面盯住任意指标的 P75；一旦指标从良好跌入需要改进或差，或者变动幅度超过 25% 或 50%，就会触发告警。AI 自动告警（AI Auto Alerts）只需点一个开关：它每天针对全部 5 个指标排查数百个细分维度，只有当性能退化影响了至少 2% 的流量时才会发出提醒，并注明具体分群和受影响的用户数。两种告警都能推送到邮件或 Slack。CrUX 数据和 RUM 数据也在同一个 dashboard 里，你可以随时把 Google 看到的数据跟真实访客的实际体验做对照。
哪个脚本导致的
遇到 INP 问题，Cloudflare 能告诉你哪个元素慢，还能通过 API 给出时间在输入延迟、处理和呈现上的拆解。但它告诉不了你是哪个脚本干的。它的 schema 里根本没有 Long Animation Frames 相关的字段。而这恰恰是你最需要的部分。点击响应慢，通常是因为某个 tag manager 或客服挂件霸占了 main thread，而按钮本身的 handler 其实一点问题都没有。
当交互触发 long animation frame 时，CoreDash 会通过 Long Animation Frames API 同步记录对应的脚本 URL，让你能够按脚本筛选 INP。你还能获得 input type、INP load state（点击发生时页面是否仍在加载）以及 LCP priority（是 preloaded、fetchpriority high 还是 lazy loading）。各阶段的耗时拆解在 dashboard 和 API 中都有提供，而且 Diagnosis 视图会检查 14 种 LCP 反模式，并针对你的技术栈给出修复方案。
分群与历史数据
Cloudflare 不记录 query string、自定义事件或自定义维度，因此无法按 UTM 参数、A/B 测试版本、页面模板或登录状态来细分数据。而在 CoreDash 中，只需在 snippet 运行前设置一个 window 变量，页面标签、A/B 测试版本和登录状态 就会和 query string 一起成为分析维度。把 5 万个商品页面归入同一个“product”标签，就能为整套模板汇总出一个综合指标。
Cloudflare 的原始 beacon 数据只在 7 天内保留全量未采样。7 天后会被聚合并抽样至约 10%，dashboard 最多支持回溯 6 个月。用来回答“这周表现怎么样”没问题，但如果想拿今年黑五和去年黑五做对比，就无能为力了。CoreDash 的数据保留期更长：Starter 保留 6 个月，Standard 保留 1 年，Studio 保留 3 年，Enterprise 更是长达 8 年。
MCP 与 AI Agent
Cloudflare 之前提供过专属的 GraphQL MCP server，但目前已被废弃，转而推荐通用的 API MCP。这样一来，Agent 只能通过通用的 search 和 execute 工具来读取分析数据，并且得自己手写 GraphQL。虽然能用，但 Agent 在提问前，必须先花功夫搞清楚 RUM 的 schema。
CoreDash 的 MCP server 与 API 共用同一个端点，提供三个工具：get_metrics、get_timeseries 和 get_histogram。你自己写的脚本也是用这三个工具，因此生成的报告和 Agent 看到的数据完全一致。它是纯只读的（完全没有写入接口），并且包含在每个套餐里，Starter 也不例外。把它连到 Claude、Claude Code、Cursor、Windsurf、VS Code 或 Gemini CLI，直接问它这周移动端哪些页面变慢了就行。
另外还有 CWV Superpowers，一个开源免费、采用 MIT 协议的 Agent。它会拉取 field data，定位耗时最长的性能瓶颈，在模拟手机和 4 倍 CPU 降速下录制 Chrome trace，最后直接输出代码修复方案（具体到文件、行号和 diff）或 HTML 报告。里面根本没有 Lighthouse 分数的事。用 AI Agent 修复 INP 展示了它在真实网站上的排查过程。
如果你负责给客户维护网站，Agency API 可以用同样的三个工具读取任意客户项目，而 Agency 套餐 允许多个客户合并共享页面浏览量配额。费用按页面浏览量计算，每个套餐都包含全部 dashboard 功能，更高级别的套餐主要是额度更大、支持站点更多、数据保留时间更长。
什么时候选 Cloudflare Web Analytics 更合适
- 预算为零。Cloudflare 的免费版确实不错。
- 网站本就接入了 Cloudflare，而且它已经在跑了。在买任何付费工具（包括 CoreDash）之前，先看它给出的数据。
- 主要需求是注重隐私的访问量和页面浏览量，顺便看一眼 Core Web Vitals。它本来就是为了这个场景设计的。
- 只是个小型网站，平时没人会每周去排查性能。Debug View 列出的前 5 个元素，往往就能直接揪出拖慢速度的首屏大图。
- 已经买了 Cloudflare Pro 或更高级别套餐，希望将 Lighthouse 测试与 field data 结合起来看。Observatory 刚好能满足。
不妨把两者同时跑跑看
你完全可以两个一起跑。Cloudflare 免费，而 CoreDash 提供 14 天免绑信用卡的试用，在同一个网站上跑两周不需要花一分钱。接着在两边同时打开最慢的页面，看看究竟哪一个能说清为什么慢。想先看看 dashboard 长什么样？可以直接体验 CoreDash demo，并根据流量查看 价格方案。其他工具的对比可以查看 对比汇总页面。
参考来源：关于 Web Analytics、Web Analytics 中的 Core Web Vitals、Web Analytics 常见问题、配额限制、更新日志、通知设置、RUM beacon、Observatory 测试、GraphQL API 配额限制、Cloudflare MCP servers。