Cloudflare推出共享压缩字典，提升网页加载效率
Cloudflare AI··作者 Sid Chunduri
关键信息
共享字典利用客户端缓存的文件版本作为压缩参考，可使传输数据量减少高达90%；该功能将于2026年4月30日进入测试版。
资讯摘要
网页因框架和媒体内容日益丰富而逐年变重，同时由AI代理驱动的流量也在快速增长。传统压缩无法识别客户端已缓存的内容，造成大量冗余下载。Cloudflare的共享字典通过让服务器基于客户端已知内容进行压缩，只发送变化部分来解决这个问题。
例如，一个包含一行更改的500KB JavaScript包可缩减至几KB传输。这不仅节省了带宽，还显著提升了返回用户和代理的性能体验。
资讯正文
网页页面在过去十年中每年重量增加了6%至9%，这主要是因为网络变得更加以框架驱动、互动性更强且媒体内容更丰富。这一趋势不会改变。正在变化的是这些页面被重新构建的频率以及请求它们的客户端数量——两者都在急剧上升，原因在于代理（agents）的普及。
共享字典可以缩小从服务器到浏览器的资产传输量，使页面加载更快，并减少慢速连接用户在网络上的冗余数据传输。浏览器不再每次部署后都重新下载整个JavaScript包，而是告诉服务器自己已经缓存了哪些内容，服务器仅发送文件差异部分。
今天，我们很高兴向您展示我们对共享压缩字典的支持功能，分享我们在早期测试中观察到的效果，并透露您何时能亲自试用该功能的测试版（提示：2026年4月30日）。
问题：更多部署 = 更少缓存
代理爬虫、浏览器和其他工具会反复访问端点，获取完整页面，通常只是为了提取其中一部分信息。在2026年3月，代理行为占Cloudflare网络总请求数的近10%，相比去年同期增长约60%。
每一页都比去年更重，而且机器读取的频率也前所未有地高。但代理不仅是在消费网络，也在帮助构建网络。AI辅助开发意味着团队发布速度更快。增加部署频率、实验和迭代次数虽然提升了产品开发速度，却严重破坏了缓存效果。
当代理推送一行修复代码时，打包工具会重新分块，文件名发生变化，地球上每个用户都可能重新下载整个应用程序。并不是因为代码实质上发生了变化，而是因为浏览器或客户端无法准确知道具体哪些部分被修改了。它看到的是一个新URL，于是从零开始处理。传统压缩技术只能减小单次下载的体积，却无法消除重复内容。它不知道客户端其实已缓存了文件的95%。因此，每次部署，无论用户还是机器人，都会不断发送重复的数据包。每天发布十个微小变更，实际上就等于放弃了缓存机制。这在硬件正迅速成为瓶颈的网络环境中，浪费了大量的带宽和CPU资源。
为了应对更多请求、更重页面以及更高频部署带来的挑战，压缩技术必须变得更智能。
什么是共享字典？
压缩字典是服务器与客户端之间共享的一个参考表，类似于一份速查手册。服务器不是从头开始压缩响应内容，而是说：“你之前已经缓存过这部分内容了”，然后只发送新增的部分。客户端保存相同的参考表，在解压过程中利用它重建完整的响应内容。字典能引用文件中越多的内容，传输给客户端的压缩输出就越小。
这种基于已有内容进行压缩的原则，正是现代压缩算法超越前辈的关键所在。Brotli 内置了常见网页模式的字典，例如 HTML 属性和常用短语；Zstandard 则专为自定义字典设计：你可以输入代表性内容样本，它会生成针对你所提供内容的优化字典。而 Gzip 既没有内置字典，也必须在压缩过程中实时寻找模式来构建字典。这些‘传统压缩’算法如今已在 Cloudflare 上可用。
共享字典进一步深化了这一理念：之前缓存的资源版本本身成为字典。还记得那个部署问题吗？一个团队只改了一行代码，却导致每个用户都重新下载整个包？借助共享字典，浏览器已经缓存了旧版本。服务器可以基于该版本进行压缩，仅发送差异部分。原本 500KB 的包，因一行改动变成仅几 KB 的传输数据。每天 10 万用户、每日 10 次部署的情况下，这相当于从每天 500GB 的传输量减少到几百 MB。
差分压缩（Delta Compression）
差分压缩将浏览器已有的版本转化为字典。协议规定，当服务器首次提供某个资源时，会附带一个 Use-As-Dictionary 响应头，告诉浏览器保留该文件，因为它之后会派上用场。在下一次请求同一资源时，浏览器会返回 Available-Dictionary 请求头，告知服务器：“我这里有这个版本”。随后，服务器基于旧版本压缩新版本，并只发送差异部分——无需单独的字典文件。
这才是真实应用场景中真正体现价值的地方。适用于版本化的 JS 包、CSS 文件、框架更新，以及任何在发布之间逐步变化的内容。浏览器已经缓存了 app.bundle.v1.js，开发者更新并部署了 app.bundle.v2.js，差分压缩只需发送这两个版本之间的差异。后续每个版本也是如此，版本三基于版本二压缩，版本四十七基于版本四十六压缩。节省下来的流量不会重置，而是持续累积在整个发布历史中。
社区也在积极探讨非静态内容的自定义和动态字典方案。这是未来的工作方向，但其影响深远，我们将在另一篇文章中详述。
那么，为什么还要等呢？
如果共享字典如此强大，为何尚未被广泛采用？
因为上次尝试时，实现无法经受开放网络的考验。
Google 在 2008 年的 Chrome 中推出了 HTTP 共享字典压缩（SDCH）。一些早期使用者报告页面加载速度提升了双位数百分比，效果良好。但 SDCH 所积累的问题远超修复速度，最终未能成功落地。
最令人印象深刻的是压缩侧信道攻击（CRIME、BREACH）这一类攻击。研究人员表明，如果攻击者能够注入内容，并与某个敏感信息一起进行压缩（比如会话Cookie或令牌等），压缩输出的大小可能会泄露关于该秘密的信息。攻击者可以逐字猜测，观察资源大小是否缩小，重复此过程直到提取出整个秘密。
但安全问题并非唯一障碍，甚至不是主要原因。SDCH（Shared Dictionary Compression for HTTP）暴露了一些架构层面的问题，例如违反了同源策略（这恰恰也是它性能出色的原因之一）。它的跨域字典模型无法与CORS兼容，并且在与Cache API等机制交互方面缺乏规范。一段时间后人们意识到，这项技术尚未准备好被广泛采用，因此在2017年，当时唯一支持它的浏览器Chrome决定移除该功能。
让网络社区接手这项工作花了整整十年，但这一切都是值得的。
现代标准RFC 9842《压缩字典传输》填补了使SDCH不可行的关键设计空白。例如，它强制规定：声明的字典只能用于来自同一来源的响应，从而防止了许多导致侧信道压缩攻击发生的条件。
Chrome和Edge已经实现了该标准的支持，Firefox正在跟进。该标准正朝着广泛采用的方向发展，但完整的跨浏览器支持仍在追赶中。
RFC缓解了安全问题，但字典传输从一开始就是实现起来很复杂的任务。一个源站可能需要生成字典，用正确的头部服务它们，检查每个请求是否匹配Available-Dictionary字段，实时对响应进行差分压缩，并在客户端没有字典时优雅降级。缓存也变得复杂：响应因编码方式和字典哈希值的不同而变化，所以每个字典版本都会创建独立的缓存变体。部署中途，你将同时面对使用旧字典的客户端、新字典的客户端以及完全没有字典的客户端，你的缓存必须为每种情况分别存储副本。命中率下降，存储量上升，而字典本身还必须遵循正常的HTTP缓存规则保持更新。
这种复杂性本质上是一个协调问题，而这正是边缘计算最适合解决的事情。CDN本就位于所有请求之前，已经管理压缩，也处理缓存变体（敬请关注即将发布的公告博客）。
Cloudflare如何构建共享字典支持
共享字典压缩涉及浏览器与源服务器之间的每一层技术栈。我们已看到强烈的客户需求：一些人已经自行开发了实现方案，比如RFC作者帕特里克·米南（Patrick Meenan）的dictionary-worker，它利用WASM编译的Zstandard在Cloudflare Worker内部运行完整的字典生命周期（作为示例）。我们希望让所有人都能轻松访问并尽可能简化实施流程。因此，我们将分三个阶段在整个平台上推出该功能，首先从基础架构开始。
第一阶段：目前，旁路支持正处于积极开发中。Cloudflare 会转发共享字典所需的头部和编码格式，例如 Use-As-Dictionary、Available-Dictionary，以及 dcb 和 dcz 内容编码，不会删除、修改或重新压缩它们。缓存键也扩展为根据 Available-Dictionary 和 Accept-Encoding 变化，确保使用字典压缩的响应能被正确缓存。这一阶段服务于那些在源站自行管理字典的客户。
我们计划在 2026 年 4 月 30 日前推出第一阶段的公开测试版。要使用该功能，您需要处于启用了此特性的 Cloudflare 域名下，并且源站需提供带有正确头部（Use-As-Dictionary、Content-Encoding: dcb 或 dcz）的字典压缩响应，同时访问者必须使用支持 dcb/dcz 编码的浏览器（即 Chrome 130+ 和 Edge 130+，Firefox 的支持正在开发中）。
请持续关注变更日志，以了解何时可用，以及查阅更多使用说明文档。
我们已经内部开始测试旁路模式。在一个受控实验中，我们依次部署了两个几乎相同的 JavaScript 文件包，仅版本之间存在少量局部差异，代表同一 Web 应用的连续部署。未压缩时文件大小为 272KB；Gzip 压缩后降至 92.1KB，压缩率高达 66%。而使用 DCZ 共享字典压缩（以前一个版本作为字典），同一资产压缩后仅为 2.6KB，比已压缩版本再减少 97%。
在同一实验室测试中，我们测量了客户端的两个关键时间点：首次字节到达时间（TTFB）和完整下载完成时间。TTFB 结果令人意外——在缓存未命中（DCZ 需要在源站基于字典进行压缩）的情况下，相比 Gzip 仅慢约 20 毫秒，传输开销几乎可以忽略不计。
真正的差距体现在下载时间上。在缓存未命中时，DCZ 完成时间为 31 毫秒，而 Gzip 为 166 毫秒（提升 81%）；在缓存命中时，DCZ 为 16 毫秒，Gzip 为 143 毫秒（提升 89%）。由于响应体小得多，即使初期有轻微延迟，最终完成速度仍远超传统压缩方式。
初步实验室结果模拟的是最小 JS 包差异的情况，实际效果将取决于字典与目标资源之间的差异程度。
第二阶段：在此阶段，Cloudflare 将为您承担大部分工作。您不再需要在源站处理字典头部、压缩逻辑或回退机制。您只需通过规则指定哪些资源应作为字典，其余工作由 Cloudflare 自动完成：我们会注入 Use-As-Dictionary 头部，存储字典数据，对新版本进行增量压缩，然后向不同客户端提供合适的响应。您的源站仍然返回标准响应，所有字典相关的复杂性都将从您的基础设施转移至我们的平台。
为了直观展示这一过程，我们构建了一个实时演示页面，您可以点击此处体验：Can I Compress (with Dictionaries)？
共享字典：一种能跟上智能代理网络的压缩技术
演示部署每分钟都会更新一个约94KB的JavaScript包，模拟典型的生产环境单页应用包。大部分代码在每次部署之间保持不变，只有很小一部分配置内容会变化，这与现实中的部署情况一致——大多数包都是不变的框架和库代码。当第一个版本加载时，Cloudflare的边缘节点会将其存储为字典。当下一个部署到达时，浏览器会发送它已有的版本哈希值，边缘节点则基于此对新包进行增量压缩。结果是：94KB的包压缩到大约159字节，相比gzip实现了99.5%的压缩率，因为传输的内容仅仅是实际差异部分。
该演示网站包含操作指南，你可以通过curl或浏览器自行验证压缩比。
第三阶段：字典将自动为网站生成。无需客户指定哪些资源作为字典，Cloudflare会自动识别它们。我们的网络已经看到所有流经它的每个资源的每一个版本，涵盖数百万个站点、数十亿次请求以及每一次新的部署。其核心思路是：当网络观察到某个URL模式下连续响应内容大部分相同但仅哈希值不同，就说明该资源具有版本化特征，是一个适合增量压缩的候选对象。系统会将前一版本存储为字典，并以此压缩后续版本。整个过程无需客户配置，也无需维护。
这是一个简单的理念，但实现起来确实非常困难。安全地生成字典以避免泄露隐私数据，并准确识别出最受益于字典压缩的流量，这些都是真实的工程挑战。但Cloudflare具备了正确的条件：我们能看到全网的流量模式，我们已经管理着字典需要存储的缓存层，同时我们的RUM信标可以向客户端发送信号，帮助我们建立一个验证循环，在正式提供之前确认某个字典是否真正提升了压缩效果。流量可见性、边缘存储和合成测试的结合，使得自动生成功能成为可能，尽管仍有许多细节有待解决。
第三阶段带来的性能和带宽优势正是我们推动这项工作的核心动力。这使得共享字典对所有使用Cloudflare的用户都变得可用，包括那些从未有时间手动实现自定义字典的数百万个站点。
更广阔的视角
在互联网历史的大部分时间里，压缩都是无状态的——每个响应都被当作客户端从未见过任何内容一样来处理。共享字典改变了这一点：它让压缩拥有了记忆。
这比五年前更加重要。代理编码工具正在压缩部署之间的间隔，同时也在推动越来越多的流量消耗这些部署。虽然如今AI工具可以生成巨大的代码差异，但代理正获得更多的上下文信息，并在代码修改上变得更加精准。这与更频繁的发布和更自动化的客户端相结合，意味着每次请求中都会出现更多冗余字节。差分压缩通过减少每次传输的字节数量，以及减少需要发生的传输次数，从而同时优化了这两个方面。
共享字典的标准化花了数十年时间。Cloudflare 正在帮助构建基础设施，使每一个访问你网站的客户端——无论是人类还是机器——都能使用这项技术。第一阶段测试版将于4月30日开放，我们非常期待你能尝试一下。
1Bots = 所有HTTP请求的约31.3%。AI = 所有机器人流量的约29-30%（2026年3月）。
来源与参考
收录于 2026-04-18