Cloudflare Shared Dictionaries 现在值得试吗？我按官方 demo 跑了一次，先给频繁发版团队一个判断

如果你的网站或 Web 应用每天会发很多次前端 bundle，而且每次改动都不大，那么截至 2026-04-29，Cloudflare Shared Dictionaries 已经值得进测试名单，但还不值得当成“所有站点都该立刻上的通用优化项”。它真正解决的不是传统 gzip / Brotli 不够强，而是“你明明只改了一小段配置，用户却要重新下载整包”的高频发版浪费。

我这轮没有只看 Cloudflare 的发布文。我直接按官方 demo 给的 curl 流程跑了一次 canicompress.com：同一类约 93KB 的 JavaScript 资源，普通 gzip 传输了 22,423B，带共享字典的 dcz 版本只传了 140B；但总耗时也从 0.641s 增到 0.902s。这说明它对“少传很多字节”这件事已经很有说服力，但它的价值前提依然是：你的资源版本之间必须高度相似，且客户端、缓存链路、回退策略都要配合。

如果你最近在看 Cloudflare 怎么把面向 agent 的能力往站点和交付层推进，可以先对照我们前面写过的 Cloudflare Agent Readiness Score；那篇讲的是站点对 agent 是否“读得懂”，这篇讲的是站点在频繁更新时代，能不能别让每次小改动都把传输成本重新付一遍。

先给判断：谁该现在试，谁先别急

适合现在试的人

• 你维护的是频繁发版的 SPA、控制台、文档站或 AI 工具前端
• 你每次上线只改一小部分配置、文案、实验开关，但静态 bundle 大部分内容不变
• 你已经在用 Cloudflare，且愿意先在小范围流量上做浏览器与缓存链路验证
• 你关心的是“同一批用户反复下载近似资源”的浪费，而不只是首访压缩率

先别急的人

• 你的网站主要是 SSR HTML、图片、视频，JavaScript 不是主要传输成本
• 你每次构建都会让 bundle 大面积重排，旧版和新版并不相似
• 你的用户端浏览器环境杂，或者公司代理 / TLS 中间层很多
• 你现在连基础缓存命中、资源版本化、Brotli 配置都还没理顺

我实际跑了一次：Cloudflare Shared Dictionaries 能把 22KB 级传输压到 140B，但不是白送的

Cloudflare 在官方文章里给了一个 live demo：canicompress.com。它每分钟生成一个新的约 94KB JavaScript bundle，并把前一版资源当成共享字典。官方在页面里把测试思路也公开了，我照着跑了一次最小复现：

ORIGIN="https://canicompress.com"
MANIFEST=$(curl -s "$ORIGIN/manifest.json")
PREV=$(echo "$MANIFEST" | python3 -c "import json,sys;print(json.load(sys.stdin)['recent_deploys'][1]['path'])")
CURR=$(echo "$MANIFEST" | python3 -c "import json,sys;print(json.load(sys.stdin)['recent_deploys'][0]['path'])")

我这次拿到的结果是：

• 上一版资源：/assets/app.deploy.9578b365.js
• 当前资源：/assets/app.deploy.7a009269.js
• gzip 传输大小：22,423B
• dcz 传输大小：140B
• gzip 总耗时：0.641s
• dcz 总耗时：0.902s

如果你想验证自己是不是跑到了共享字典链路，最直接的验收信号有 3 个：

• 响应头里的 Content-Encoding 变成 dcz
• 传输体积从数十 KB 掉到几百 B 量级
• 首次请求只是注册 dictionary，真正的超小传输通常出现在下一次相近版本请求

这点和我们之前写过的 Transformers.js Chrome 扩展实践 有点像：真正该先看的不是“新能力有没有宣传图”，而是你的真实交付对象里，重复成本到底卡在首包、权限、还是增量更新。 Shared Dictionaries 的价值，明显属于第三类。

Cloudflare Shared Dictionaries 真正在补哪一个洞

很多团队看到这个话题，第一反应会是：“Brotli 不是已经很强了吗？为什么还要再折腾？”

问题不在 Brotli 太弱，而在它不知道用户本地已经有上一版资源。如果你的应用今天发了 10 次版，而每次都只是改一个实验开关、换一段文案、调一个配色，旧 bundle 和新 bundle 的大部分内容其实没变。传统压缩仍然会把“整个压缩后的文件”再发一次；Shared Dictionaries 则试图把用户已经缓存的旧版本当成字典，只把差异部分放到线上传输。

Cloudflare 在官方文里举了一个很直观的量级：500KB bundle 如果只是改一行代码，传统缓存失效后仍可能整包重下；共享字典则有机会把线上传输缩到几 KB 甚至更低。我这次跑官方 demo，也看到了同一个方向的结果：页面显示的未压缩体积约 93.2KB，普通 gzip 在 22.1KB 左右，而第二次相邻版本请求的 dcz 只剩 140B。

所以 Cloudflare Shared Dictionaries 更像“频繁发版时代的增量交付优化”，而不是“所有站点通用的下一代压缩默认值”。

现在值不值得上测试，先看这 4 个前提

1）你的资源版本之间，真的足够相似吗？

这是第一道门槛，也是最容易被忽略的一道。

如果你的构建过程会频繁改 chunk 边界、打包顺序、hash 生成方式，或者每次上线都会让 bundle 大面积重排，那么共享字典的收益会迅速变差。它吃的是“新旧版本高度相似”这口饭，不是吃“文件很大”这口饭。

