启用brotli需分层调优：按资源类型设压缩级（html/css/js用-q5，json用-q4，构建产物预压缩至-q6–8），启用静态字典与lgwin=18窗口，嵌入http/2和强缓存链路，并强制构建预压缩、禁用运行时压缩。
直接启用 Brotli 并不能自动带来 20% 的压缩率提升和首屏加速效果。真正起效的是分层调优：按资源类型设定压缩级别、启用静态字典与预压缩、精准控制 MIME 类型范围，并嵌入 HTTP/2 和强缓存链路中。
压缩级别必须分内容精细设置
Brotli 的 0–11 级不是“越高越好”，尤其在移动端弱网场景下，高压缩级会拖慢构建、增加解压延迟，反而损害首屏体验：
- HTML / CSS / JS 文件用 -q 5：实测体积再降 15–20%，兼顾解压响应速度与 CPU 占用
- JSON / API 响应用 -q 4：结构化数据重复模式少，4 级已足够稳定提效，避免高阶模型引入额外开销
- 构建产物（如 dist 中的 .js/.css）可离线预压缩至 -q 6–8：不挤占用户请求时的服务端资源
窗口大小与静态字典是关键增益点
Brotli 的核心优势来自内置的 120KB 静态字典 + 可调滑动窗口，这两项对 HTML/CSS/JS 类文本资源压缩率贡献超 30%：
- 窗口设为 lgwin=18（256KB）：适配移动端常见资源块尺寸，在内存占用与长距离匹配间取得平衡
- 务必启用静态字典：它预置了 class、function、display: flex 等 Web 常见关键词，大幅提升文本密度
- Nginx 需确认编译时启用了 --with-http_brotli_module 并加载字典支持
服务端策略要协同 HTTP/2 与缓存机制
Brotli 单独生效有限，必须嵌入完整传输链路：
- 强制走 HTTP/2：多路复用缓解弱网下多个小资源排队延迟，Brotli 压缩后的小文件更适配此特性
- 静态资源设强缓存：Cache-Control: public, max-age=31536000，配合 ETag 或 Last-Modified 实现协商缓存
- Nginx 中明确声明 br 编码优先级高于 gzip，并仅对 text/html、application/javascript、text/css、application/json 等文本 MIME 类型启用
构建阶段必须预压缩，禁用运行时压缩
移动端首屏对 TTFB 极其敏感，运行时实时压缩会引入不可控延迟：
- Vite / Webpack 构建时用 vite-plugin-compression 或 compression-webpack-plugin 输出 .br 文件
- Nginx 启用 ngx_http_brotli_static_module，直接返回预压缩版本
- 禁用 Express 等框架中的 res.send() 插件式动态压缩，避免 Node.js 层 CPU 成为瓶颈
