网页越来越重，缓存越来越废，共享字典怎么救场

Cloudflare 的人最近盯上了一个老问题：网页每年胖 6-9%，缓存却越来越不管用。他们的解法叫"共享压缩字典"，beta 版定在 2026 年 4 月 30 日开放。

问题一：Agent 正在吃掉你的带宽预算

2026 年 3 月，Cloudflare 网络里近 10% 的请求来自 Agentic 爬虫和工具，同比增长约 60%。这些机器不像人类用户——它们反复抓取完整页面，往往只为提取一小段信息。

更麻烦的是，AI 辅助开发让团队部署频率飙升。一次一行代码的修复，打包工具重新分块，文件名全变，全球用户被迫重新下载整个应用。浏览器看到新 URL 就归零重来，不管实际代码差异有多小。

传统压缩算法只管把单个文件压小，不知道客户端已经缓存了 95% 的内容。一天部署十次，就等于主动放弃缓存。带宽和 CPU 被反复浪费，而硬件正在成为新的瓶颈。

问题二：字典是什么，怎么省流量

压缩字典是服务器和客户端之间的一份"共享参考书"。压缩时，服务器不再从零开始，而是直接引用客户端已缓存的内容，只传真正新增的部分。

客户端用同一份字典解压，把碎片还原成完整文件。字典能引用的历史内容越多，传输体积就越小。

这个思路不算新——现代压缩算法本身就是基于"已知内容"做差分。但共享字典把它从单机内存搬到了网络层，让跨会话、跨部署的重复数据真正被利用起来。

问题三：为什么现在必须做

三个趋势在同时恶化：

• 页面体积：十年持续增长，框架化和富媒体没停过
• 请求频次：Agent 占比一年内涨六成，且只读片段却要拖整页
• 部署密度：AI 写代码越快，缓存失效越频繁

旧假设是"部署少、缓存久"，新现实是"天天发版、秒级迭代"。共享字典把优化目标从"首次加载"转向"增量更新"，让频繁部署不再等于流量灾难。

实用判断：谁该盯着 4 月 30 日

如果你的团队符合以下任意画像，这个 beta 值得排期测试：

• 日部署超过 3 次，用户抱怨"怎么又刷新这么久"
• 前端 bundle 超过 500KB，且骨架屏之外还有大量重复代码
• Agent/爬虫流量占比超过 5%，CDN 账单里"回源"项在涨
• 服务新兴市场，用户设备存储大但带宽贵

共享字典不解决首次访问的速度，但能把"老用户回流"和"小版本迭代"的成本打下来。在 Agent 重构 Web 流量结构的当下，这种针对"重复拉取相同内容"的优化，比再压几个百分点更有杠杆效应。