brotli压缩质量等级需按资源类型分层设置：动态内容用3–4级，构建产物用6级，静态资源用8–11级（配合预压缩）；避开brotli_static on误用于动态场景和小响应硬压陷阱，并协同lgwin=18与精准mime类型控制。
设置 Brotli 压缩质量等级，核心不是选“最高”，而是按资源类型分层控制，在压缩率、CPU 开销和首字节延迟（TTFB）之间取得实际可落地的平衡。
按资源类型设不同 comp_level
Brotli 的 0–11 级别对性能影响非线性，盲目统一设 11 会显著拖慢高并发响应：
-
动态内容（API JSON、PHP/Node 渲染的 HTML）：用
brotli_comp_level 3–4。实测比 gzip level 9 压缩率仍高 15%+，但单次编码耗时降低 50% 以上，P95 延迟更稳 -
前端构建产物（app.js、vendor.css、index.html）：设
6。这是静态资源的黄金档位，压缩率约 65%，CPU 占用可控，适合多数 CDN 回源或边缘节点 -
长期不变的公共资源（reset.css、logo.svg、字体文件）：可配
8–11，但必须配合brotli_static on和预生成.br文件——此时 CPU 不参与运行时压缩，高压缩纯属“一次投入，长期受益”
避开两个典型陷阱
很多配置失效，就卡在这两点：
-
别在动态压缩场景下开
brotli_static on：它会直接跳过实时编码，只查 .br 文件。若没提前生成或权限不对，Nginx 静默忽略，既不报错也不 fallback -
别对小响应硬压：设
brotli_min_length 1024（1KB）是底线。小于这个值的响应（如空 JSON、304、短错误提示），压缩后反而更大，还白耗 CPU
配合窗口大小与 MIME 类型精准控制
仅调 comp_level 不够，需协同参数才能真正释放 Brotli 优势：
-
窗口大小建议
lgwin 18（即 256KB）：覆盖常见 HTTP/2 帧和 TCP 分片，提升跨段重复文本识别率；低于 16（64KB）会明显损失 HTML/CSS 压缩收益 -
brotli_types必须严格匹配真实资源 MIME：比如用application/javascript，别写成已弃用的text/javascript；排除image/jpeg、font/woff2等本就不该压的二进制类型
验证是否生效且平衡得当
上线后不能只看配置有没有语法错误，要盯三个关键信号：
- 响应头含
Content-Encoding: br，且Content-Length比原始文件小 20% 以上 - 服务器 CPU 使用率无异常尖峰，尤其在流量突增时段
- Chrome DevTools → Network → 查看某 JS 文件的 TTFB 和传输时间，对比开启前后变化；若 TTFB 明显上升，说明
comp_level过高或未关brotli_static
