性能与成本优化清单：按收益排序的 18 件事
优化清单容易变成"什么都做一点"，结果每项都不彻底。更有用的排法是按收益除以改动量：先做那些一行配置就能让 80% 请求不打到源站的，再考虑代码层面的。这篇的清单分四组，每组内部按优先级排，最后给出怎么量化效果。
缓存规则的细节见 74-cache-rules.md，指标采集见 76-site-speed-web-analytics.md，额度背景见 56-free-tier-limits-cheatsheet.md。
1. 第一组：缓存（收益最大）
| # | 动作 | 影响 | 改动量 |
|---|---|---|---|
| 1 | 静态资源 cache-control: public, max-age=31536000, immutable | 边缘命中后不再回源 | 一个响应头 |
| 2 | HTML 用 max-age=0, must-revalidate 加 etag | 内容新鲜且省带宽 | 一个响应头 |
| 3 | 开启 Tiered Cache | 回源次数按机房聚合下降 | 控制台开关 |
| 4 | 把重复计算的接口结果缓存 30–60 秒 | 直接砍掉大部分 Worker 执行 | 代码几行 |
第 1 项和第 2 项的组合是最常见的错误来源：给 HTML 也加一年 immutable，用户永远看不到新内容。区分方法是看内容是否随发布变化，静态资源带哈希文件名可以永久缓存，HTML 不行。
2. 第二组：传输体积
| # | 动作 | 影响 | 改动量 |
|---|---|---|---|
| 5 | 开 Brotli | 文本体积再降 15–20% | 一个开关 |
| 6 | 图片转 WebP/AVIF | 同等画质体积减半 | 构建时处理 |
| 7 | 图片按显示尺寸出图 | 移动端少下 70% 字节 | 需要图片处理链路 |
| 8 | 删掉没用的字体与图标库 | 首屏少几百 KB | 需要清理 |
图片通常是最大的单项。一个 200 KB 的 PNG 换 WebP 大约 90 KB，再按实际显示宽度出一半尺寸，能到 30 KB 以下。这条对 LCP 的影响比任何代码优化都大，具体做法见 73-image-optimization.md。
3. 第三组：执行时间
Worker 免费档给 10 ms CPU，超过就 1102。等上游的时间不算 CPU，所以耗时长的接口不一定撞这个限制，但计算密集的会。
| # | 动作 | 影响 | 改动量 |
|---|---|---|---|
| 9 | 避免在请求路径里 JSON.parse 大对象 | 省 CPU | 改数据结构 |
| 10 | 把正则换成前缀判断 | 省 CPU，避免回溯 | 小 |
| 11 | 用 Promise.all 并行子请求 | 墙钟时间下降 | 小 |
| 12 | 上游请求加 AbortSignal.timeout | 防止挂起耗尽并发 | 一行 |
第 9 项容易被忽略。一个 100 KB 的配置 JSON 每次请求都解析，CPU 时间能到几毫秒，直接吃掉限额的一半。改成启动时缓存到模块作用域（isolate 复用），只在冷启动时解析一次。
4. 第四组：请求数量
| # | 动作 | 影响 | 改动量 |
|---|---|---|---|
| 13 | 静态资源交 Pages，别用 Worker 返回 | 不占 Workers 额度 | 改部署方式 |
| 14 | 合并小接口 | 减少往返 | 需要改前端 |
| 15 | 用 _headers / _redirects 处理规则 | 不经过 Worker 执行 | 加两个文件 |
| 16 | favicon、robots.txt 走静态 | 省掉每次页面加载的额外请求 | 加文件 |
| 17 | 合理设置 TTL，减少回源 | 降低源站请求 | 配置 |
| 18 | 关掉不用的预览部署自动构建 | 省构建次数 | 配置 |
第 13 项对成本的影响最直接：把首页从 "Worker 返回 HTML" 改成 "Pages 发静态文件 + Worker 只处理 /api/*"，Workers 请求数可能下降一个数量级。额度是按请求计的，静态请求走 Pages 不进这个池子。
5. 怎么量化
三个指标够用：
先记基线，再改。基线的三项数字写进项目 README，改动后对照着看，比凭印象说"快了"可靠。
TTFB。curl -w "%{time_starttransfer}\n" -o /dev/null -s https://example.com/。改缓存前后各测十次取中位数。
缓存命中率。看响应头 cf-cache-status，HIT 的比例就是命中率。个人站做到 80% 以上很正常，低于 50% 说明缓存头配错了，或者 URL 上带了随机参数让每次请求都成了新对象。
Worker 执行时间。控制台的 Workers 指标里有 CPU 时间分布。我之前部署的短链服务冷启动 1 ms、上传包 3.46 KiB，这说明简单路由的基线成本极低——如果你的 Worker 用了 8 ms，多半是解析或序列化在吃时间。
6. 不值得做的事
测量有噪声，别被单次数字骗。同一次改动前后各测十次取中位数，比测一次快 30% 或慢 20% 都不算数。国内到海外节点的延迟波动本来就有一两百毫秒，小于这个量级的"优化"无法从噪声里分辨出来。
为了省几毫秒去改 DNS 记录顺序，收益在噪声范围内。给纯静态站上 Worker 做"智能路由"，增加故障面还多耗额度。自己实现一套缓存层绕过 Cloudflare 的边缘缓存，等于在已经免费的层上面再搭一层。免费档上真正的成本大头是 KV 写入和 Workers 请求数，优化应该盯着这两项。
小结
清单里前四项（缓存头、HTML 的 etag、Tiered Cache、接口短缓存）几乎零改动，却决定了绝大部分性能和额度消耗。图片体积次之，执行时间和请求数量排后面。先做完前两组，再回头看代码。
量化的意义在于避免自我感觉良好。TTFB、cf-cache-status 命中率、Worker CPU 时间，三个数字就能判断一次优化有没有用。成本侧的监控与阈值见 102-cost-control-quotas.md。
数据来源与检索时间
检索时间 2026-11-10。
| 来源 | URL | 对应数据 |
|---|---|---|
| 缓存行为 | https://developers.cloudflare.com/cache/concepts/default-cache-behavior/ | 默认缓存哪些扩展名、cf-cache-status 取值 |
| Tiered Cache | https://developers.cloudflare.com/cache/how-to/tiered-cache/ | 开启方式与回源聚合效果 |
| Workers 限额 | https://developers.cloudflare.com/workers/platform/limits/ | 免费档 10 ms CPU、1102 错误 |
| Brotli | https://developers.cloudflare.com/speed/optimization/content/brotli/ | 压缩开关与适用内容类型 |
核验说明
- 真实执行：本次会话部署的短链 Worker 上传 3.46 KiB / gzip 1.59 KiB、启动 1 ms、首页 1250 字节；限流 Worker 上传 1.27 KiB / gzip 0.66 KiB。这些是清单里"基线成本极低"的依据。
- 文档核对：默认缓存行为、
cf-cache-status取值、Brotli 开关位置来自上述页面。 - 未做：没有做改动前后的 TTFB 对比，没有采集真实站点的缓存命中率；18 项按收益排序是依据机制的判断，不是 A/B 测试结果。图片压缩比例为经验值。