brotli需精细化调优而非简单启用：html/css/js用压缩级5，json用4级，窗口设18（256kb），启用静态字典与预压缩，并协同http/2和强缓存策略。
直接调优 Brotli 参数比单纯开启压缩更能提升移动端弱网首屏速度。关键不是压得最狠，而是让资源在窄带宽、高延迟、低解压能力的手机上“又小又快解”。
压缩级别要分内容精细设定
统一用最高级（11）反而拖慢构建、增加内存压力，也不利于弱网下快速解压。应按资源类型差异化配置：
- HTML / CSS / JS：用 5 级——兼顾体积缩减（实测再降 15–20%）与解压响应，避免高阶模型带来的 CPU 消耗
- JSON / API 响应体：用 4 级——结构化数据重复模式少，过高压缩收益低，4 级已足够稳定提效
- 预压缩静态资源（如构建产物）：可用 6–8 级——离线完成，不挤占用户请求时的服务器资源
窗口大小和静态字典必须启用
Brotli 的核心优势来自 120KB 静态字典 + 可调滑动窗口。移动端弱网下，这两项直接影响首屏文本资源的压缩密度和解压效率：
- 窗口大小设为 18（对应 256KB）：比默认值更适配移动端常见资源块尺寸，在内存占用与长距离匹配间取得平衡
- 务必启用 静态字典（static dictionary）：它内置了 HTML/CSS/JS 常见关键词（如
class、function、display: flex），对文本类资源压缩率提升贡献超 30% - 若使用 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（Time to First Byte）极其敏感，运行时实时压缩会引入不可控延迟：
- Vite / Webpack 构建时用
compression-webpack-plugin或vite-plugin-compression输出.br文件，Nginx 启用ngx_http_brotli_static_module直接返回预压缩版本 - 禁用运行时动态压缩（如 Express 中的
res.send()插件式压缩），避免 Node.js 层 CPU 成为瓶颈 - 验证是否生效：用 Chrome DevTools → Network → 查看响应头含
content-encoding: br，且文件体积比 gzip 版小 15% 以上
