如何开启gzip压缩实现HTTP层全站内容带宽节省实战-Nginx-PHP中文网

开启gzip压缩需精准配置：仅压缩html/js/css/json等文本资源（减幅65%～75%），禁压图片/字体/视频；确保客户端发送accept-encoding头，服务端按类型启用动态压缩，并设min-length阈值，最后验证content-encoding响应头及vary字段。

如何开启gzip压缩实现http层全站内容带宽节省实战

开启 gzip 压缩实现 HTTP 层全站内容带宽节省，关键不是“打开开关”，而是让服务器对合适的资源在正确的时机执行适度的压缩，同时避开常见失效点。实测中，HTML/JS/CSS/JSON 类文本响应体积常减少 65%～75%，但图片、字体、视频等再压反而增大体积。

服务器不会主动压缩，必须依赖浏览器明确声明能力：

现代浏览器默认发送 Accept-Encoding: gzip, deflate 请求头；若为 API 客户端或旧 SDK，需手动添加该头，否则 Nginx/IIS/Go 中间件直接跳过压缩
CDN 或负载均衡器可能剥离该头（尤其老旧设备），建议用 curl -H "Accept-Encoding: gzip" 或浏览器 DevTools 的 Network 面板验证请求是否含此字段
若请求无该头，所有服务端配置均无效——这是压缩静默失败的首要原因

静态资源可预压缩，但 PHP/Node.js/Go 等生成的 HTML、JSON、API 响应必须靠服务端实时压缩：

Nginx（推荐首选）：在 http{} 块中统一配置，避免在每个 location 重复写。必须包含 application/x-httpd-php（PHP）、application/json（API）等动态 MIME 类型
IIS：默认只开静态压缩，需进管理器 → 服务器节点 → “压缩” → 勾选“动态内容压缩”，并在 applicationhost.config 的 <dynamictypes></dynamictypes> 中显式添加 text/html、application/json 等类型
Go/Python/Node.js 应用层：用中间件（如 ntfy 的 gzip_handler.go 或 Flask-Compress）拦截响应，检查 Accept-Encoding 后调用 gzip.Writer，注意复用 writer 实例（如连接池）避免高频分配

乱压等于浪费 CPU 且可能损害传输效率：

只压文本类 MIME：text/html、text/css、application/javascript、application/json、image/svg+xml —— 这些压缩率高（通常 60%+）
绝对禁压二进制资源：.jpg、.png、.webp、.woff2、.mp4、.pdf —— 它们本身已是高压缩格式，再 gzip 可能增大约 10%～30% 体积
设最小长度门槛：Nginx 用 gzip_min_length 1024，IIS 设 minFileSizeForComp，跳过小于 1KB 的响应（如小 JSON、空 HTML），避免压缩开销反超收益

上线后务必实测，不能仅看配置是否写上：

用 Chrome DevTools → Network → 点击任一 HTML/JS/CSS 请求 → 查响应头是否有 Content-Encoding: gzip，并对比 Size（解压后）与 Transfer Size（压缩后）是否明显缩小
检查是否出现 Vary: * 或缺失 Vary: Accept-Encoding —— 若后端脚本手动写了 Vary: * 或 identity，Nginx/IIS 将拒绝压缩
确认未双重压缩：构建时已生成 .js.gz 文件，又在运行时被 Nginx 再次 gzip，会导致浏览器解压失败或乱码