折腾CDN Gzip时，我发现最麻烦的往往不是安装，而是配置。很多人都有过这样的经历：明明装了宽带，打开一个网页却要等好几秒。在移动端，这感觉尤其明显。其中一大元凶就是传输的数据没有被压缩——就像寄一个棉被，直接塞进包裹和抽真空打包，体积能差好几倍。
在HTTP世界，压缩算法就是那个“抽真空机”。Gzip、Brotli和Zstd是目前主流的三种压缩格式。而CDN（内容分发网络）的边缘节点，恰好是站在用户和源站之间的“搬运工”，它能够根据双方的“喜好”自动选择最合适的压缩方式。这就是所谓的“动态协商”。
这篇文章不讲复杂的数学公式，也不手把手改配置，而是帮你彻底理解：这三种压缩算法到底是什么？CDN是怎么拍板的？以及你该怎么利用这套机制让网站更快。
一、压缩算法为什么对网页如此重要？
先看关键判断
一个典型的网页由HTML、CSS、JavaScript、图片、字体等组成。图片我们通常用WebP或AVIF等有损压缩，但文本类资源（HTML/CSS/JS/JSON）则依赖无失真压缩算法。这些算法能无损地缩减大小，浏览器解压后与原文件完全一致。
以一篇实际的博客首页为例：HTML原大小约150KB，Gzip压缩后降到45KB。Brotli甚至能压缩到38KB。节省的不只是流量，更是用户的等待时间——尤其是移动网络下，每减少100KB，加载时间可能缩短几百毫秒。
压缩算法各有千秋：有的压缩率高但慢，有的速度快但压缩率低。不同的资源、不同的网络条件，最优解都不一样。这就是CDN需要动态协商的原因。
补充参考：此处可内链到“CDN Gzip故障排查实例”。
二、三种压缩算法：出身、特点与适用场景
1. Gzip——老资格，兼容性最强
Gzip诞生于1992年，源自UNIX系统。它基于Deflate算法，属于LZ77和哈夫曼编码的组合。几乎所有Web服务器、浏览器、CDN都支持Gzip。它的压缩率中等，解压速度非常快。对于动态生成的页面（比如PHP实时渲染），用Gzip压缩CPU消耗极低。
优点：支持范围最广，任何现代浏览器都认。解压速度极快。CPU占用友好。
缺点：压缩率不如后两者，尤其在文本量大的场景下。
2. Brotli——谷歌出品，压缩率王者
Brotli由Google在2013年开源，2015年用于HTTP压缩。它采用更先进的LZ77变体、高阶上下文建模和二阶熵编码。相同的质量下，Brotli比Gzip多压缩20%～30%。但是它的压缩速度偏慢（尤其是最高压缩级别），解压速度与Gzip相当甚至略快。
Brotli内置了静态字典（预置常用英文单词和HTML标签），对文本内容效果极佳。因此它非常适合压缩HTML、CSS、JS此类有大量重复结构的文件。
优点：压缩率明显优于Gzip，静态文件效果拔群。
缺点：压缩时CPU消耗较高，动态压缩时会影响服务器吞吐；浏览器支持需要HTTPS（实际现在HTTPS已经是标配）。
3. Zstd——后起之秀，速度与压缩率的平衡剂
Zstd（Zstandard）由Facebook在2015年发布，2018年进入IETF标准。它的最大特点是：压缩速度可调节，且在不同级别下都表现出色。在“压缩率与Gzip相当”的级别下，Zstd的压缩和解压速度比Gzip快数倍；在“压缩率最高”的级别下，它又可逼近甚至超过Brotli。
Zstd还支持字典训练——对特定类型文件（如你的网站的模板文件）提前生成一个字典，压缩率能再提升10%～20%。不过这个功能在HTTP场景下还不太普及。
优点：速度极快，压缩率灵活可选，适合实时压缩；解压速度也很快。
缺点：浏览器的支持度正在追赶（Chrome 123+已原生支持，Safari 17+支持，Firefox 118+支持），但部分旧浏览器或中间代理可能不识。
三、CDN边缘节点如何“动态协商”？
CDN边缘节点是连接用户与源站的中间人。当用户请求一个资源时，边缘节点需要决定：把这个资源从源站拉回来时要不要压缩？用什么算法？返回给用户时又该用哪种？
这个过程涉及两次协商：
- 边缘节点 → 源站：回源请求时，CDN会带上
Accept-Encoding头，告诉源站自己支持哪些压缩算法。源站可以选择压缩后返回，或者返回原始内容让CDN自己压缩。 - 用户 → 边缘节点：用户发来的请求也带有
Accept-Encoding头，边缘节点根据用户支持的能力，决定返回哪种编码。
如果边缘节点缓存了资源，它甚至可能缓存多个压缩版本（比如Gzip版和Brotli版），然后根据请求头返回对应版本。这就是压缩缓存变体技术。CDN会优先尝试Brotli（如果用户支持），否则回退Gzip。Zstd正在被各大CDN支持，但还需要用户浏览器普及。
动态协商的典型流程
- 用户在浏览器输入网址，请求一个HTML文件。浏览器在请求头中声明：
Accept-Encoding: gzip, br, zstd（支持顺序）。 - CDN边缘节点收到请求，发现该资源不在缓存中（或缓存已过期）。于是向源站发出回源请求，并在回源请求中加上
Accept-Encoding: gzip, br, zstd（CDN自己支持哪些算法取决于配置）。 - 源站如果支持协商，根据自身优先生成最适合的压缩版本返回（例如Brotli）。如果源站不支持，则返回原始内容（无压缩），并在响应头标注
Content-Encoding: identity。 - CDN收到源站响应后，决定是否进行边缘压缩。如果源站已经压缩了，CDN不再重复压缩；如果未压缩，CDN会根据用户的请求头选择一种算法进行实时压缩。注意：实时压缩会增加CPU消耗，所以CDN通常会对大文件或热门文件采用“先存储压缩版本”策略。
- CDN将最终资源（可能是源站压缩版，也可能是边缘压缩版）返回给用户，响应的
Content-Encoding头设置为实际使用的算法。
几个关键配置点
- 源站是否开启压缩？ 建议源站关闭动态压缩或只保留Gzip。因为源站计算力有限，且CDN会重复压缩浪费资源。更好的做法是让源站返回原始内容，由CDN根据需要压缩。
- CDN支持哪些算法？ 大部分主流CDN已支持Gzip和Brotli；Zstd正在逐步开放。需要确认你的CDN服务商是否支持Zstd的边缘压缩。
- 缓存依赖Vary头：如果CDN按压缩算法缓存多个版本，它必须正确设置
Vary: Accept-Encoding，否则缓存会混乱。 - 优先级：通常CDN按算法质量、CPU消耗和浏览器支持度排序。一般优先级：Brotli > Gzip > Zstd（因为Zstd浏览器尚不普遍）。如果Zstd支持度提升，优先级可能变化。
相关阅读：此处可内链到“CDN Gzip常见问题”专题。
四、小白最需要记住的三件事
1. 开启Gzip是底线，Brotli是加分项
如果你的网站没有开启任何压缩，用户传输的都是纯文本，那加载速度至少慢一半。绝大多数CDN默认开启Gzip。如果你能手动开启Brotli（或者在CDN后台开启Brotli压缩），可以额外节省20%流量。
2. Zstd是未来，现在可以提前准备
虽然目前仅Chrome 123+和Firefox 118+原生支持，但Zstd的压缩速度和压缩率优势非常明显。如果你的用户群比较新潮（比如技术社区），可以尝试让CDN启用Zstd。要注意的是，CDN可能需要显式配置，并且要保证缓存命中。
3. 别让源站干压缩的活
很多新手在Nginx或Apache里开启动态Gzip压缩，然后又把CDN的回源压缩开着，结果导致“压缩两次”——源站压缩一次，CDN收到压缩后的内容，再解压、再压缩，浪费CPU。正确做法是：源站关闭压缩或仅保留低级别Gzip，让CDN来负责最终的压缩决策。
CDN Gzip：五、如何验证你的CDN是否做到了最佳压缩？
配置前的检查
打开浏览器的开发者工具（F12），切换到Network面板，找到一个HTML或JS文件，查看Response Headers中的Content-Encoding字段。如果值是br说明用了Brotli，gzip就是Gzip，zstd则是Zstd。如果完全没出现这个字段，说明没压缩——赶紧去CDN后台配置吧。
还可以使用在线工具如KeyCDN的压缩测试，输入你的网站URL，它会告诉你是否启用了压缩、压缩率是多少。
关联教程：此处可内链到“CDN Gzip部署与验证”内容。
进阶阅读：此处可内链到“CDN Gzip性能优化”指南。
想继续深入：此处可内链到“CDN Gzip优化清单”文章。
六、总结——CDN Gzip
验证与回滚
Gzip、Brotli、Zstd，本质都是帮你省流量的工具。CDN边缘节点的动态协商机制，能让不同浏览器和不同网络条件下都能拿到当前可用的最优压缩版本。作为站长，你不需要懂算法实现，只需要确保三点：CDN支持至少Gzip和Brotli；源站不重复压缩；留意Zstd的支持进度。
压缩算法虽然藏在背后，但它的优化效果立竿见影。下次再有人抱怨你网站慢，先检查一下Content-Encoding吧。后续只要定期检查关键指标，CDN Gzip就不会变成维护负担。
延伸阅读