网页体积直接决定用户的首屏体验和站点的带宽账单。同样是1MB的JS文件，经过合理压缩后传输量可能只有200KB，这中间的差距全靠压缩算法与协商机制来完成。腾讯云CDN内置了内容压缩功能，同时支持Gzip和Brotli两种算法，并根据客户端能力自动选择最优方案。本文围绕这套自动协商机制展开，讲清楚它的原理、配置方式和排查思路。
一、内容压缩的协商原理：Accept-Encoding说了算
CDN与浏览器之间的压缩协商，本质上是一个HTTP内容协商过程。浏览器发起请求时，会在Accept-Encoding请求头中声明自己支持的压缩算法，例如Chrome会发送Accept-Encoding: gzip, deflate, br, zstd，其中br就代表Brotli。CDN节点收到请求后，解析这个头，按照自身的优先级策略选择一种算法，对响应内容进行压缩，并通过Content-Encoding响应头告知浏览器实际使用的算法。
整个协商链路需要注意一个关键点：压缩发生在CDN边缘节点到浏览器这一段，而不是源站到CDN这一段。也就是说，即使你的源站不支持Brotli，只要在腾讯云CDN控制台开启了内容压缩，CDN会先向源站回源拿到原始内容（或源站已Gzip的内容并解压缓存），再对终端用户的请求动态选择压缩方式。这也是CDN内容压缩相比源站直接开启压缩的最大优势：源站只需提供一份内容，压缩策略由边缘节点灵活处理。
协商的优先级通常是：如果浏览器声明支持Brotli且CDN开启了对该文件类型的压缩，则优先返回Brotli压缩内容；否则降级到Gzip；两者都不支持则返回未压缩的原始内容。这种降级机制保证了老浏览器和部分非浏览器客户端（如低版本HTTP库）的兼容性。
二、Brotli与Gzip的差异对比
两种算法定位不同，理解差异有助于判断为什么CDN要同时支持两者。Gzip诞生于上世纪90年代，基于DEFLATE算法，几乎所有HTTP客户端都支持，是兼容性兜底方案。Brotli由Google推出，使用现代压缩技术和内置字典，对HTML、CSS、JS等文本资源的压缩率通常比Gzip高15%到25%。
但Brotli的高压缩率是有代价的：它的压缩计算开销更大，尤其在高压缩级别下，源站CPU消耗明显上升。不过这个代价对CDN场景影响较小，因为压缩由CDN边缘节点完成，且CDN可以将压缩结果缓存复用，不必每次请求都重新压缩。此外，Brotli在规范上要求仅在HTTPS连接中使用，HTTP明文请求通常不会协商到Brotli，这一点在排查问题时要特别注意。
| 对比维度 | Gzip | Brotli |
|---|---|---|
| 压缩率 | 基准水平 | 高15%至25% |
| 兼容性 | 几乎所有客户端 | 现代浏览器，仅HTTPS |
| 压缩耗时 | 较低 | 较高 |
| 适用场景 | 兜底方案 | 文本类静态资源 |
实际测试中，一个500KB的JS文件，Gzip压缩后约140KB，Brotli压缩后可能只有110KB左右。对于流量大的站点，这几十KB的差距乘以海量请求，节省的带宽费用相当可观。
三、腾讯云CDN控制台配置步骤
登录腾讯云控制台，进入CDN与加速产品下的域名管理，选择目标域名后，在高级配置或规则引擎中找到内容压缩相关选项。不同版本的入口略有差异，新版控制台一般在规则引擎中可以按文件类型、目录、文件后缀分别配置压缩策略，支持单独开启Gzip或Brotli。
配置时建议按以下原则操作：第一，对HTML、CSS、JS、JSON、XML、SVG等文本类资源开启压缩；第二，对图片、视频、字体等已经是压缩格式的文件保持关闭，二次压缩几乎无收益还会浪费CPU；第三，检查文件大小限制，CDN通常对极小文件（如几字节的响应）不压缩，因为压缩头开销反而更大。
配置完成后，可以用curl验证协商结果。例如请求一个JS文件并查看响应头：
curl -sI https://www.ippipp.com/static/app.js \ -H "Accept-Encoding: gzip, deflate, br" \ | grep -i content-encoding # 输出 content-encoding: br 说明命中Brotli压缩
如果去掉br再请求一次，响应头应该变成content-encoding: gzip，这就验证了自动协商机制在正常工作。
四、压缩不生效的常见原因排查
实际使用中，最常见的问题是配置了压缩但抓包发现内容没有压缩。第一类原因是命中了范围请求，带Range头的请求（如视频拖动播放）CDN通常不压缩，这是正常行为。第二类原因是Content-Type不在压缩范围内，例如源站返回的JS文件MIME类型写成了application/octet-stream，CDN不会对其压缩，需要修正源站的MIME配置。
第三类原因是客户端根本没声明支持。HTTP明文访问时Brotli不会生效，部分App内嵌的网络库也可能只声明gzip。排查时先用curl模拟浏览器的Accept-Encoding头做对照测试，确认问题出在CDN侧还是客户端侧。第四类原因是缓存的影响，压缩结果会被CDN缓存，修改压缩配置后需要刷新缓存或等待缓存过期才能看到新效果。
此外还要注意源站返回头的影响。如果源站已经返回了Content-Encoding: gzip的内容且CDN配置为透传压缩，CDN可能直接透传而不再二次压缩。这种情况下可以在CDN上配置忽略源站压缩头，让CDN接管压缩逻辑，从而对支持Brotli的浏览器返回更优的压缩结果。
五、最佳实践总结
综合来看，腾讯云CDN的内容压缩功能配置成本低、收益明确，推荐所有文本类站点默认开启。核心实践包括：全站启用HTTPS以获得Brotli支持；按文件类型精细化配置压缩规则；避免对已压缩格式做无意义的二次压缩；修改配置后及时刷新缓存并验证。
对于追求极致性能的站点，还可以在源站构建阶段预先产出Brotli和Gzip双份静态资源，配合CDN的自定义缓存键按Accept-Encoding分别缓存，进一步降低边缘节点的实时压缩开销。不过对大多数业务来说，直接使用CDN内置的内容压缩已经足够，简单可靠且维护成本几乎为零。