确认Brotli/Gzip是否生效需查Chrome DevTools Network中index.html的Response Headers是否有Content-Encoding: br或gzip，并对比Size与Content体积；若Size接近Content则未压缩，还需检查Vary: Accept-Encoding确保CDN缓存正确。
直接开 Brotli 不一定比 Gzip 更省带宽——关键看你怎么配，以及是否真生效。
怎么确认 gzip 或 brotli 实际起效了
别信构建后文件大小，那只是本地磁盘体积。真实压缩发生在 HTTP 响应传输时，靠的是 Content-Encoding 响应头。
- 打开 Chrome DevTools → Network → 刷新页面 → 找到
index.html请求 - 在 Response Headers 里找
Content-Encoding: br（Brotli）或Content-Encoding: gzip - 对比表格里的 “Size”（实际传输字节数）和 “Content”（解压后体积）：如果两者接近，说明根本没压缩
- 顺手检查有没有
Vary: Accept-Encoding—— 没它，CDN 可能缓存错版本
Nginx 中 brotli_comp_level 和 gzip_comp_level 怎么设才不翻车
Brotli 默认开 brotli on 后，不调参数反而可能比 Gzip 更慢、更大。
-
brotli_comp_level 5是 HTML/JS/CSS 的安全起点；4～6 是黄金区间；7+ 压缩耗时陡增，边缘节点容易卡住 -
gzip_comp_level 6是实测平衡点：压缩率约 65%，CPU 占用只增 15%～20% - 别盲目设
brotli_comp_level 11：它比gzip_comp_level 9还慢，但体积只小 1%～2% - 小文件不值得压：
gzip_min_length 1024和brotli_min_length 1024必须配，否则几十字节的响应也进压缩流水线
哪些资源该压、哪些死都不能压
压错类型=白耗 CPU + 增加延迟，不是所有 .js 或 .css 都适合实时压缩。
立即学习“前端免费学习笔记（深入）”；
- 必压类型：
text/css、application/javascript、application/json、image/svg+xml、text/plain - 禁压类型：
.jpg、.png、.mp4、.pdf、.webp—— 它们本身已是高压缩格式，再套一层只会拖慢响应 - PHP 动态输出要显式加：
application/x-httpd-php，否则location ~ \.php$返回的内容不会被 gzip/brotli 捕获
为什么开了 brotli 还得留着 gzip
不是兼容性问题，而是协商机制和部署现实的双重约束。
- 现代浏览器（Chrome 52+、Firefox 44+、Edge 15+、Safari 16.4+）都支持
br，但部分企业内网代理、老旧 CDN 节点会 strip 掉br头，导致请求直接失败 -
Accept-Encoding协商是标准行为：客户端发br,gzip，服务端优先回br；但如果只开 brotli，遇到 strip 行为就退化成明文传输 - 预生成
.br文件（如brotli --quality=9 --output=main.js.br main.js）并启用brotli_static on，可绕过运行时压缩开销，但必须同时保留gzip_static onfallback
最容易被忽略的点：Brotli 的压缩优势只在文本类资源上稳定成立，且高度依赖 brotli_comp_level 和 brotli_min_length 的组合；而 gzip 的“稳”恰恰来自它对小文件、动态内容、老旧链路的宽容度——不是技术落后，是设计取舍不同。
