站点性能与 Web Analytics：先看见，再优化

2026-11-10 #Cloudflare

读完这篇你能做到：用 Cloudflare 的 Web Analytics 拿到真实用户的速度数据，看懂 LCP、INP、CLS、TTFB 四项指标分别该改什么，并且按投入产出排出一个不用一次性全做的优化顺序。

性能优化最容易走偏的地方是凭感觉改。加了个懒加载、换了个字体，主观上觉得快了，实际指标没动。先有字段数据（真实用户而不是实验室环境），再决定改什么，效率高得多。

1. Web Analytics 提供什么

它是 Cloudflare 提供的真实用户监测，免费，不写 cookie，也不需要 consent 弹窗。数据来自页面里的一段 beacon 脚本，浏览器加载后上报指标。

能看到的内容：

它不提供用户级明细、不做漏斗、不支持自定义事件。要这些得上第三方分析工具或 Zaraz。定位是"看站点快不快"，不是"看用户干了什么"。

控制台路径：账号级 → Web Analytics → Add a site。

自动注入失败时用手动模式，把脚本贴进 <head>：

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

defer 保证它不阻塞渲染。token 是公开值，写在前端没有安全问题。

指标不是抽象分数，每一个都指向具体的资源。

指标	衡量的东西	主要改动
LCP	最大内容元素的出现时间	首屏图压体积、加 `fetchpriority="high"`、去掉阻塞渲染的 CSS
INP	交互到响应的延迟	拆长任务、减少首屏 JS、事件处理里别做重计算
CLS	布局偏移	给图片和嵌入内容写死宽高、字体用 `font-display: swap` 并预加载
TTFB	首字节时间	边缘缓存、静态托管、减少回源

TTFB 在 Pages 上通常很好，因为文件就在边缘。如果 TTFB 差，先看是不是没走缓存、或者请求进了 Function。缓存规则的设计见 74-cache-rules.md。

CLS 是最容易一次修完的。所有 <img> 带上 width 和 height，广告位和 iframe 预留固定高度，两处改完基本归零。

LCP 的收益最大也最费功夫，图片相关的处理在 73-image-optimization.md。

按这个顺序做，每一步都能单独看到效果，不用等整套做完。

第一步，量基线。开启 Web Analytics 后跑一周，记下四项指标的"良好"占比。没有基线就没有对比。

第二步，修 CLS 与字体。改动小、风险低、见效快。图片宽高加上，字体改成 swap 并预加载主字体文件。

第三步，压 LCP 资源。找出首屏最大的那张图或那段文字，压体积、提优先级。这一步通常能拿到最大的一笔改善。

第四步，砍首屏 JS。用构建产物的体积报告看哪个 chunk 最大，能延迟加载的延迟，能用原生实现的换掉库。

第五步，配缓存。静态资源长缓存加哈希名，HTML 短 TTL。这一步对回访用户的 TTFB 改善明显。

第六步，复查。对比第一周的基线，确认改动真的生效。指标没动说明改错了地方，回去看具体页面的分布。

不开控制台也能看几个关键信号：

curl -sI https://example.com/ | grep -i -E 'cf-cache-status|server-timing|cache-control'
curl -s https://example.com/ | grep -c 'beacon.min.js'

第一条看缓存命中与响应头，第二条确认 beacon 是否注入成功（返回 1 表示有）。这只是粗查，字段数据还是得看 Web Analytics。

Web Analytics 和 Google Analytics 有什么不同。

Web Analytics 只做性能与流量统计，不追踪用户、不写 cookie、数据不用于跨站画像。GA 的功能面大得多，代价是脚本体积和合规成本。两个都装不冲突，只是各自统计口径不同。

数据一直是空的。

三个常见原因：域名没走 Cloudflare 代理；自动注入没开且页面里也没有手动脚本；访问量太低，样本不足时图表不显示。先确认页面 HTML 里有没有 beacon.min.js。

免费吗，有没有采样。

Web Analytics 在免费档可用，不需要额外开通。具体保留时长与采样策略以控制台显示为准，官方文档在不同时期调整过这两项。

性能优化的顺序是：先装 Web Analytics 拿到字段数据，再按 CLS、LCP、JS、缓存的次序改，每步单独验证。这套流程的好处是每一步都有据可依，不靠主观感受。

Pages 托管的站点在 TTFB 上有先天优势，需要花力气的是图片和 JS。四项指标里 LCP 与 INP 的改善空间最大，也最依赖构建期的处理。

部署侧的构建配置见 70-pages-build-cache.md；指标异常时先回看缓存命中率与首屏图片体积，这两处能解释多数波动。

检索时间 2026-11-10。

来源	URL	对应数据
Web Analytics 文档	https://developers.cloudflare.com/web-analytics/	免费、无 cookie、自动与手动两种接入方式、Core Web Vitals 指标集
Core Web Vitals 说明	https://web.dev/articles/vitals	LCP / INP / CLS / TTFB 的定义与阈值
Pages Limits	https://developers.cloudflare.com/pages/platform/limits/	静态资源托管与请求计量方式，用于解释 TTFB 基线