brotli对文本类资源（html/css/js/json/xml/svg）压缩率比gzip高15%–26%，解压速度相近；对已压缩二进制文件（图片/字体/pdf）无效甚至增体积，应从brotli_types中排除。
直接看压缩效果差异，关键不是“哪个算法更强”，而是不同文件类型在真实压测中表现出的体积缩减和解压开销。Brotli 并非全面碾压 Gzip，它对文本类资源优势明显，但对已压缩二进制文件几乎无用，甚至有害。
HTML、CSS、JS 这类纯文本资源
这是 Brotli 最能发挥价值的场景：压缩率稳定高出 17%–26%，尤其在中高 comp_level 下。例如：
- 一个 280KB 的 Vue 构建产物 app.js，Gzip level 6 压到约 92KB；Brotli level 6 预压缩后为 75KB 左右，再降 18%
- 含大量空格/注释的 HTML 模板，Gzip 压缩率约 70%，Brotli 可达 85%+，多省近 15KB
- 解压速度两者接近，现代浏览器处理 br 和 gzip 几乎无感知延迟
JSON、XML、SVG 等结构化文本
同样属于高收益类型，压缩率提升幅度与 HTML/JS 相当（15%–20%），且因内容重复模式强，Brotli 的二阶上下文建模优势更明显：
- API 返回的 JSON（如 120KB 用户数据），Gzip 压后约 28KB，Brotli 预压后约 22KB
- 内联 SVG 图标集合（纯文本路径指令），Brotli 比 Gzip 多压 20%+，而 Gzip 对这类内容本身已很高效
- 务必在 brotli_types 中显式包含 application/json 和 image/svg+xml，否则默认不压
图片、字体、PDF 等二进制文件
这类资源本身已是高压缩格式，再套一层 Brotli 或 Gzip 不仅无效，还可能增大体积、白耗 CPU：
- WebP/JPEG/PNG 文件开启 brotli_types image/png 后，Nginx 会尝试压缩，但结果常比原图更大
- WOFF2 字体已用 Brotli 内部算法压缩过，二次 Brotli 基本无收益，反而增加首字节延迟
- 正确做法是：从 brotli_types 和 gzip_types 中彻底移除 image/.*、font/.*、application/pdf 等类型
小响应（
压缩阈值和运行时开销在此类场景中起决定性作用：
- 一个 320 字节的空 JSON 响应（
{"code":0}），Gzip 或 Brotli 压缩后可能膨胀至 410 字节，还增加 TCP 包头负担 - 建议统一设 brotli_min_length 1024 和 gzip_min_length 1024，跳过所有小响应
- 模板实时渲染的 HTML、带用户 ID 的 JSON 接口等动态内容，不适合预压缩，应优先用 Brotli level 3–5 + static off，避免 TTFB 升高
