pb级流量站点静态资源压缩是带宽成本控制核心，需动态压缩与静态预压缩协同、精准类型筛选及缓存联动；实测可降传输体积30%～35%，带宽支出降约30%。
对 PB 级流量站点来说，静态资源压缩不是“锦上添花”，而是带宽成本控制的核心杠杆。真正起效的不是简单打开 gzip on，而是动态压缩与静态预压缩协同、类型精准筛选、缓存策略联动的一整套工程实践。实测中，合理配置可稳定降低传输体积 30%～35%，对应带宽支出下降约 30%。
优先启用 Gzip 动态压缩，但必须设好门槛
动态压缩是零改造、见效最快的起点，但盲目开启会徒增 CPU 压力，尤其在高并发下反而拖慢响应。
-
只压文本类资源：明确限定
gzip_types为text/plain text/css application/javascript application/json text/xml application/xml+rss，坚决排除.jpg、.png、.webp、.mp4等已压缩二进制格式，避免无效计算 -
设置最小长度阈值：
gzip_min_length 1024（1KB），防止小文件压缩开销反超收益 - 压缩级别选 6 而非 9：6 级在压缩率（平均 65%）和 CPU 占用（增加约 18%）之间取得实际平衡；9 级压缩率仅多出 3%～5%，但 CPU 耗时翻倍，不划算
-
务必开启
gzip_vary on：让 CDN 和浏览器知道响应内容依赖Accept-Encoding，避免缓存错乱
对高频 JS/CSS 文件做静态预压缩，卸载 Nginx CPU
动态压缩每次请求都重算，PB 级流量下 CPU 成为瓶颈。更优解是构建阶段生成 .gz 文件，Nginx 直接返回——即“静态压缩”。
- 前端构建时（如 Webpack）引入
compression-webpack-plugin，配置threshold: 1024和deleteOriginalAssets: false，输出同名.js.gz、.css.gz - Nginx 编译时需包含
--with-http_gzip_static_module模块（多数云厂商默认启用） - 配置中启用
gzip_static on，它会自动查找并返回xxx.js.gz（当客户端支持 gzip 且原文件存在） - 注意：
gzip_static开启后，gzip_types不再生效，无需重复配置类型
搭配 Brotli 进一步提效，尤其对文本资源
Gzip 是基础，Brotli 是增量收益。现代浏览器（Chrome、Firefox、Edge 70+）均支持 Brotli，压缩率比 Gzip 高 10%～15%，且解压更快。
- 安装
ngx_brotli模块（需重新编译或使用支持该模块的发行版） - 配置
brotli on、brotli_comp_level 6（兼顾速度与压缩率）、brotli_types同 Gzip 类型列表 - 启用
brotli_static on，配合构建工具生成.br文件，实现零运行时开销 - 通过
map指令按Accept-Encoding选择响应格式，优先返回 Brotli，降级到 Gzip，最后回退原始文件
压缩必须和缓存策略绑定，否则效果打折扣
压缩后的资源若未被有效缓存，用户每次访问仍要重新下载，带宽节省归零。
- 对已压缩的静态资源（.js.gz、.css.br），设置强缓存：
expires 1y或add_header Cache-Control "public, immutable, max-age=31536000" - 利用
ETag和Last-Modified支持协商缓存，避免 304 响应体重复传输 - 确保
Vary: Accept-Encoding存在于所有压缩响应头中，使 CDN 正确区分 gzip / br / plain 版本缓存 - 图片等非压缩资源，改用长缓存 + 版本化 URL（如
logo.a1b2c3.png），避免缓存失效问题
