Brotli压缩大体积文本应以缩短整机响应时间（TTFB+传输+解压）为目标，推荐级别6–7平衡压缩率与CPU开销，避免11级实时压缩，并设置最小长度阈值（如20字节）、优先预压缩静态资源、精准匹配MIME类型。
用 Brotli 压缩大体积文本，核心目标不是“压得越小越好”，而是让整机响应时间（TTFB + 传输 + 解压）整体变短。它特别适合 HTML、JSON、JS、CSS 等结构清晰、重复模式多的文本，对纯随机二进制无效。
选对压缩级别，平衡 CPU 与体积
Brotli 的 0–11 级别中，级别过高（如 10–11）会显著拖慢 TTFB，尤其在高并发或低配服务器上；级别过低（0–3）则浪费压缩增益。对大体积文本推荐：
- 级别 6–7：最常用平衡点，压缩率提升明显，CPU 开销可控
- 级别 8：适用于带宽受限但 CPU 充足的场景（如 CDN 边缘节点预压缩）
- 避免 11 级实时压缩：实测 100KB JSON 在级别 11 下压缩耗时可能达 40ms+，抵消掉一半传输收益
配合最小长度阈值，跳过无效压缩
小文本（如
- brotli_min_length 20;（Nginx）或等效参数（如 Node.js 的 minRatio: 0.8）
- 若服务大量返回 1024，但需实测验证
- 不建议设为 0 —— 防止对单字节响应也触发编码逻辑
优先走预压缩，绕过运行时开销
对不变或低频更新的大文本（如文档页 HTML、配置 JSON、静态 API 响应），直接生成 .br 文件更高效：
- 用
brotli -q 7 --content-type "application/json" data.json -o data.json.br预生成 - Nginx 中启用
gzip_static on;类似机制（需模块支持或自定义逻辑） - 预压缩后，Nginx 只需做文件 I/O 和 header 注入，TTFB 接近裸响应水平
确保 MIME 类型精准匹配，不漏关键资源
Brotli 不会自动识别内容类型，只按 brotli_types 列表中的 MIME 才启用。常见疏漏：
- 漏掉 application/javascript → JS 文件未压缩，首屏阻塞严重
- 漏掉 image/svg+xml → 内联 SVG 体积大且未受益
- 误加 image/jpeg → 对已压缩图片再压，徒增 CPU 且无收益
- PHP 动态输出 text/html？确认 fastcgi_params 中设置了
Content-Type，否则 Nginx 可能无法匹配
不复杂但容易忽略
