如何通过gzip和brotli压缩算法大幅降低静态资源带宽成本？

本文共计649个文字，预计阅读时间需要3分钟。

直接启用 gzip 和 brotli 压缩，可将文本类静态资源体积压缩至原大小的 30%-40%，带宽消耗平均降低 60%-80%。关键不在于开不开，而在于如何配置和给谁用。

明确支持范围：只压该压的文件

图片（.jpg、.png）、视频（.mp4、.avi）、音频（.mp3）等本身已是高压缩格式，再套 gzip 或 brotli 不仅无效，还徒增 CPU 开销。应严格限定压缩类型：

• 必压类型：text/plain、text/css、application/javascript、application/json、text/xml、application/xml、image/svg+xml
• 可选类型：image/tiff（较少见但未压缩）、application/rss+xml
• 禁压类型：所有二进制媒体文件（.jpg/.jpeg/.png/.gif/.mp4/.webm/.pdf 等）

合理设置压缩阈值与级别

小文件不值得压，高压缩级未必更划算：

• gzip_min_length 设为 1024（1KB）：避免对几十字节的空响应头或极短 JS 片段做无谓压缩
• gzip_comp_level 推荐 6 级：实测压缩率约 65%，CPU 占用增幅控制在 15%-20%
• brotli_comp_level 推荐 7–9 级：Brotli 在 7 级时已超越 gzip 9 级的压缩率，且压缩耗时明显低于 11 级

优先使用 brotli，fallback 到 gzip

现代浏览器（Chrome 52+、Firefox 44+、Edge 15+、Safari 16.4+）均支持 brotli，且当 Accept-Encoding 同时含 br 和 gzip 时，服务端默认优先返回 brotli 压缩内容。配置逻辑应是：

• 同时开启 brotli 和 gzip 模块
• 不手动判断 UA，依赖标准 Accept-Encoding 协商机制
• 确保 .br 静态文件预生成（如用 brotli --quality=9 --output=main.js.br main.js），并启用 brotli_static on 提升性能

注意兼容性与副作用

压缩不是万能开关，几个易被忽略但影响上线的关键点：

• 源站若已返回 Content-Encoding: gzip 或 br，CDN/网关层不会再重复压缩——需统一管控压缩入口
• 压缩会改变响应体二进制内容，导致 MD5/SHA256 校验失败，如有前端校验逻辑，必须关闭压缩
• 页面优化类功能（如 HTML 自动去空格、CSS 内联）与压缩互斥，二者同时开启时，压缩会覆盖优化效果