CSS 文件需通过 Brotli 压缩至原始体积的 30%–40%，关键验证是 Response Headers 中存在 Content-Encoding: br；Nginx 必须配置 brotli_static always、brotli_types 显式包含 text/css，并添加 Vary: Accept-Encoding 响应头，同时构建时预生成 .br 文件，CDN 与源站不可重复压缩。
直接开压缩，CSS 文件体积通常能压到原始的 30%–40%，但前提是链路每环都对得上——浏览器要发 Accept-Encoding: br 或 gzip，服务器得真返回 Content-Encoding: br 或 gzip，中间 CDN 不能缓存错版本。
怎么确认 CSS 真被 Brotli 压缩了
别信“我配了 brotli on”这种说法。打开 DevTools → Network → 刷新页面 → 找到任意 .css 请求 → 点开看 Response Headers。关键就一条：Content-Encoding: br 必须存在。没有？说明没走 Brotli。
常见断点：
- Nginx 配了
brotli on，但漏了brotli_static always，导致它无视已存在的style.css.br，仍返回未压缩的style.css - CDN（如 Cloudflare）支持 Brotli，但源站响应头没带
Vary: Accept-Encoding，结果缓存把br和gzip版本混成一个，Chrome 用户拿到的是 gzip 版本 -
brotli_types没显式写text/css，Nginx 默认不压缩 CSS
Nginx 启用 Brotli 的最小可靠配置
以下配置经实测可稳定投递 .br 文件，无需动态压缩开销：
立即学习“前端免费学习笔记（深入）”；
http {
brotli on;
brotli_comp_level 7;
brotli_types text/css application/javascript image/svg+xml;
brotli_static always;
add_header Vary "Accept-Encoding" always;
}
注意三点：
-
brotli_static always是关键：它会直接读取同名.br文件（比如请求main.css，就返回main.css.br），比on更确定、更省 CPU -
brotli_comp_level 7是性价比拐点；设成 11 对 CSS 提升不到 2%，但 CPU 占用翻倍，高并发下容易拖垮静态服务 -
add_header Vary "Accept-Encoding" always必须加，否则 CDN 缓存会污染，同一 URL 可能给 Chrome 返回 gzip，给 Safari 返回 br
Webpack 构建阶段必须预生成 .br 文件
运行时压缩（比如 compression-webpack-plugin 配 algorithm: 'brotliCompress'）只在 webpack-dev-server 生效，上线后完全不起作用。生产环境靠的是 Nginx 或 CDN 直接投递 .br 文件。
构建脚本建议这样写：
brotli -q 11 -f -o dist/main.css.br dist/main.css
参数含义：
-
-q 11：对 CSS 这类文本资源值得拉满，Brotli 在高等级下压缩率明显优于 gzip -
-f：强制覆盖已有 .br 文件，避免构建失败时残留旧版 - 确保 CI/CD 流程里这步执行成功，且
.br文件和原 CSS 一起上传到 CDN 或部署目录
gzip 和 brotli 共存时谁生效
如果客户端请求头同时带 Accept-Encoding: br,gzip（现代 Chrome/Firefox 默认行为），Nginx 会优先返回 Brotli —— 但前提是它真能找到 .br 文件并配置了 brotli_static always。否则 fallback 到 gzip。
兼容性提醒：
- Brotli 不支持 IE 和 Android Browser 4.4 以下；若业务还有这类用户，gzip 是兜底必需项
- 不要在源站和 CDN 上重复开启压缩（比如 Nginx 开了 brotli，CDN 又开 Gzip），会导致二次压缩失败或响应头冲突
- 图片（
.png、.jpg）、字体（.woff2）本身已是压缩格式，再套 Brotli 没效果，还可能损坏文件
最常被忽略的一点：Vary: Accept-Encoding 这个响应头不是可选项，是缓存正确性的命门。少了它，哪怕所有其他配置都对，Brotli 也只在你本地测试时有效，一上 CDN 就失效。
