大型JS包必须用Brotli而非仅Gzip，因其对精简后文本资源压缩率高15–25%，尤其在100KB+ bundle上更显著；Brotli内置Web静态字典针对性强，而Gzip仅依赖局部重复匹配。
为什么大型 JS 包必须用 Brotli 而不是只靠 Gzip
因为 Brotli 对文本类资源（尤其是经过 Tree Shaking 和 minify 后的生产级 JS）压缩率比 Gzip 高 15–25%，且这种优势在 100KB+ 的 bundle 上更明显。Gzip 在压缩级别 9 时仍不如 Brotli 级别 4，而后者 CPU 开销更低、更适合服务端实时压缩。
关键点在于：Brotli 内置的静态字典（含 document、function、export 等上万 Web 常见 token）对 JS 语法结构有强针对性；而 Gzip 仅依赖局部重复字符串匹配，对已高度精简的代码收益有限。
- 不要对
.png、.jpg、.woff2等本身已压缩格式启用 Brotli，反而增大体积 - 确保构建产物带内容哈希（如
main.a1b2c3d4.js），否则immutable缓存策略失效 - 浏览器仅在 HTTPS 下发送
Accept-Encoding: br，HTTP 环境下会退化为 Gzip 或无压缩
Nginx 中正确配置 Brotli + Gzip 双压缩回退
不能只开 brotli on 就完事——老旧浏览器（如 IE、旧版 Safari）不支持 br 编码，必须让它们自动降级到 Gzip。Nginx 本身不支持运行时协商两种算法，需靠顺序和 gzip_vary on 配合实现。
在 nginx.conf 的 http 块中添加：
gzip on; gzip_vary on; gzip_types text/plain text/css application/json application/javascript; gzip_comp_level 4; gzip_min_length 1024; <p>brotli on; brotli_comp_level 6; brotli_min_length 1024; brotli_types text/plain text/css application/json application/javascript; brotli_static always;</p>
brotli_static always 表示优先查找预生成的 .js.br 文件；若不存在，再走实时压缩。而 gzip_vary on 会让 Nginx 对同一 URL 返回带 Vary: Accept-Encoding 的响应头，强制 CDN 和浏览器按编码类型缓存不同副本。
前端构建阶段预生成 .br 文件而非运行时压缩
运行时压缩（尤其 brotli_comp_level 6+）会显著抬高 TTFB，对首屏 JS 尤其不利。更稳的做法是在构建后立即生成 .br 和 .gz 双版本文件，由服务器按需返回。
以 Webpack 项目为例，在 package.json 的 build 脚本末尾追加：
"build": "webpack --mode production && brotli -f -q 6 dist/main.js && gzip -k -6 dist/main.js"
确保 dist/main.js.br 和 dist/main.js.gz 与原文件同目录。此时 Nginx 的 brotli_static always 和 gzip_static on 才真正生效——零 CPU 开销，100% 复用构建时压缩结果。
- 别用
brotli -q 11：压缩耗时翻倍，但体积只比-q 6小不到 2% - 检查输出文件权限：Nginx worker 进程需有读取
.br文件的权限，否则静默 fallback 到未压缩版本 - Webpack 5+ 用户可直接用
compression-webpack-plugin插件，但注意它默认不生成.br，需显式配置algorithm: 'brotliCompress'
Cache-Control 与 Service Worker 协同控制 JS 加载生命周期
光压得小不够，还得让浏览器“信得过”这个 JS 文件长期不更新。大型 bundle 必须拆离频繁变动的逻辑（如用户态数据），并用 immutable + 内容哈希锁定缓存行为。
在 Nginx server 块中对 JS 设置：
location ~* \.js$ {
add_header Cache-Control "public, max-age=31536000, immutable";
}
这表示：只要 URL 不变（即哈希不变），浏览器永远不用发条件请求（If-None-Match）。但上线新版本后，HTML 中引用的 JS 路径变了，浏览器自然拉新包。
如果用了 Service Worker，别让它盲目缓存所有 JS——应只缓存 vendor 类稳定模块（如 react、lodash），主业务逻辑 JS 交给 HTTP 缓存控制更稳妥。否则 SW 更新逻辑出错会导致白屏或功能错乱，排查成本远高于 HTTP 层配置失误。
容易被忽略的是：CDN 边缘节点是否识别 immutable？Cloudflare 默认支持，但部分自建 CDN 或老旧代理可能忽略该指令，建议搭配 ETag 或 Last-Modified 作兜底。
