应根据服务对象、资源类型和基础设施选 gzip 或 brotli：gzip 兼容性好、零依赖，适合旧环境或资源受限场景；brotli 压缩率更高（平均再减 15%–20%），适合现代浏览器与静态资源预压缩。
选 gzip 还是 brotli，关键不在“哪个更强”，而在于你的服务对象、资源类型和基础设施条件。Gzip 是开箱即用的稳妥选择；Brotli 在现代浏览器环境下能带来更小体积（平均再减 15%–20%），但需额外编译模块且不兼容 IE。
什么时候该坚持用 Gzip
Gzip 内置支持、零依赖、全兼容，适合大多数通用场景：
- 用户群体包含旧版浏览器、嵌入式设备或定制客户端（如某些 IoT 终端、微信内置 WebView 早期版本）
- 服务器 CPU 资源有限（如 1C2G 的轻量云实例），或并发请求密集（如 API 网关类服务）
- 内容高度动态（如模板实时渲染的 HTML、带用户态变量的 JSON 接口），无法预压缩
- 运维流程成熟，不愿引入第三方模块（如 ngx_brotli）或额外构建步骤
什么时候值得尝试 Brotli
Brotli 不是 Gzip 的替代品，而是补充策略——尤其适合静态资源主导、用户环境可控的站点：
- 主力用户集中在 Chrome/Firefox/Safari/Edge（即基本无 IE 流量）
- 大量构建产物（如 React/Vue 打包后的 JS/CSS/HTML）可提前用
brotli -Z预压缩，Nginx 只需按Accept-Encoding: br返回 .br 文件，运行时几乎不耗 CPU - 带宽成本敏感（如 CDN 回源费用高、海外节点出口受限），此时多压几 KB 比多花点 CPU 更划算
- 已启用
gzip_vary on并做好缓存分层，能避免因压缩格式混用导致的缓存错乱
Gzip 配置的几个关键实操点
默认开启 ≠ 高效压缩，几个参数直接影响效果与稳定性：
- gzip_comp_level 设为 6：级别 9 比 6 多压 3%–5%，但 CPU 时间翻 4–5 倍；字节跳动 AB 测试显示 QPS 下降 23%
- gzip_min_length 至少设为 1024：小于 1KB 的响应（如空 JSON、小图标内联 CSS）压缩后可能反而变大，还增加 TCP 包头开销
- 务必开启 gzip_vary on：让代理、CDN 和浏览器知道响应会随 Accept-Encoding 变化，否则容易缓存 gzip 版本却返回给不支持的客户端
- gzip_types 别漏掉 application/json 和 text/xml：API 类服务中 JSON 占比高，压缩率常达 70%–80%，收益明显
真实收益参考：典型文本资源压缩效果
以常见资源为例（基于 2026 年多轮压测数据）：
- HTML 文件：Gzip 级别 6 压缩率约 70%；Brotli 预压缩可达 85%+
- JS/CSS 文件：Gzip 压缩率约 60%–65%；Brotli 预压缩普遍再降 15%–18%
- JSON/XML：Gzip 压缩率 70%–80%，Brotli 提升幅度类似，但解压速度两者差异不大
- 图片、PDF、ZIP 等二进制文件：一律禁用压缩，Gzip 对它们基本无效，还白耗 CPU
