Gzip与Brotli需从真实资源体积、传输耗时、终端解压表现三维度实测对比；典型文件（JS/HTML/JSON）在Brotli预压缩下体积减少15–25%，FCP/LCP缩短300–800ms，但动态Brotli CPU开销高30%，预压缩则零运行成本。
直接对比 Gzip 与 Brotli 的压缩效果，不能只看配置开关是否打开，而要落在真实资源体积、传输耗时和终端解压表现三个维度上。关键不是“谁更强”，而是“在你当前环境下，谁更省带宽且不拖慢服务”。
用同一份资源做实测对比
选几个典型文件（比如一个 240 KB 的打包 JS、一个含内联 CSS 的 HTML、一个 80 KB 的 JSON 接口响应），分别用以下方式处理：
- Gzip level 6 动态压缩（Nginx 默认推荐档位）
- Brotli q=5 预压缩（
brotli -q 5 -k file.js生成file.js.br） - Brotli q=5 动态压缩（启用
brotli on，不依赖预压缩）
然后 curl 测试响应头和 body 大小：
curl -H "Accept-Encoding: gzip" -I http://yoursite/js/app.js<br>curl -H "Accept-Encoding: br" -I http://yoursite/js/app.js
对比 Content-Length 和 Content-Encoding 字段，就能看到实际下发体积差异。例如：Gzip 后 72 KB，Brotli 预压缩后 55 KB —— 直接少传 17 KB。
重点关注首屏关键资源的压缩收益
HTML、内联 CSS/JS、SVG、JSON 这几类对首屏渲染影响最大。它们的压缩率提升最明显：
- HTML：Gzip 压缩率约 70%，Brotli 预压缩可达 85%+，首字节体积下降常超 25%
- JS/CSS：Gzip 约 60–65%，Brotli q=5～6 预压缩再降 15–18%
- JSON：Gzip 达 70–80%，Brotli 提升幅度类似，但解压更快，尤其利于 API 响应解析
体积减少直接转化为 FCP/LCP 缩短 300–800ms，这个差距在弱网或中低端手机上尤为可观。
别忽略解压端的实际开销
压缩率高 ≠ 用户体验好。还要看浏览器解压速度：
- Brotli 解码使用二阶上下文建模 + Web 静态字典（含
class、function、flex等高频词），现代浏览器解压耗时比 Gzip 低 10–25% - 尤其在 Android 中低端机或 iOS WebView 中，Brotli 解压更稳，不易卡顿
- Gzip 在极老设备（如 IE11 或某些 IoT 终端）上仍唯一可靠，但解压效率已落后
服务器 CPU 开销必须同步衡量
动态压缩时，CPU 成本是硬约束：
- Gzip level 6：CPU 占用增加约 15–20%，level 9 则翻 4–5 倍，QPS 可能下降 23%
- Brotli q=5 动态压缩：耗时比 Gzip level 6 高约 30%，但 q=1 就已超过 Gzip level 9 的压缩率
- Brotli 预压缩（
brotli_static on）：Nginx 几乎零运行时 CPU 开销，只读取 .br 文件，适合构建产物稳定的服务
所以真正有效的对比，是把“压缩后体积 × 实际传输耗时 × 终端解压耗时 × 服务器 CPU 占用”放在一起算综合成本，而不是单看百分比数字。
