content-encoding 实测 27 个首页：不声明压缩要多下 7.5 倍

实测 · 2026-09-02 · 27 个首页 · 各请求三次 · Accept-Encoding 协商

样本 / 口径：30 个站在 2026-09-02 各发一次 GET 定面板，桌面 Chrome UA（不是 Googlebot），跟随跳转，不执行 JavaScript。剔掉 3 个 —— stackoverflow.com 与 medium.com 返回 403，www.reddit.com 只回了一个 8,393 字节的空壳 —— 纳入 27 个。这 27 个各再发三次，只改 Accept-Encoding，关掉自动解压后数线上字节。

先说最能换算成钱的那个数：同样 27 个首页，请求头里不声明压缩，要下 18,593,772 字节；完整协商只要 2,490,063 字节，差 7.5 倍。而这次的 content-encoding 分布是 16 个站回 br、11 个回 gzip，zstd 一个都没有 —— 尽管每一次请求都声明了它。

怎么测的

每站三次 GET，UA、跟随跳转、超时全部一样，只差一个请求头：

响应体是关掉自动解压读的，所以下面每个字节数都是真正跨网络的量，不是解压后 HTML 的长度。三跑要放在同一把尺子上比，只能这么读。

# 在自己的站上跑同样三次
for ae in 'gzip, deflate, br, zstd' 'gzip' 'identity'; do
  curl -s -o /dev/null -H "Accept-Encoding: $ae" \
    -w "$ae -> %{size_download} bytes\n" https://example.com/
done

两条限制要摆在前面。三次请求隔了几秒，不是同时发的，而这批页面本身会变 —— 11 个 gzip 站在「完整」和「只 gzip」两跑里用的是同一个算法，字节仍然差了最多 1,316（www.nytimes.com）。所以 2% 以内的差一律当噪音。另外这次只量了传输：没渲染、没绘制、没计时。

不声明压缩，同样的页面要多下 7.5 倍

27 个站全部认 Accept-Encoding: identity，老老实实发了原文，没有一个站无视请求强行压缩。整批加起来是 18,593,772 字节对 2,490,063 字节。

逐站看，倍数从 stripe.com 的 3.6 倍到 www.theverge.com 的 15.4 倍，中位数 7.1 倍。过 10 倍的有四个：www.theverge.com 15.4、supabase.com 14.2、www.cloudflare.com 12.5、www.framer.com 11.6。

这个数对自己写检测脚本的人最要紧。Google 的说法很直白：「Google's crawlers and fetchers support the following content encodings (compressions): gzip, deflate, and Brotli (br).」，而且这份支持「is advertised in the Accept-Encoding header of each request they make」（Google Crawler Overview，2026-09-02 访问）。一个忘了带这个头的自写脚本，行为不像 Googlebot，像 identity 那一列。

压缩是协商出来的，不是配出来的。忘了开口要的那一方付账，在这批站上要付七倍。

content-encoding：16 个站回 br，11 个回 gzip，zstd 零

没有一个站拒绝压缩。这是第一个结果，也是个无聊的结果 —— HTML 压缩这件事已经定了，2026 年还在发未压缩 HTML 的站，这份样本没抓到。

比总数更值得看的是那个分法。brotli 并不是到处都默认开：27 个里有 11 个 —— 包括 github.com、stripe.com、www.wikipedia.org、www.bbc.com、www.nytimes.com —— 面对一个明确声明了 brotli 的请求，回的仍是 gzip。这几家都不是小团队。不管原因是什么，声明 br 不等于拿得到 br。

zstd 是这句话的另一半。完整跑的每一次请求都声明了 zstd，27 个站没有一个用它回。MDN 把这个取值记在文档里，出处是 RFC 8878（Content-Encoding，2026-09-02 访问）。在这 27 个首页上，它是有文档、没人用。

brotli 比 gzip 省 31.6%，但站与站差得离谱

拿完整跑和只 gzip 跑在那 16 个 brotli 站上对比：2,071,362 字节变成 1,417,422 字节，16 个首页合计省下 653,940 字节，相当于 gzip 那一档的 31.6%。这个平均数里面的分布非常散。

一头 64%，一头 4%，换的是同样两个算法。压缩等级是服务器上的一个设置，brotli 有十一档，开得低就会落到 gzip 附近。这些站各自用的哪一档我们没测，也分不开它和 HTML 本身的差异。

这对你的站意味着什么

服务器上查两件事，脚本上查一件。

1. 确认源站面对一个声明了 br 的请求真的会回 br。这批里有 11 个站没做到，而从外面看它们的配置都很正常。
2. 已经在发 brotli 的，先看压缩等级再加别的。上表里 4% 和 64% 的差距是设置差距，不是算法差距。
3. 凡是会去请求自己站点的脚本，都把 Accept-Encoding 带上。同样的页面数，七倍的带宽，日志里还会多出一个不像真实客户端的访客。

「站好像很慢」这句话里通常混着三个数。HTML 本身的重量在 首页源代码到底有多大，第一个字节前的等待在 网站速度实测。这些字节值不值得你花时间，是另一个问题，答案在 crawl budget 是给谁准备的。想看这些都还没调之前，一次抓取从你自己的页面上拿到什么，可以 看看 QueryWin 怎么读一个页面。

常见问题

你们是怎么测的？

2026-09-02 每个首页三次 GET，桌面 Chrome UA 完全一致，只差 Accept-Encoding：先 gzip, deflate, br, zstd，再 gzip，最后 identity。响应体关掉自动解压后计长度。跟随跳转，不执行 JavaScript，出口在日本大阪。

brotli 一定比 gzip 小吗？

这 16 个站上每次都更小，幅度在 4.2% 到 64.4% 之间。放到一般情况不保证：低等级的 brotli 压已经压过一遍的 HTML，可能和 gzip 落在噪音范围里，而各站用的哪一等级我们没测。

为什么一个站都没回 zstd？

不知道。每次请求都声明了它，27 个站全都选了别的。这和「源站与 CDN 没开」是对得上的，但这次的测法区分不了「不支持」和「支持但不优先」。

content-encoding 影响 SEO 吗？

不直接影响，本篇也没有任何排名数据。它改变的是爬虫在同一个页面上花掉多少字节，那是带宽问题，不是质量问题。Google 自己的爬虫声明支持 gzip、deflate 和 br，你给什么它拿什么。

11 个站还在用 gzip，要替它们担心吗？

不用。这 11 个的意义在于：一个站可以在别的地方都做得很好，唯独把这一次协商留在默认值上。所以与其假设 CDN 已经处理好了，不如自己在源站上读一次这个头。