为什么同一家网站越逛越省流量？网页也有共同词典

打开同一家网站的两个页面，你下载的导航栏样式、组件代码和常用文字往往高度相似。普通压缩会在每一个响应内部寻找重复，但如果浏览器已经拥有上一版文件，能不能直接告诉服务器：“共同部分我有了，只把差异发来”？

Compression Dictionary Transport（压缩字典传输）正是在做这件事。网站可以指定一个资源作为未来响应的字典，让压缩器引用浏览器已有的字节，从而减少重复传输。

普通压缩先在一个包裹里找重复

网页文本、CSS 和 JavaScript 含有大量重复。服务器使用 gzip、Brotli 等算法，把重复片段替换成更短的引用；浏览器收到后再还原。双方通过 Accept-Encoding 与 Content-Encoding 等 HTTP 头协商算法。

这种方式像搬家时给每个箱子单独做编号：同一只箱子里的重复物品可以简写，但另一个箱子即使装着类似东西，也要重新描述。

共享字典则像双方都拿着一本常用语手册。服务器不必再次发送整段内容，只要说“引用手册第几页，再补上这些新字节”。MDN 的 HTTP 压缩指南举了很直观的例子：浏览器已有 app.v1.js 时，可以把它作为下载 app.v2.js 的字典，大部分传输只需包含两个版本的差异。

缓存解决的是“这个资源我是否已经完整拥有”。若文件没有变化，浏览器可以直接复用，不必下载；一旦 URL 或内容版本改变，传统缓存通常要获取新文件。

压缩字典解决的是“新资源与我已有内容有多少相似”。即便新版必须下载，只要大部分字节相同，旧版仍能帮助压缩。两者不是替代关系：缓存避免不必要的请求，字典降低必要请求的体积。

浏览器必须确认字典确实可用，服务器也要知道客户端拥有哪个版本。缓存过期、字典被清理或内容不匹配时，系统需要安全退回普通响应，否则浏览器将无法解压。

跨用户内容尤其敏感。若压缩过程把私密页面与攻击者可控制的文本混合，响应大小变化可能泄露秘密，这类压缩侧信道在网络安全中已有先例。因此字典的来源、适用范围和缓存分区需要严格约束，不能为了省流量把个人账户页面当作公共词典。

内容分发网络和代理也可能影响协商。如果缓存没有正确区分“支持某字典”与“不支持字典”的客户端，就可能把无法解码的响应发给错误对象。部署时必须正确设置响应头、缓存键和回退路径。

版本之间高度相似的大型 JavaScript、CSS、字体子集或结构重复的页面，是自然候选。已经高度压缩的 JPEG、视频和压缩包通常收益很小，再压一次还可能因额外元数据变大。

收益也取决于用户是否会继续访问同一站点。只打开一次的落地页，下载字典本身可能得不偿失；频繁使用的 Web 应用不断更新大型资源，更有机会摊薄成本。

共享压缩字典不会让网站神奇地“越用越快”，它只是更聪明地利用浏览器已经下载的知识。最理想的网络请求不是更快地重发同样内容，而是双方先确认共同拥有多少，再只传真正新增的部分。