边缘压缩省的是下行流量
压缩把文本类响应（HTML、JS、CSS、JSON）在边缘压缩后传输，明显减少下行带宽与加载时间。常见规则是命中指定文件类型且超过大小阈值才压缩：太小的文件压缩收益有限，图片、视频等已经是压缩格式的内容再压一遍几乎没有收益。开启前要确认源站没有做重复压缩。
基本信息
| 格式 | Gzip 兼容性最好；Brotli 压缩率更高，需要客户端支持 |
|---|---|
| 适用对象 | HTML、JS、CSS、JSON 等文本类内容 |
| 不适用 | JPG、PNG、MP4 等已压缩格式 |
| 触发阈值 | 小于阈值的小文件通常不压缩，收益有限 |
| 协商方式 | 按请求的 Accept-Encoding 协商，未声明则不压缩 |
典型使用场景
- 前端资源体积大，开启 Brotli 降低传输体积
- 接口返回大量 JSON，压缩后显著减少下行流量
- 源站与 CDN 重复压缩导致体积反而变大，做规则收敛
- 排查响应体积异常：确认是否命中压缩与是否被重复压缩
- 按客户端能力区分压缩策略，兼容老客户端
检查压缩是否生效
检查压缩是否生效
# 声明支持压缩，观察是否返回压缩后的内容
curl -sI -H 'Accept-Encoding: gzip, br' https://cdn.example.com/app.js | grep -i -E 'content-encoding|content-length|vary'
# 不声明压缩，对比响应体积
curl -sI https://cdn.example.com/app.js | grep -i content-length
# 注意：部分客户端不发送 Accept-Encoding，验证时不要漏掉这个前提格式与适用性
| 内容类型 | 是否压缩 | 说明 |
|---|---|---|
| JS / CSS | 是 | 体积大且为文本，收益明显 |
| HTML / JSON | 是 | 文本类内容，压缩率高 |
| JPG / PNG | 否 | 本身已是压缩格式 |
| MP4 / ZIP | 否 | 重复压缩无收益且浪费资源 |
CDN 压缩与缓存的关系按产品实现不同：部分产品按压缩状态分别缓存，混用源站压缩与边缘压缩前先核对文档并实测。
Brotli 需要客户端在请求头中声明支持，未声明时会回退到 Gzip 或不压缩，这类差异在排查体积异常时要特别注意。
压缩与缓存粒度
压缩后同一资源会出现压缩与非压缩两种形态。若产品按形态分别缓存，命中率会被摊薄；开启压缩前先确认缓存粒度的设计是否与预期一致。