Gzip 与 Brotli

Gzip 与 Brotli 是两种压缩算法，压的是文本响应。开这一层的原因很直接：HTML、CSS、JavaScript 这些文本文件的体积可以压掉一大截，传输时间随之下降，而加载性能正是 LCP 衡量的一项，它属于核心 Web 指标^[1]。

两者的分别是压缩率与代价

Gzip 出现早，支持面广，服务器与浏览器都默认认它。Brotli 的字典更大、压缩率更高，代价是压缩时更耗 CPU，因此常见做法是分工，Brotli 管静态与可预压缩的资源，其余交给 Gzip。web.dev 的两份压缩实践分别对应这两种算法，都在减小请求体积这条线上^[2][3]。

协商由 HTTP 头完成：客户端把自己支持的算法写进 Accept-Encoding，服务器在响应的 Content-Encoding 里写实际用了哪一种。

与打包步骤的关系

压缩与缩小是两步。缩小去掉空格、注释与不必要字符，压缩把剩下的文本重编码。web.dev 的实操顺序是先缩小再压缩，只看打包体积数字会误判^[2]。

图片不适用这一层，它有自己的编码方式，重复压缩反而变大。

配置上的几个坑

只压文本类型。把已压缩的资源（图片、视频、zip）再送进 gzip 或 brotli，白烧 CPU。

设最小字节阈值。太小的文件压完省不了什么，反而增加一次处理。

等级不必拉满。Brotli 的等级从低到高，高收益的差别在等级中段就收敛，等级拉满会明显加重服务器负担^[3]。

不要按用户代理决定给谁压缩。压缩与内容呈现无关，按爬虫身份改响应，会让抓到的页面与用户看到的不一致^[4]。

验证办法

看响应头里的 Content-Encoding 与实际字节数。同一 URL 分别在开启与关闭时取一次大小，差异要能覆盖 CPU 开销。浏览器侧的加载瀑布里也能看到传输大小与资源大小两个数^[2]。

常见误用

第一种是只看分数不看字节。第二种是启用了模块却没设 MIME 白名单，实际没压。第三种是把 CDN 与源站两边同时开启，重复劳动^[3]。

附录

参见

• 关键渲染路径
• 页面性能
• Core Web Vitals
• 反向代理

参考资料

官方（境外）

1. 《了解 Core Web Vitals 和 Google 搜索结果》，Google 搜索中心。
2. 《使用 gzip 缩减和压缩网络载荷》，web.dev。
3. 《使用 brotli 缩减和压缩网络载荷》，web.dev。
4. 《创建实用、可靠、以用户为中心的内容》，Google 搜索中心。

外部链接

• HTTP Semantics（RFC 9110），IETF。