tech

Cloudflare Web Analytics：免费、无 Cookie 的网站分析与真实用户性能监控

📅 2026/7/21 👁️ 10 阅读 ✏️ 2026/7/21 更新

Cloudflare Web Analytics：免费、无 Cookie 的网站分析与真实用户性能监控



来源：机器之心 · 2026年7月




网站上线后，有两个问题绕不开：谁在访问？ 以及 访问体验怎么样？

Google Analytics 4 确实强大，但配置复杂、合规成本高。如果你只是想看访问趋势、热门页面、流量来源和真实用户性能，Cloudflare Web Analytics 提供了一条更轻的路径——免费、无需把域名迁入 Cloudflare、没有 Cookie，也不使用 localStorage 或跨站指纹来识别访客。

Cloudflare Web Analytics 概览



它是什么，适合谁



Cloudflare Web Analytics 的核心是基础流量分析 + 真实用户监控（RUM）。它通过浏览器 Performance API 采集页面加载与 Core Web Vitals 数据，再以聚合方式展示访问趋势。

| 场景 | 是否适合 | 原因 |
|------|---------|------|
| 个人博客、作品集、文档站 | 很适合 | 零成本、接入快 |
| Cloudflare Pages / Workers 静态站 | 很适合 | 一键开启，几乎无维护成本 |
| 关注 SEO 与真实用户性能 | 很适合 | 自带 LCP、INP、CLS 和问题元素定位 |
| 内容站日常趋势观察 | 适合 | 可按路径、来源、国家、设备过滤 |
| SaaS 产品增长分析 | 只能作为补充 | 没有自定义事件、漏斗、留存分析 |
| 电商转化与广告归因 | 不适合 | 不支持 UTM、购买事件、多触点归因 |

一句话总结：想知道"有人来吗、从哪来、页面快不快"，先用 Cloudflare Web Analytics；想知道"用户做了什么、为什么转化"，再配 GA4、Plausible 或 PostHog。



工作原理



Cloudflare Web Analytics 的核心是一个轻量 JavaScript beacon：
  • 用户打开页面
  • 浏览器加载 beacon.min.js
  • 读取 Navigation Timing / Performance API / web-vitals
  • 向 /cdn-cgi/rum 或 cloudflareinsights.com/cdn-cgi/rum 发送数据
  • Cloudflare 聚合、采样并展示在 Dashboard / GraphQL API


    • 采集脚本地址：https://static.cloudflareinsights.com/beacon.min.js

    对于传统多页应用（MPA），beacon 会在页面完成加载以及用户离开页面时上报；对于单页应用（SPA），每次路由变化还会额外上报。Core Web Vitals 通常在页面首次进入隐藏状态时发送，以便收集更完整的交互数据。

    工作原理图



    RUM 与边缘 Analytics 的区别



    Cloudflare 控制台里有几种名字相近的 Analytics，最容易混淆的是下面两种：

    | 对比项 | Web Analytics（本文） | HTTP Traffic / Edge Analytics |
    |--------|----------------------|------------------------------|
    | 数据来源 | 访客浏览器里的 JS beacon | Cloudflare 边缘服务器日志 |
    | 能否看到真实渲染性能 | 能，包含 Web Vitals | 不能直接看到浏览器渲染体验 |
    | 会不会被广告拦截器拦截 | 可能 | 不会 |
    | 是否包含机器人和非 HTML 请求 | 主要是运行脚本的页面访问 | 会看到所有到达边缘的 HTTP 请求 |
    | 域名是否必须经过 Cloudflare | 不必须 | 必须经过 Cloudflare 代理 |

    两边数字不完全一致是正常现象，不要拿 beacon 的页面访问量与边缘 HTTP 请求数逐条对账。



    隐私模型：不靠"认出一个人"来统计



    Cloudflare 官方说明，RUM beacon：
  • 不读取或写入 Cookie
  • 不访问 localStorage、sessionStorage 或 IndexedDB
  • 不把 IP、User-Agent 等组合成个人指纹
  • 不跨 Cloudflare 客户的网站追踪同一个人
  • 源 IP 会在边缘丢弃，不进入核心数据库或日志


    • 这意味着 Web Analytics 没有持久访客 ID，不能像传统分析工具那样准确回答"独立用户、回访用户、跨天留存"。Cloudflare 对 Visits 的定义也不是"唯一访客"：当一次页面访问来自外部网站或直接链接时，就开始一次 visit；一次 visit 可以包含多个 page views。

    隐私模型说明



    免费额度与数据保留



    Cloudflare Web Analytics 在所有计划中可用，目前没有按 page view 收费。但有几个明确边界：

    | 项目 | 限制 |
    |------|------|
    | 不经过 Cloudflare 代理的站点 | 每个账户 10 个（soft limit） |
    | 经过 Cloudflare 代理的站点 | 不限数量 |
    | 无采样原始 beacon 数据 | 保留 7 天 |
    | 7 天后 | 聚合到原始数据量约 10% |
    | 可查询历史 | 最近 6 个月 |

    Dashboard 和 GraphQL 查询可能应用自适应采样（Adaptive Bit Rate），低流量站点通常会使用更高采样比例。所以 Web Analytics 很适合观察趋势和性能分布，但不应被当作财务审计或逐条事件仓库。



    5 分钟快速开始



    方式一：经过 Cloudflare 代理的域名自动安装

  • 登录 Cloudflare Dashboard，进入 Web Analytics
  • 选择 Add a site
  • 从下拉列表选择 hostname，点击 Done
  • 保持自动安装启用
  • 打开网页，等待几分钟后回到 Dashboard 查看数据


    • Cloudflare 会在 HTML 响应经过边缘网络时自动注入脚本，还会为脚本添加 Subresource Integrity（SRI）。如果源站返回 Cache-Control: public, no-transform，Cloudflare 不能修改 HTML，此时需要移除 no-transform 或切换到手动安装。

    自动安装步骤

    方式二：任何网站手动安装



    不需要把 DNS 或流量迁到 Cloudflare。先在 Web Analytics 中添加 hostname，再从 Manage site 复制专属 token，将下面脚本放到 </body> 前：

    html
    <script
  type="module"
  defer
  src="https://static.cloudflareinsights.com/beacon.min.js"
  data-cf-beacon='{"token":"YOUR_SITE_TOKEN"}'
