选择 Brotli 还是 Gzip，不必把问题简化成“谁压得更小”。边缘节点既要缩短传输时间，也要避免压缩计算拖慢动态请求，并确保不同编码版本被正确缓存。理解Brotli与Gzip压缩在边缘分发中的适用差异后，可以按内容类型和生成方式配置，而不是全站只开一种。
先看内容：文本与已压缩文件不是一回事
HTML、CSS、JavaScript、JSON、XML 等文本通常能从压缩中获益；其中 Brotli 对不少文本内容压缩得更紧凑，代价是高压缩级别可能需要更多计算。Gzip 压缩速度快、兼容范围广，适合作为稳妥的通用方案。实际节省量受文件结构、压缩级别和内容重复度影响，不宜用单一比例推算所有站点。
JPEG、PNG、WebP、AVIF、MP4 和 ZIP 等格式已经经过压缩，再套一层 Brotli 或 Gzip 通常收益很小，有时还会增加处理开销。可在边缘配置中按 MIME 类型筛选对象，避免对这类文件重复压缩。
边缘分发中的关键差异
| 比较项 | Brotli | Gzip |
|---|---|---|
| 传输体积 | 对许多文本资源压缩效果较好 | 通常稍逊，但足以满足常见传输需求 |
| 计算开销 | 高压缩级别可能较耗计算，适合离线预压缩或缓存复用 | 压缩迅速，适合需要即时生成的响应 |
| 客户端兼容 | 现代浏览器普遍支持，仍需检查目标客户端 | 兼容性广，可作为回退选择 |
| 常见用途 | 长期缓存的脚本、样式表和静态页面 | 动态文本响应及需要广泛兼容的场景 |
边缘节点通常依据请求中的 Accept-Encoding 选择客户端支持的编码，再返回相应的 Content-Encoding。若同一资源可能返回 Brotli、Gzip 或未压缩版本，缓存必须区分这些变体；可通过正确设置 Vary: Accept-Encoding，或使用边缘平台提供的编码协商与缓存键机制。否则，可能出现缓存命中却发给客户端不支持的编码，或不同版本相互覆盖。
按静态与动态请求分别配置
静态文件：优先评估 Brotli 预压缩
对版本化的 JavaScript、CSS 和长期缓存的 HTML，可以在构建或发布阶段生成 Brotli 文件，让边缘节点直接读取成品，减少每次请求的压缩负担。Gzip 文件也可一并保留，供不支持 Brotli 的客户端使用。文件名、响应头和缓存规则应保持一致，发布新版本时同步更新压缩产物。
动态响应：先测延迟，再调压缩级别
搜索结果、个性化页面或接口 JSON 每次内容可能不同，不一定适合高强度实时压缩。可先用较低压缩级别测试 Gzip，再对边缘平台支持的 Brotli 动态压缩做对照；观察响应时间、边缘计算用量和实际传输字节数。请求量、响应大小和节点规格都会影响结果，不能仅凭压缩率决定。
实操选择：从小范围验证开始
- 盘点响应类型。区分文本、图片、视频、归档文件，并记录主要静态资源与动态接口。
- 检查客户端协商。确认边缘规则会参考 Accept-Encoding，并为不支持 Brotli 的请求保留 Gzip 或原始响应。
- 配置缓存变体。核对 Vary 响应头或平台缓存键，分别验证 Brotli、Gzip 与未压缩版本。
- 抽样对比。对同一文本资源记录压缩前后字节数、边缘响应时间和缓存命中情况；在相同地区、相近负载下重复观察，避免把网络波动当成压缩收益。
- 分阶段上线。先覆盖静态文本，再评估动态响应；若边缘计算成本或延迟上升，就降低压缩级别或改用预压缩。
结论与常见问题
总体上，静态文本且能复用压缩产物时，可优先选择 Brotli；动态内容、计算预算有限或兼容要求更宽时，Gzip 往往更直接。两者并非只能二选一：同时提供编码变体并正确处理协商和缓存，通常更灵活。落实Brotli与Gzip压缩在边缘分发中的适用差异，重点是让压缩收益覆盖额外计算与配置成本。
常见问题
问：所有资源都应该开启压缩吗？
答：不应如此。优先压缩 HTML、CSS、JavaScript 和 JSON；已压缩的图片、视频及归档文件通常跳过。
问：Brotli 是否一定比 Gzip 快？
答：不一定。Brotli 常能减少文本传输字节，但压缩计算可能更重；预压缩资源和实时动态响应的结果也不同。
问：只启用 Brotli 可以吗？
答：若需要照顾不支持 Brotli 的客户端，应保留 Gzip 或未压缩回退，并确认边缘缓存不会混淆不同编码版本。