brotli需针对性配置才能提升移动端https响应敏捷度：压缩级别html/css/js设5、json设4，窗口18（256kb），启用静态字典与预压缩，并协同回源与缓存。
直接启用 Brotli 并不能自动提升移动端 HTTPS 响应敏捷度，关键在于围绕弱网特性、设备能力与传输链路做针对性配置——压缩级别选 4–6、窗口设为 18（256KB）、启用静态字典与预压缩，并确保回源与缓存协同生效。
压缩级别必须按内容类型分级设定
移动端 CPU 和内存有限，高压缩级（如 q=11）会拖慢服务端压缩和客户端解压，反而增加首屏延迟。
- HTML/CSS/JS 主资源统一用 brotli_comp_level 5：压缩率提升约 19%，解压 100KB 文本稳定低于 8ms，iOS/Android 主流机型均可流畅处理
- API 返回的 JSON 建议设为 brotli_comp_level 4：小文件（
- 避开 q=0–1（增益仅比 gzip 高 5–8%）和 q=9–11（压缩耗时翻 3 倍，对加载速度几乎无贡献）
窗口大小要匹配弱网分片规律
Brotli 的 lgwin 决定查重范围，直接影响 HTML 模板类结构的压缩效果和内存开销。
- 设为 18（即 256KB）：覆盖 95% 以上跨帧重复，内存占用
- Nginx 配置写为 brotli_window 256k（推荐带单位后缀，兼容性更好）
- 不建议低于 lgwin=16（64KB）：含大量 class、data-* 属性的 HTML 压缩率会明显下降
必须启用静态字典 + 预压缩机制
运行时压缩在高并发下易成瓶颈，而预压缩 + 静态字典可实现零延迟响应。
- 确保 brotli_static on 或 brotli_static always：Nginx 优先查找同名 .br 文件，跳过实时压缩
- 构建阶段批量生成 .br 文件（如用
brotli -q 5 -k *.html），并确认 brotli_types 包含text/html、application/json、image/svg+xml等关键类型 - 静态字典默认启用（≥q2 即生效），无需额外开关；若页面高度同质（如电商商品页），可提取真实 HTML 样本生成 16KB 定制字典，再通过
brotli_static_dict /path/to/mobile_dict.bin加载
HTTPS 下必须打通 Brotli 回源链路
浏览器只在 HTTPS 下发送 Accept-Encoding: br，但边缘 Nginx 默认不向源站透传该头，容易造成“假开启”。
- 反向代理 location 中显式添加：proxy_set_header Accept-Encoding "br,gzip,deflate";（br 必须排最前）
- 源站 Nginx 启用 brotli on 且配置对应 brotli_types；静态资源建议同步开启 brotli_static on
- 缓存键中加入 $http_accept_encoding：
proxy_cache_key "$scheme$request_method$host$request_uri$http_accept_encoding";，防止 br/gzip 版本混用导致解压失败 - 验证方式：查边缘 access log 中
$upstream_http_content_encoding字段是否为br，或用 curl 直连源站对比响应头与 body 大小