></script>


    注意：token 不是需要隐藏的服务端密钥；一个页面只能运行一个 Web Analytics snippet，不要重复自动注入和手动安装；DNS-only（灰云）域名不能自动注入，只能手动安装。

    方式三：Cloudflare Pages 一键开启



    进入 Workers & Pages → 打开 Pages 项目 → Metrics → 在 Web Analytics 下选择 Enable → 重新部署项目。



    Dashboard 里能看什么



    1. Visits



    来自外部网站或直接链接的一次入口访问。通过 HTTP Referer 是否与当前 hostname 匹配来判断。它不是持久化的 unique visitor，也不能直接用于计算严格的 DAU / MAU。

    2. Page views



    一次 Content-Type: text/html 的成功 HTTP 响应。手动安装时，实际可见数据取决于页面是否渲染并成功运行 snippet。

    3. Page load time



    Dashboard 把浏览器 Navigation Timing 拆成多个阶段：DNS、TCP、Request、Response、Processing、Load Event、First Paint、First Contentful Paint。

    4. Dimensions 与过滤器



    支持按 Country、Host、Path、Referer host、Device type、Browser、OS 等维度过滤。Cloudflare 不记录 query string，因此不能按 utm_source、utm_campaign 等参数分析。

    5. Weekly Summary



    Cloudflare Notifications 可以发送每周汇总，包含账户下所有站点的聚合 visits、page views 和中位 page load time。

    Dashboard 界面



    Core Web Vitals：从"页面慢"定位到具体元素



    Cloudflare 当前展示三项核心指标：

    | 指标 | 衡量什么 | Good | Needs Improvement | Poor |
    |------|---------|------|-------------------|------|
    | LCP | 最大内容元素出现的速度 | ≤ 2.5s | 2.5s～4.0s | > 4.0s |
    | INP | 点击、输入等交互后的响应速度 | ≤ 200ms | 200ms～500ms | > 500ms |
    | CLS | 页面布局的视觉稳定性 | ≤ 0.1 | 0.1～0.25 | > 0.25 |

    评估时重点看 P75（第 75 百分位），而不是只看平均值。Cloudflare 的 Debug View 会列出影响最大的前五个元素，并显示 P50、P75、P90 和 P99：
  • LCP：CSS selector、资源 URL、资源大小
  • INP：产生慢交互的元素与耗时
  • CLS：发生位移的元素，以及位移前后的坐标和尺寸


    • Core Web Vitals 展示

    截至官方说明，Core Web Vitals 完整能力主要支持 Chromium 浏览器，Safari 与 Firefox 的支持仍受限。



    一套能落地的分析流程



    第一步：确认流量是否健康

  • Visits 与 Page views 是否同步变化？
  • 流量突增来自新内容、外部推荐，还是机器人？
  • 开启 Exclude Bots 后趋势是否明显变化？


    • 第二步：找到"值得优化"的页面



    不要先优化访问量极低的长尾页。用 Path 和 Referer 找到高流量 × 差体验的页面，优先级最高。

    第三步：按维度切开性能



    全站 P75 看起来正常，不代表所有用户正常。继续按 Path、Device type、Browser/OS、Country、Navigation type 过滤。

    第四步：把指标翻译成改动



    | 现象 | 优先检查 |
    |------|---------|
    | LCP 差 | hero 图片尺寸与格式、字体、首屏 CSS、服务端响应 |
    | INP 差 | 长任务、大型 hydration、事件处理器、第三方脚本 |
    | CLS 差 | 图片未声明宽高、异步广告、字体替换 |
    | DNS/TCP 高 | 域名数量、连接复用、第三方资源、TLS 与网络距离 |
    | Request 高 | TTFB、源站性能、缓存命中、数据库与 Worker CPU |
    | Response 高 | HTML/资源体积、压缩、图片、带宽 |
    | Processing 高 | render-blocking CSS/JS、脚本执行、DOM 规模 |

    每次只改一类问题，部署后比较相同 Path、Device 和时间窗口的 P75。



    Web Analytics vs GA4：目标不同



    | 能力 | Cloudflare Web Analytics | Google Analytics 4 |
    |------|-------------------------|-------------------|
    | 价格 | 免费，无公开 page view 计费 | 标准版免费 |
    | Cookie/本地状态 | beacon 不使用 | 通常使用客户端标识 |
    | 基础页面与来源 | 有 | 有，维度更丰富 |
    | Core Web Vitals RUM | 内置，带元素 Debug View | 非核心内置，通常需额外接入 |
    | 自定义事件 | 不支持 | 支持 |
    | UTM campaign | 不支持 query string 采集 | 支持 |
    | 转化/漏斗/用户旅程 | 不支持 | 支持 |
    | 用户、会话与留存 | 非持久身份模型，能力有限 | 支持 |
    | 广告归因 | 不支持 | 深度集成 |
    | SPA history 路由 | 自动支持 | 支持，通常需要正确配置 |
    | 上手与维护成本 | 很低 | 中等到高 |

    实际项目完全可以同时使用：Cloudflare 负责轻量流量趋势和真实性能，GA4 或产品分析工具负责业务事件与转化。

    对比图



    它明确做不到什么



    截至 2026 年 7 月，官方 FAQ 明确写着：
  • 不支持 UTM parameters：为避免 query string 中的潜在敏感信息，当前不记录 query string
  • 不支持 custom events：不能直接记录 signup、purchase、download 等业务事件


    • 由此还意味着：没有原生转化目标和漏斗、没有用户级 session journey、没有 cohort retention、没有 session replay、没有 JavaScript exception 分析。

    一个勉强可用的替代办法是把成功动作跳转到独立路径（例如 /signup/success），再按 page view 看趋势。但它不能等价于可靠的 conversion event。



    最佳实践与避坑指南

  • 不要重复安装：自动安装与手动 snippet 二选一
  • 用浏览器 Network 验证：搜索 beacon.min.js 和 rum，确认脚本加载和数据上报
  • CORS 报错先核对 hostname：最常见原因是 Dashboard 注册的 hostname 与实际加载页面不匹配
  • 自动注入失败检查三件事：DNS 是否为橙云代理、HTML 是否结构有效、Cache-Control 是否包含 no-transform
  • 接受广告拦截带来的缺口：Brave、DuckDuckGo 扩展和部分 ad blocker 会阻止 beacon
  • 看 P75，不迷信平均值：性能分布通常长尾明显
  • 不把 sampled analytics 当账本：7 天后数据会聚合，Dashboard 和 GraphQL 还可能应用自适应采样
  • 建立自己的数据字典：写清 Visit 不是 unique visitor、Page view 与边缘 request 不同等口径




    • Cloudflare Web Analytics 最有价值的地方，不只是"免费"，而是把两个原本分开的任务放进了同一个低维护工具：用 Visits、Page views、Path、Referer 回答"流量发生了什么"；用 Navigation Timing、LCP、INP、CLS 和 Debug View 回答"真实用户为什么觉得慢"。

    它主动放弃持久身份、query string 和自定义事件，换来了更小的数据面与更清晰的隐私模型。这也是它的优势和限制。

    对独立开发者，最务实的组合是：先免费开启 Cloudflare Web Analytics，建立流量与性能基线；只有当业务真的需要 campaign、conversion、funnel 或 retention 时，再增加更重的分析工具。



    相关资源：Cloudflare Web Analytics 官方文档

    💬 评论区 (0)

    0/500

    暂无评论，快来抢沙发吧！