Google 靠共享字典把搜索页从 107KB 压到 60KB，但 rel=compression-dictionary 的 crossorigin 一直被 Chrome 忽略——156 今天让它从失效变生效

Google 搜索结果页用一个共享字典把响应从 107KB 压到 60KB，但你把字典放到 CDN 独立域、给 link 标签加上 crossorigin 之后，Chrome 156 之前这个属性根本没人读——取字典的请求不带 CORS 语义、referrer 策略也不生效，等于跨域字典白配。Chrome 156 把取字典请求的 destination、mode、credentials、referrer 四件事全部按规范补齐，crossorigin 和 referrerpolicy 从「装饰品」变成真正管用的配置。

先说清楚这个压缩机制是什么。 Compression Dictionary Transport（压缩字典传输）从 Chrome 130 开始可用：服务端先给浏览器一份「字典」，之后同站点的响应就用这份字典做差分压缩，编码标成 dcb（Dictionary-Compressed Brotli）或 dcz（Dictionary-Compressed Zstandard）。原理和 Brotli 内置字典一样——高频内容不再传第二遍，只传引用。字典可以是站内已有资源（比如用 app.v1.js 压 app.v2.js），也可以是一份独立的字典文件。

Google Search 是目前最有说服力的生产案例。 搜索结果页（SRP）内容每天多次更新，Google 给它单独建了一个字典：服务端在响应里发 Link 头声明字典，字典本身带 Use-As-Dictionary 头限定匹配范围，浏览器下次请求时回带 Available-Dictionary 头。Chrome 官方博客给的实测数字：首次访问是完整 Brotli 压缩的 107KB，二次加载走字典压缩后只剩 60KB，体积降了 44%。DevTools 的 Network 面板里能直接看到 Content-Encoding 从 br 变成 dcb——你不用改 HTML，改的是服务器响应头。

# 服务端首次响应（示意）
Link: <https://static.example.com/dict/srp-zh.dict.br>; rel=compression-dictionary

# 字典资源本身的响应头
Use-As-Dictionary: match=/search/*

# 浏览器二次请求时带上
Available-Dictionary: srp-zh.dict.br

问题出在字典和页面不同源的场景。 线上站点的字典通常放 CDN 独立域（static.example.com 之类），于是你会老老实实写：

<!-- Chrome 155 及之前的实际行为：这两个属性取字典时被忽略 -->
<link rel="compression-dictionary"
      href="https://static.example.com/dict/srp-zh.dict.br"
      crossorigin
      referrerpolicy="no-referrer">

但 2026 年 9 月 18 日的 blink-dev Intent to Ship 写得很直白：在那之前，浏览器抓 rel=compression-dictionary 链接时不看 crossorigin 属性，也不看 referrer 属性，请求的 mode、credentials、referrer、referrerpolicy 四项都没有正确设置。后果分三种：

• 字典按 CORS 规则必须走 CORS 校验的场景，请求却是非 CORS 模式，校验语义对不上；
• 需要带 cookie 鉴权的私有字典，credentials 处理不对，要么带错要么拿不到；
• referrerpolicy="no-referrer" 写了等于没写，referrer 照发不误——字典域名商能从 Referer 头看到你的页面地址。

Chrome 156 的修复就是把这四件事按规范接回请求管道，同时给取字典的请求设上了正确的 destination（compression-dictionary），crossorigin 和 referrer 属性从此生效。同一份 HTML，行为差异：

改动来自规范层的同步推进：whatwg/html 的 PR #11620 于 2026 年 9 月 18 日提交 Intent to Ship，配套的 web-platform-tests 覆盖了 destination、跨域 crossorigin、referrer/referrerpolicy 三组场景；Mozilla 正在 Firefox 对齐实现，Igalia 正把 WebKit 侧实现往上游合。也就是说这轮修完，三引擎行为会真正收敛，不会再出现「Chrome 能压、Firefox 拉不到字典」的分裂。

一个部署时必踩的坑提前说： MDN 明确标注，站点如果有 Content-Security-Policy，connect-src（没写就回落到 default-src）必须放行字典 URL，否则字典请求会被 CSP 直接拦掉——这种失败在页面上没有任何报错，只表现为「二次加载体积没变小」。

今天可以做的三步：

1. 打开 DevTools Network，勾上 Preserve log，刷新两次你的站点首页，看有没有第二个响应的 Content-Encoding 是 dcb/dcz——没有就说明字典没配上；
2. 如果字典在独立 CDN 域，检查 link 标签的 crossorigin 和 referrerpolicy 是否写齐，等 Chrome 156 覆盖到你的真实用户后复测（Google 的公开案例是 107KB → 60KB，你的首页 JS 体积差不多就能套这个量级估收益）；
3. 有 CSP 的站点，先把字典 URL 加进 connect-src 白名单，再谈压缩收益。