Brotli 提升首屏速度需满足“压得准、传得对、解得快”：仅对 HTML/CSS/JS 等文本启用，禁用二进制文件；Nginx 需手动编译 ngx_brotli 模块并正确配置 brotli_types、brotli_comp_level 4–6、brotli_static on 等参数，配合预压缩与客户端协商验证。
直接开 Brotli 不等于首屏变快，关键在「压得准、传得对、解得快」——尤其对 HTML、CSS、JS 这类文本资源，Brotli 比 Gzip 多压出 17–25% 体积，但若配置不当，反而增加 CPU 开销、破坏 Range 请求、或被旧客户端降级失败。
确认 Nginx 已编译支持 ngx_brotli 模块
CentOS 7 默认源里的 Nginx 不带 Brotli，必须手动编译加载模块。光装 ngx_brotli 仓库还不行，还得确保子模块 brotli 被正确拉取：
- 执行
git submodule update --init后，检查ngx_brotli/deps/brotli/下是否有完整 C 源码（不是空目录） - 编译时加上
--add-module=/path/to/ngx_brotli，缺这步brotli on;会报unknown directive "brotli" - 验证是否生效：
nginx -V 2>&1 | grep -o brotli应输出brotli
只对文本资源启用 Brotli，坚决禁用二进制文件压缩
对 .mp4、.webp、.jpg 等已压缩二进制文件再压 Brotli，不仅无效，还会干扰 Range 请求，导致视频拖拽卡顿、图片加载失败。Nginx 日志里会出现大量 206 Partial Content 变成 200 OK 的异常。
- 明确限定类型：
brotli_types text/html text/css application/javascript application/json text/plain text/vtt; - 排除图片与视频：
brotli_disable "MSIE 6";不影响媒体，但可防极旧 UA 触发降级逻辑 - 不要写
brotli_types *;或漏掉text/html——首屏 HTML 压缩收益最大，却常被忽略
Brotli 参数调优：移动端弱网下选 level 4–6，非盲目拉满
压缩级别设为 11 虽然体积最小，但服务端 CPU 占用翻倍，且移动端解压延迟上升，反而拖慢 FCP。实测在东南亚/华南弱网环境下，brotli_comp_level 5 是性价比拐点：
-
brotli_comp_level 4–6：压缩率提升明显（比 level 1 多压 8–12%），CPU 开销可控 -
brotli_window 18（即 256KB 窗口）：适配多数 JS/CSS 文件长度，比默认 16 更优 -
brotli_min_length 20：小文件不压，避免 HTTP 头膨胀反超压缩收益 - 务必搭配
brotli_static on;：让 Nginx 优先读取预压缩的.br文件，省去运行时压缩开销
响应头与客户端协商必须干净，避免降级失效
Brotli 是否真正生效，取决于客户端请求头 Accept-Encoding: br 和服务端响应头 Content-Encoding: br 是否闭环。常见断点在 CDN、反向代理或浏览器兼容层：
- 确保 upstream（如 Node.js 或 PHP-FPM）没覆盖
Content-Encoding；Nginx 的brotli on只作用于它自己生成或透传的响应 - 禁用可能干扰的指令：
gzip off;必须显式写，否则和brotli on共存时部分请求仍走 Gzip - 用 curl 验证：
curl -H "Accept-Encoding: br" -I https://yoursite.com/app.js | grep encoding，应返回br而非gzip - 注意 Safari 对
br的支持从 11.1+ 才稳定，若需兼容更老版本，保留 Gzip fallback 并用gzip_vary on
最容易被忽略的是静态资源路径一致性：如果构建产物里 JS 文件名带 hash（如 main.a1b2c3.js），但 Nginx 的 brotli_static on 找不到对应的 main.a1b2c3.js.br，就会退化为实时压缩——此时 CPU 上升、延迟不降反增。预压缩脚本必须和构建流程对齐，且部署时同步上传 .br 文件。
