从带宽账单和加载速度说起
我的处理经验
CDN Brotli看似简单，真正落地时却很容易踩坑。每个运营网站的人都会遇到两个问题：每月带宽费用越来越高，用户却抱怨页面加载慢。压缩技术是解决这两个矛盾的利器——同样一份数据，压缩后体积变小，传输更快，带宽消耗也更低。但传统gzip压缩已经用了二十多年，还有优化的空间吗？Brotli和Zstd给出了答案。
不过，更强的压缩意味着更多的计算量。CDN边缘节点每天处理海量请求，如果每个压缩操作都消耗更高的CPU，会不会影响节点响应速度？这正是本文要讨论的——如何通过合理配置，在CDN边缘节点上使用Brotli或Zstd动态压缩，找到带宽节省与CPU负载之间的平衡点。
补充参考：此处可内链到“CDN Brotli故障排查实例”。
延伸阅读：此处可内链到“CDN Brotli配置案例”相关文章。
Brotli和Zstd是什么？——CDN Brotli
Brotli：Google专门为Web打造的算法
Brotli由Google在2013年提出，2015年标准化。它的设计目标就是替代gzip用于HTTP压缩，尤其针对文本类资源（HTML、CSS、JS）。Brotli的压缩率比gzip高20%～30%，这意味着同样的文件可以再缩小约四分之一。代价是压缩和解压缩都需要更多CPU时间，尤其是压缩时的计算量可能比gzip高出数倍。
Zstd：Facebook出品，兼顾速度与比率的“多面手”
Zstd（Zstandard）由Facebook在2015年发布，近年迅速流行。它最大的特点是支持可调节的压缩等级：等级1非常快，但压缩率一般；等级22会非常慢，但能逼近极限压缩比。在常见的中低等级（3~5），Zstd的压缩速度比gzip快，解压缩速度更是惊人，同时压缩率优于gzip，接近Brotli。所以Zstd在需要快速压缩的场景（比如实时日志压缩、CDN边缘压缩）中很有优势。
简单记忆：Brotli压缩率最高，但消耗CPU最多；Zstd在速度和压缩率之间平衡得更好；gzip则是老牌选择，兼容性极佳但效率已落后。
动态压缩vs静态压缩，CDN边缘节点该用哪种？
我的处理经验
在CDN场景下，压缩可以分为两种模式：
- 静态压缩：源站在生成文件时预先压缩好（比如将.css.gz或.css.br文件上传），CDN直接缓存并分发压缩后的内容。这种模式不消耗CDN边缘节点的CPU，但需要源站管理多个版本的文件。
- 动态压缩：CDN边缘节点收到请求后，实时对原始文件进行压缩并返回。源站只需要按原始文件响应，CDN节点负责压缩，同时可以根据请求头的Accept-Encoding选择不同的算法。这种模式灵活，但每次压缩都会消耗边缘节点的CPU。
大部分CDN服务商会默认使用静态压缩（预压缩）或gzip动态压缩。当你启用Brotli或Zstd动态压缩时，相当于告诉CDN：“用更强的算力去压缩，换取更小的传输体积。” 这对热门资源（比如首页、核心JS）特别有效，因为压缩后的文件可以被缓存，后续请求不再重复压缩。
想继续深入：此处可内链到“CDN Brotli优化清单”文章。
CPU与带宽的平衡：把资源花在刀刃上
开启更强的压缩算法是否划算？需要看具体的收益。
节省的带宽
假设一个HTML页面原始大小100KB，gzip压缩后30KB，Brotli压缩后22KB。每次请求节省8KB流量。如果一个热门资源每天被请求100万次，节省的带宽约8GB/天。按CDN流量单价0.2元/GB计算，每天节省1.6元，一年近600元。如果多个资源都这样，效果可观。
消耗的CPU
压缩等级越高，CPU消耗越大。Brotli的默认等级（4~6）压缩每个100KB文件约需要5～10ms（取决于节点CPU性能），而gzip只需1～2ms。如果节点每秒处理1万个请求，全部做Brotli动态压缩会额外消耗约50个CPU核心，这是无法接受的。因此，CDN服务商通常只在“首次请求”或“缓存未命中”时做动态压缩，一旦压缩完成，结果会存入缓存，后续直接返回缓存内容，不再消耗CPU。
这揭示了一个核心原则：动态压缩的开销只体现在初次回源或缓存过期时。对于静态资源（图片一般不需要压缩、视频已压缩），合理设置缓存策略后，Brotli/Zstd带来的额外CPU只在少数请求中出现，而带宽节省却是每一次请求。
如何在CDN边缘节点开启Brotli或Zstd动态压缩？
先看关键判断
主流CDN平台（如Cloudflare、Akamai、阿里云CDN、腾讯云CDN）都已支持Brotli和Zstd压缩。操作通常很直观，但不同平台的位置不同。这里给出通用思路：
- 登录CDN控制台，找到域名配置或性能优化选项卡。
- 寻找“压缩”或“内容优化”设置，通常会列出支持的算法（gzip、Brotli、Zstd）。有的平台需要额外付费或白名单开通（如Zstd还较新）。
- 选择开启Brotli、Zstd或两者都开。很多平台允许你指定优先级，比如客户端支持Brotli优先返回Brotli，否则回退到gzip。
- 配置缓存策略：确保静态资源有长缓存时间（如7天、30天），这样压缩后的内容长驻边缘节点，减少重复压缩。
- 注意回源头：CDN压缩通常要求客户端请求包含Accept-Encoding。对于不支持Brotli的旧浏览器，CDN需要自动降级到gzip或发送原始响应。
如果使用开源CDN软件（比如Nginx+Varnish+Traffic Server），可以手动启用Brotli模块和Zstd模块。Nginx的ngx_brotli模块和ngx_zstd_module（需第三方编译）可供选择。但在边缘节点上，建议优先使用CDN厂商的默认方案，避免自行管理带来的兼容性和性能问题。
进阶阅读：此处可内链到“CDN Brotli性能优化”指南。
实际效果与监控建议
验证与回滚
开启后，建议观察以下指标：
- 带宽节省率：比较开启前后CDN统计中的“回源带宽”和“总下行流量”。如果节省不明显，检查是否大部分资源已由gzip压缩，或者资源类型不适合（如图片、视频）。
- 边缘节点CPU使用率：CDN控制台通常有CPU指标（或代理率/压缩率）。如果开启后CPU飙升超过10%，考虑降低压缩等级（如Brotli从6降到4），或者限制只对特定文件类型（如text/*, application/javascript）开启。
- 用户端加载速度：通过WebPageTest或Lighthouse对比压缩效果，查看首字节时间（TTFB）是否有微妙变化。
一个常见的陷阱：如果CDN节点配置了“动态压缩所有内容”（包括图片、PDF），CPU会急剧上升，而压缩效果几乎为负（二进制文件压缩率低）。务必只对文本类资源启用Brotli/Zstd。
关联教程：此处可内链到“CDN Brotli部署与验证”内容。
风险与回滚
我的处理经验
任何配置变更都有风险。开启Brotli/Zstd动态压缩可能带来两个主要风险：
- CPU过载：在突发流量或回源高峰时，边缘节点可能因大量实时压缩而响应变慢。建议先在低峰期测试，并设置监控报警。
- 兼容性问题：极少数老旧客户端或网络中间件可能错误处理未知Content-Encoding。不过现代浏览器和CDN通常会自动协商，风险很低。
如遇问题，可快速回滚：在CDN控制台关闭压缩选项，或降级为仅用gzip。缓存不会立即失效，但新请求会使用旧配置重新压缩（或被gzip替代）。
一句话总结与CDN Brotli
先看关键判断
在CDN边缘节点上启用Brotli或Zstd动态压缩，本质上是用边缘节点的CPU资源换取带宽和加载速度的提升。由于缓存的存在，CPU开销只发生在初次或缓存过期时，而带宽节省长期有效。只要合理设置压缩范围、缓存策略和压缩等级，这绝对是一笔值得做的“投资”。后续只要定期检查关键指标，CDN Brotli就不会变成维护负担。
延伸阅读