## 三个选项
文本资源的传输压缩有两条路：gzip 是老牌标配，浏览器全支持，Nginx 官方内置模块；Brotli 是 Google 推出的新算法，同级别压缩率更高，尤其在中高质量档位，文本类资源体积普遍比 gzip 再小一截，流量成本与首屏加载都受益。第三种是按内容分层：静态资源预压缩 + 动态响应实时压缩的组合，兼得质量与 CPU 开销。前提要说清：Brotli 加密传输场景依赖 HTTPS，明文 HTTP 下多数浏览器不启用它。
## 各自适用面
gzip 的优势是零门槛：ngx_http_gzip_module 官方内置，一行 gzip on 就能用，兼容性没有死角，任何老旧客户端与代理链路都吃得下。Brotli 的压缩率优势对纯文本最明显：HTML、CSS、JS、JSON、SVG 都是目标；它的动态压缩更吃 CPU，需要权衡质量档位。还有 brotli_static 的特殊玩法：把静态文件预先压成 .br 文件放同目录，Nginx 直接发预压文件，压缩成本一次性付出，线上零开销，配合内容哈希的静态资源最合适。
## 共存与配置思路
Brotli 需要模块支持：官方包不含，自编译或第三方仓库提供 ngx_brotli 模块，安装后配置：
nginx brotli on; brotli_comp_level 5; brotli_types text/css application/javascript application/json image/svg+xml;
与 gzip 共存的策略很简单：两个都开，压缩类型列表保持一致，模块间协商交给实现，老客户端自然落到 gzip，新客户端拿到 Brotli。动态响应压缩等级取中间值，CPU 与压缩率折中；静态资源尽量走预压缩文件。改完 nginx -t 与 reload，验证用 curl 带 Accept-Encoding 头看响应头里返回的 content-encoding 是不是 br。
## 选择建议
多数站点的务实路线：gzip 保底常开，模块条件具备就叠加 Brotli，静态资源上预压缩。大流量站点收益最直接：文本占比高、UV 大，同样的字节数下降折算成带宽就是真金白银。顺云的云服务器按带宽计费时，传输压缩直接影响成本与加载体验，值得花一小时配置。最后一句提醒：压缩只对文本有效，图片与视频本身已压缩，重复压缩白费 CPU 还可能变大，类型列表按需勾选就好。改完后用真实页面对比加载体积，压缩收益看得见，也顺手验证无兼容问题。