《林一的 Cloudflare 通关记》第 14 篇-上线前的"体检报告"——Analytics 与性能监控
《林一的 Cloudflare 通关记》第 14 篇
"明天上线？"老张问。
"嗯！"林一摩拳擦掌。
"那先看看你的体检报告。"
"什么体检？我上周刚体检过，指标都正常——"
故事引入
"说你的网站。"老张打开 Cloudflare Dashboard，点进 Analytics 面板，"你的网站跑得快不快？哪里慢？有多少人访问？有没有出错？这些你知道吗？"
林一看了看满屏的图表和数字，一脸茫然。
"不知道……"
"上线前不看数据，那叫蒙眼狂奔。"老张拉了把椅子坐下，"来，逐项给你讲。"
技术讲解
Cloudflare Analytics 的四大维度
老张在白板上画了个四宫格：
┌─────────────┬─────────────┐
│ 流量分析 │ 安全分析 │
│ Traffic │ Security │
├─────────────┼─────────────┤
│ 性能分析 │ DNS 分析 │
│ Performance │ DNS │
└─────────────┴─────────────┘
"Cloudflare 的 Analytics 分四个维度——流量、安全、性能、DNS。前三个是你最需要关注的。"
1. 流量分析（Traffic）
"流量分析回答的基本问题是：有多少人来、从哪来、看什么。"
| 指标 | 含义 |
|---|---|
| Requests（请求数） | 所有 HTTP 请求总数 |
| Bandwidth（带宽） | 传输的数据总量 |
| Unique Visitors（独立访客） | 去重后的访客数 |
| Threats（威胁数） | 被安全系统拦截的请求数 |
| Page Views（页面浏览） | 页面被加载的次数 |
"这些数据不需要你装任何代码——只要你的域名开了 Cloudflare 代理（Proxied 模式），流量经过 Cloudflare 的边缘节点，就自动统计了。"
"就像高速路口的摄像头？"
"对，过路就拍照，不需要你额外装东西。"
2. 安全分析（Security）
"安全分析展示你的网站被攻击的情况——这个我们在第 11 篇 WAF 那篇看过。"
| 指标 | 含义 |
|---|---|
| Threats blocked | 被拦截的威胁数 |
| Threat type | 威胁类型分布（SQL注入、XSS、CC等） |
| Top countries | 攻击来源国家 |
| Top IPs | 攻击最多的 IP |
| Action taken | WAF 的处理动作（Block/Challenge/Log） |
"上线前看一眼安全面板——如果已经有攻击被拦截了，说明 WAF 在正常工作。如果一条拦截都没有……可能你的 WAF 配错了。"
3. 性能分析（Performance）
"这个最关键——你的网站到底快不快。"
"快不快我自己访问一下不就知道了？"林一不以为然。
"你访问快不代表用户访问快——你在公司网络里，离 Cloudflare 节点可能就几十毫秒。但用户在新疆、在海南、在国外呢？"
"说得对……"
"所以需要 RUM。"
Real User Monitoring——真实用户监控
"RUM（Real User Monitoring）就是'真实用户监控'——在你的网页里嵌一小段 JS 代码，每个真实用户访问你的网站时，浏览器会自动采集性能数据发回 Cloudflare。你看到的是真实用户在不同地点、不同设备、不同网络下的实际体验。"。"
"跟 Google Analytics 一样？"
"不完全一样。"老张画了张对比表：
| Cloudflare Web Analytics | Google Analytics | |
|---|---|---|
| Cookie | 不使用 Cookie | 使用 Cookie 追踪用户 |
| 用户追踪 | 不追踪个人用户 | 跨站追踪用户行为 |
| 隐私合规 | GDPR 友好，无需 Cookie 横幅 | 需要用户同意才能使用 |
| 数据归属 | 你的数据，不用于广告 | 数据可能用于广告投放 |
| 性能指标 | Core Web Vitals + TTFB | 主要偏流量分析 |
| 费用 | 免费 | 免费（但有数据采样限制） |
"最大的区别是——Cloudflare Web Analytics 不使用 Cookie，不追踪个人用户。它统计的是聚合数据：有多少人访问、页面加载花了多久、从哪个国家来的。但不会告诉你'张三昨天看了5个页面，在第3个页面停留了120秒'。"
"那它不是不如 GA 功能多？"
"看需求。如果你要分析用户行为路径、转化漏斗、A/B 测试——那确实需要 GA。但如果你只是想知道'网站快不快、有没有人来看、哪里卡了'——Cloudflare Web Analytics 够了，而且不用操心隐私合规。"
国内类比：类似百度统计的轻量版，但比百度统计更注重隐私。如果你的用户群对隐私敏感（比如海外用户），Cloudflare Web Analytics 是更安全的选择。
Core Web Vitals——网站性能的核心指标
"性能分析里最重要的就是 Core Web Vitals——Google 定义的一组'用户体验核心指标'。直接影响搜索排名。"
老张在白板上画了张表：
| 指标 | 全称 | 含义 | 好的标准 | 差的 |
|---|---|---|---|---|
| TTFB | Time to First Byte | 首字节时间——从发请求到收到第一个字节 | < 800ms | > 1800ms |
| LCP | Largest Contentful Paint | 最大内容渲染——页面主要内容渲染完成 | < 2.5s | > 4s |
| INP | Interaction to Next Paint | 交互到下次渲染——用户点击后到页面响应 | < 200ms | > 500ms |
| CLS | Cumulative Layout Shift | 累计布局偏移——页面元素跳来跳去的程度 | < 0.1 | > 0.25 |
"逐个解释。"
TTFB——首字节时间
"从用户发出请求到收到服务器第一个字节的时间。这个指标反映的是服务器响应速度。"
"对 Cloudflare 用户来说，TTFB 通常很好——因为 CDN 在边缘节点缓存了内容，用户请求根本不到源服务器。"
"但如果你的 Worker 要查 D1 数据库再返回结果呢？"
"那就慢了？"
"不一定。Cloudflare 的边缘节点到 D1 的延迟通常在 50ms 以内。但如果你的 Worker 写了5个串行数据库查询……"
"那我改成并行。"
"孺子可教。"
LCP——最大内容渲染
"页面'看起来加载完了'的时间。通常是你页面里最大的那个元素——比如一张 banner 图、一段大标题——渲染完成的时间。"
"这个主要看前端优化吧？图片大小、字体加载……"
"对。在 Cloudflare 这边能做的优化：CDN 缓存图片和静态资源（第 3 篇），Pages 自动部署到全球 CDN（第 4 篇）。剩下的看你的前端代码质量。"
INP——交互到下次渲染
"INP 是 2024 年 3 月替代 FID（First Input Delay）的新指标。FID 只测第一次交互的延迟，INP 测所有交互的延迟——更严格。"
"什么算'交互'？"
"点击按钮、输入文字、滚动页面……用户做了任何操作到页面给出视觉反馈的时间。如果你的前端 JS 特别重，用户点了按钮要等半秒页面才有反应——INP 就差了。"
CLS——累计布局偏移
"这个最好理解——你打开一个网页，正要点某个按钮，结果页面突然跳了一下，你点到了别的地方。这就是 CLS。"
"最烦这种了！"小王凑过来说，"我昨天看新闻，广告加载完页面跳了一下，我不小心点了广告。"
"CLS 的常见原因：图片没设宽高、字体加载导致文字重排、动态插入的内容把已有元素挤走。优化方法：给图片设 width 和 height、给广告位预留空间、用 transform 代替 top/left 做动画。"
Workers Analytics
"除了网站性能，你的 Worker API 也需要监控。"
在 Cloudflare Dashboard → Workers & Pages → 选你的 Worker → Metrics 标签：
| 指标 | 含义 |
|---|---|
| Requests | Worker 被调用的总次数 |
| CPU Time | 消耗的 CPU 时间（注意不是执行时间） |
| Errors | 失败的请求数和错误率 |
| Success Rate | 成功率 |
| Duration | 请求处理总时长 |
"注意区分 CPU Time 和 Duration——CPU Time 是你的代码实际占 CPU 的时间，Duration 是从请求进入到响应返回的总时间。如果你的 Worker 里调了外部 API（比如 Workers AI），等待 API 响应的时间算在 Duration 里，但不算 CPU Time。"
"免费版 CPU 时间限制多少来着？"
"10ms/请求。但 Duration 没限制——你 await 等外部 API 响应等 5 秒都不算 CPU 时间。"
"那 Workers AI 的调用等待不算 CPU？"
"不算。所以你不用担心调 AI 把 CPU 时间用超了。"
实操指导
第一步：启用 Web Analytics
"你的前端是 Cloudflare Pages 部署的（第 4 篇），启用 Web Analytics 一键搞定。"
方式一：Pages 自动集成（推荐）
- 进入 Dashboard → Workers & Pages
- 选你的 Pages 项目
- 点击 Metrics 标签
- 找到 Web Analytics 区域，点击 Enable
"Cloudflare 会在下次部署时自动把 Analytics 的 JS beacon 注入到你的页面里。你什么都不用改。"
方式二：通过 Web Analytics 页面
如果你的站点不是 Pages 部署的，或者想单独管理：
- 进入 Dashboard → Web Analytics
- 点击 Add a site
- 如果域名已代理在 Cloudflare 上——选 Automatic Mode，自动注入 beacon，不需要改代码
- 如果域名没在 Cloudflare 上——选 Manual Mode，复制 JS 代码贴到你的 HTML
<body>标签前
<!-- Cloudflare Web Analytics -->
<script defer src='https://static.cloudflareinsights.com/beacon.min.js'
data-cf-beacon='{"token": "你的token"}'></script>
"Automatic Mode 是什么原理？"林一问。
"因为你域名开了 Cloudflare 代理，Cloudflare 在边缘节点响应请求时，自动在你的 HTML 里注入这段 JS。你完全不用改代码。"
"又是一个域名托管在 Cloudflare 的好处？"
"你开始悟了。"
第二步：查看 Web Analytics 数据
启用后等几分钟，数据就出来了。在 Web Analytics 页面能看到：
| 维度 | 数据 |
|---|---|
| Page Views | 页面浏览量 |
| Visits | 访问次数（同一用户 30 分钟内多次访问算一次） |
| Visitors | 独立访客数（基于 IP 去重，不用 Cookie） |
| Top Countries | 访客来源国家 |
| Top Paths | 访问最多的页面路径 |
| Top Referrers | 流量来源（从哪个网站链接过来的） |
| Core Web Vitals | TTFB、LCP、INP、CLS 的分布 |
"重点看 Core Web Vitals 的分布，"老张指着一张饼图，"Google 认为 LCP < 2.5s 是'好'，2.5-4s 是'需要改进'，> 4s 是'差'。如果你大部分访问的 LCP 在'好'的范围——没问题。如果一堆在'差'——得优化了。"
第三步：查看 Zone 级 Analytics
"除了 Web Analytics，Dashboard 上还有 Zone 级别的分析——涵盖流量、安全、性能、DNS。"
- 进入 Dashboard → 选你的域名 → Analytics & Logs
Traffic 标签：
- 请求量趋势图（按时间）
- 带宽使用量
- 缓存命中率（Cache Ratio）——这个重要！
- 独立访客数
"缓存命中率是什么？"
"CDN 缓存命中率——有多少请求是直接从边缘节点缓存返回的，不需要回源。命中率越高，网站越快，源服务器压力越小。"
"多少算高？"
"静态资源为主的网站，命中率应该 90% 以上。如果你只有 50%——说明你的 Cache Rules（第 3 篇）没配好，很多东西没缓存。"
Security 标签：
- 被拦截的威胁数趋势
- 威胁类型分布
- 攻击来源 Top 10
Performance 标签：
- TTFB 分布
- 缓存命中率
- 各边缘节点的性能数据
第四步：设置告警
"上线后你不可能 24 小时盯着 Dashboard。设置告警，出问题自动通知你。"
- 进入 Dashboard → 选域名 → Notifications
- 点击 Add notification
可以配置的告警类型：
| 告警类型 | 触发条件 | 推荐用途 |
|---|---|---|
| DDoS Attack | 检测到 DDoS 攻击 | 必须——攻击时第一时间知道 |
| HTTP Rate Limit | 速率限制被触发 | 防暴力破解告警 |
| WAF Custom Rule | 自定义规则被触发 | 监控特定攻击 |
| Origin Error | 源服务器 5xx 错误 | 源站出问题告警 |
| Worker Error | Worker 异常 | API 出错告警 |
"每个告警可以发邮件或 Webhook。如果你用 Slack/钉钉/飞书，配一个 Webhook 到群机器人，告警直接推到群里。"
小结与预告
本篇知识点回顾
| 知识点 | 要点 |
|---|---|
| Analytics 四维度 | 流量、安全、性能、DNS |
| Web Analytics | 隐私友好（不用 Cookie）、免费、GDPR 合规 |
| Web Analytics vs GA | CW 侧重性能和隐私，GA 侧重用户行为分析 |
| Core Web Vitals | TTFB（服务器响应）、LCP（内容渲染）、INP（交互响应）、CLS（布局稳定） |
| INP 替代 FID | 2024年3月起，INP 成为新的交互指标，比 FID 更严格 |
| 缓存命中率 | 衡量 CDN 效果的关键指标，90%+ 为佳 |
| Workers Analytics | CPU Time ≠ Duration，等待外部 API 不算 CPU 时间 |
| 告警 | DDoS、WAF、源站错误等告警，支持邮件和 Webhook |
动手挑战
基础挑战：为你的 Pages 站点启用 Web Analytics，等待 30 分钟后查看数据。找到 Core Web Vitals 面板，记录你的 TTFB 和 LCP 的分布——多少比例是"好"、多少是"需要改进"？
进阶挑战：配置一个 Webhook 告警——当 WAF 自定义规则被触发时，推送到你的飞书/钉钉/Slack 群。提示：
- 在群设置里添加一个 Incoming Webhook 机器人，拿到 Webhook URL
- 在 Cloudflare Notifications 里添加 WAF Custom Rule 告警
- Webhook URL 填你的群机器人地址
- 触发一次 WAF 规则（比如用 curl 发一个带 SQL 注入特征的请求），确认告警推送到群里
思考题：如果你的缓存命中率只有 60%，可能是什么原因？你会怎么排查？（提示：检查 Cache Rules 配置——是不是有些应该缓存的资源类型没被覆盖？是不是有些资源的
Cache-Control头设了no-cache？用 Cloudflare 的 Cache Analytics 看哪些 URL 没命中缓存。）
下回预告
林一把 Analytics 面板从头到尾过了一遍，缓存命中率 94%，LCP 平均 1.2 秒，没有异常错误。
"张哥，体检报告——各项指标正常。"
"那就准备上线吧。"老张站起来拍了拍他的肩膀，"明天就是上线日。"
林一突然有点紧张。
"怕什么？DNS、SSL、CDN、Pages、Workers、AI、R2、KV、D1、Turnstile、WAF、Access、Email、Analytics——你全过了一遍。明天就是把所有东西串起来检查一遍。"
"那……如果上线出问题呢？"
"出问题就用你学的东西解决。你已经准备好了。"
下篇预告：《正式上线！林一的"毕业典礼"——全链路复盘与成长总结》