对 AI 产品前端尤其如此：很多团队最近会频繁更新 prompt 配置、模型开关、AB 实验和计费文案，这类改动通常很小，反而是 Shared Dictionaries 比较合适的地带。Cloudflare 此前公开内部 AI 工程栈时，我们就提过他们在 身份路由、上下文与审查链路 上更强调系统化；Shared Dictionaries 这次其实是把同样的思路推到了前端交付层：先找重复成本，再对重复成本动手。

2）你的浏览器覆盖和代理环境，允许它工作吗？

Cloudflare 官方 demo 也把限制写得很直白：当前需要 Chrome 130+ 或 Edge 130+，而且某些 TLS 拦截代理、公司代理、WARP 等中间层可能让浏览器不发送共享字典相关头部。

这意味着它不是那种“你在 CDN 勾个开关，全用户马上受益”的优化。更稳妥的方式，是先确认：

• 你的核心用户是不是以新版 Chromium 为主
• 你的企业客户会不会普遍走 TLS 检查代理
• 你的监控能不能区分 gzip、brotli、dcz 的真实命中情况

如果这些前提都没确认，就很容易把 Shared Dictionaries 写成一篇很热闹的基础设施新闻，但落到真实业务里却没有稳定收益。

3）你能不能接受“更省字节，但不一定更快到首字节”

Cloudflare 在官方文章里明确提到：在 cache miss 的情况下，边缘侧做 dictionary lookup 和 delta compression 可能会带来一些额外延迟。他们自己的实验里说 TTFB 只比 gzip 慢大约 20ms；我这次最小复现也看到一个类似方向：dcz 的总请求时间并没有比 gzip 更短。

所以这项技术最该拿去优化的，不是“首字节要冲极限”的场景，而是：

• 用户反复打开同一应用
• 资源频繁更新
• 你更在意累计传输量和重复下载浪费
• 你愿意用一点额外边缘处理，换取更小的增量包

如果你的 KPI 主要是冷启动首屏、首访 TTFB，先把缓存、HTML、图片和脚本切分做好，优先级通常仍高于 Shared Dictionaries。

4）你有没有准备好回退和可观测性

这不是“发一个 header 就完事”的功能。

Cloudflare 当前公开的推进路径分两段：第一阶段是 passthrough，让你自己处理 dictionary 头、压缩和回退；第二阶段才是 Cloudflare 替你管更多复杂度。对大多数团队来说，真正该先准备的是：

• 命中失败时是否稳定回退到 gzip / Brotli
• 资源版本错配时会不会出现不可解释的缓存问题
• 监控里能不能分辨 dcz 命中率、gzip 回退率和代理影响
• 发布流程里能不能快速定位“哪次构建让相似度突然下降”

没有这些，Shared Dictionaries 很容易变成一个“图很好看、线上不好查”的优化项。

两个常见误区

误区一：Cloudflare Shared Dictionaries 是 Brotli 的直接替代品

不是。它更像建立在现有压缩与缓存机制之上的增量交付层。第一次请求通常仍然要走常规传输，真正的大幅节省往往发生在后续相近版本之间。

误区二：只要资源够大，Cloudflare Shared Dictionaries 就一定有效

也不是。关键变量不是“文件大不大”，而是“新旧版本像不像”。一个 500KB 但每次都彻底重编的 bundle，可能不如一个 90KB 但每次只改一点点配置的 bundle 更适合吃到收益。

FAQ

Cloudflare Shared Dictionaries 现在已经全面可用了吗？

还不能这样说。按 Cloudflare 官方文章，这项能力在 2026-04-17 的公开表述仍处在预览 / beta 推进阶段，文中提到的 beta 尝试时间点是 2026-04-30。如果你在看生产可用性，最好把它当成“值得测试的新能力”，不是“所有资产默认迁移”的成熟基线。

Cloudflare Shared Dictionaries 最适合哪类站点？

最适合的是频繁发版、资源版本之间高度相似、用户会反复回访同一前端应用的站点，例如控制台、AI 工具前端、文档站、内部平台。纯内容站、媒体站，或者资源差异很大的场景，收益通常没那么稳定。

Cloudflare Shared Dictionaries 会不会让响应时间变慢？

有这个可能。Cloudflare 官方就明确提到 cache miss 时可能增加少量开销；我这次最小复现里，dcz 虽然把 22,423B 压到了 140B，但总耗时从 0.641s 增到了 0.902s。它更像“用少传很多字节换一点边缘处理成本”的技术，而不是单纯提速按钮。

Cloudflare Shared Dictionaries 和普通缓存优化，先做哪个？

如果你连资源版本化、缓存命中、Brotli、代码切分都还没做好，先做那些。Cloudflare Shared Dictionaries 更适合拿来补“高频小改动导致重复下载”的后半程问题，而不是替代基础缓存治理。

结论

截至 2026-04-29，Cloudflare Shared Dictionaries 最值得试的，不是“所有网站都想更省流量”这个大而泛的理由，而是一个很具体的判断：你是不是那个每天频繁发版、改动又往往很小、却一直在让老用户重复下载近似 bundle 的团队。

如果是，那么它已经值得进测试队列；如果不是，它现在更像一个应该持续关注的基础设施方向，而不是你本周必须上线的优化项。

来源

• Cloudflare Blog: Shared Dictionaries: compression that keeps up with the agentic web
• Cloudflare 官方 demo: Can I Compress (with Dictionaries)?
• IETF: RFC 9842 — Compression Dictionary Transport