静态资源高效压缩需分场景选算法、配策略、用预压缩：文本用Brotli（level 6–7），排除图片/字体等已压缩格式；设min_length为1024，优先构建时预压缩并Nginx启用static模式；HTTPS下仅开Brotli、关闭Gzip。
想让静态资源既压得小、又压得快，关键不是一味调高压缩级别，而是分场景选算法、配策略、用预压缩。Nginx 本身不“计算”压缩率，它靠 gzip 或 brotli 模块执行压缩，而真正影响比率与速度的，是配置逻辑和资源交付方式。
按内容类型选压缩算法
文本类资源（HTML/CSS/JS/JSON/SVG）适合用 brotli，压缩率比 gzip 高 10–20%，解压也更快；图片、字体、PDF 等二进制文件本身已压缩，再压反而增大体积或白耗 CPU，应明确排除。
- 启用 brotli 时，brotli_types 只写需要的 MIME 类型：text/html text/css application/javascript application/json image/svg+xml
- 禁用对已压缩格式的处理：不包含 image/png、image/jpeg、font/woff2、application/pdf
- 若只用 gzip，gzip_types 同样精简，避免把 font/woff2 等加进去
设合理的压缩级别与阈值
压缩级别越高，CPU 耗时越长，但体积收益会快速衰减。比如从 level 6 升到 9，JS 文件可能只少 3KB，却多花 2 倍时间。
- 静态文件（构建产出）：brotli_comp_level 设为 6–7，gzip_comp_level 设为 4–6
- 动态响应（如 API JSON）：brotli_comp_level 3–5，避免首字节延迟升高
- 最小压缩长度：brotli_min_length 和 gzip_min_length 都设为 1024（1KB），跳过小响应（如空 JSON、404 提示）
优先用预压缩，绕过运行时开销
运行时压缩每次请求都算一遍，既占 CPU 又受 sendfile 限制（开启 sendfile 时 gzip 会自动降级）。真正高效的做法是构建阶段生成 .gz 或 .br 文件，Nginx 直接读取。
- 前端打包时用插件生成压缩文件，例如 Webpack 的 CompressionWebpackPlugin 输出 .gz
- Nginx 配置 gzip_static on 或 brotli_static always，启用静态查找模式
- 确保 .gz/.br 文件权限正确（Nginx worker 用户可读），否则静默回退到未压缩
HTTPS 下启用 Brotli 并关闭冗余 Gzip
Brotli 只在 HTTPS 请求中生效，且浏览器默认按 br > gzip 顺序协商。若同时启用两者，可能因协商逻辑混乱导致 fallback 不稳定。
- 在 http {} 块顶部写 brotli on，紧接着写 gzip off
- 不要用 gzip_disable、gzip_vary off 等干扰协商的指令
- 确认模块就位：
nginx -V 2>&1 | grep ngx_brotli有输出才有效
