brotli压缩需分场景设参数：html/css/js用level 5，兼顾压缩率与解压性能；json用level 4，适配小文件低延迟需求。
移动端静态页面加载慢，核心卡在三件事上：资源体积大、传输效率低、浏览器反复请求。Nginx 不是只配个 gzip on 就完事，得围绕弱网、小屏、低算力这些真实场景做针对性配置。
用 Brotli 压缩文本资源，但别乱设级别
Brotli 对 HTML、CSS、JS 的压缩效果比 Gzip 高 15–20%，但必须选对参数：
- HTML/CSS/JS 统一设
brotli_comp_level 5：压缩率提升明显，解压快，iOS 和 Android 主流机型处理 100KB 文本稳定在 8ms 内 - API 返回的 JSON 设
brotli_comp_level 4：小文件（ - 绝对避开 0–1 级（几乎没增益）和 9–11 级（压缩耗时翻 3 倍，移动端解压反而卡顿）
窗口大小调到 256KB，匹配弱网分片规律
Brotli 的 brotli_window 影响查重范围，不是越大越好：
- 设为
brotli_window 256k（即 lgwin=18）：覆盖 95% 以上跨帧重复结构（比如模板中反复出现的<div class="item">），内存开销可控（ <li>不建议低于 64KB（lgwin=16）：含大量模板结构的 HTML 压缩率会明显下滑</li> <h3>预压缩 + 静态字典，让首字节更快出来</h3> <p>运行时压缩会拖慢首字节时间（TTFB），尤其在弱网下更敏感：</p> <ul> <li>构建阶段就用 <code>brotliCLI 工具批量生成.br文件，比如brotli -q 5 -Z main.css -o main.css.br - Nginx 配置里打开
brotli_static on，它会自动找同名 .br 文件，零压缩延迟 - 确保
brotli_types包含text/html、text/css、application/json、image/svg+xml—— 少一个，对应资源就白压了
配合 HTTP/2 和精准缓存，把并行优势真正落地
Brotli 单独启用效果有限，必须和链路其他环节协同：
- 开启 HTTP/2：让多个资源复用一个 TCP 连接，绕过 HTTP/1.1 的 6 个并发限制
- 对带哈希的 JS/CSS/woff2/webp 资源，加
Cache-Control: public, max-age=31536000, immutable—— 浏览器永不发 304，彻底释放连接 - 小图标、字体等资源启用
sendfile on+tcp_nopush on+tcp_nodelay on：内核直传、填满包、不攒包，降低毫秒级延迟
