Nginx开启Gzip压缩提升加载速度

Nginx的Gzip压缩绝非简单开启`gzip on`就能提速，而是一套需精细协同的性能优化策略：必须显式配置`gzip_types`以覆盖JSON、JS、SVG等关键文本类型，避开JPEG/MP4等本已压缩的格式；推荐`gzip_static on`与`gzip on`共存，实现预压缩文件零CPU响应与动态内容兜底压缩的高效分工；`gzip_comp_level 6`是生产环境压缩率与CPU开销的最佳平衡点，配合`gzip_min_length 1024`和`gzip_vary on`可避免小文件负优化与缓存错乱；更易被忽视的是预压缩文件需严格同步时间戳——稍有疏忽，再精妙的配置也会失效。

Gzip压缩不是“开了就快”，而是要区分动态内容实时压、静态资源提前压，否则 CPU 白烧、带宽没省、缓存还乱。

gzip on 之后为什么没生效？

常见错误是只写 gzip on，但没配 gzip_types —— Nginx 默认只压缩 text/html，其他如 application/json、application/javascript 全部被忽略。

• 必须显式列出类型，推荐组合：text/plain text/css application/json application/javascript text/xml application/xml image/svg+xml
• 别把 image/jpeg、video/mp4 加进去：这些本身已是高压缩格式，再压可能变大或白耗 CPU
• 检查 mime.types 文件是否被 include，否则 gzip_types 中的类型名会不识别

gzip_static on 和 gzip on 能一起用吗？

能，而且应该一起用：前者处理已存在的 .gz 文件（零 CPU），后者兜底处理动态内容或缺失预压缩文件的情况。

• gzip_static on 仅对请求路径匹配的文件生效（如请求 /app.js → 查找磁盘上 app.js.gz）
• 它不替代 gzip on：API 返回的 JSON、服务端渲染的 HTML 仍需动态压缩
• 注意顺序：Nginx 不会自动 fallback；若 gzip_static 找不到 .gz 文件，且 gzip on 已启用，才会走实时压缩

gzip_comp_level 设成 9 真的更好？

不。实测显示级别 6 到 9 的压缩率提升通常不足 5%，但 CPU 时间翻倍甚至更高。

• 级别 1：适合高并发 API 网关，响应快、CPU 轻
• 级别 6：生产环境通用选择，压缩率与开销平衡点
• 级别 9：只建议在构建时预压缩（如 Webpack 的 CompressionWebpackPlugin），别用在 Nginx 动态压缩
• 搭配 gzip_min_length 1024：小于 1KB 的文件压缩后可能反而更大（因 gzip header 占约 20 字节）

为什么加了 gzip_vary on 还被 CDN 缓存错？

因为 gzip_vary on 只加 Vary: Accept-Encoding 头，但部分老旧 CDN 或代理会忽略这个头，或缓存未区分编码版本。

• 确认客户端请求头含 Accept-Encoding: gzip（现代浏览器默认带）
• 检查响应头是否真有 Vary: Accept-Encoding（用 curl -I 验证）
• CDN 层需显式开启「基于 Vary 头缓存分片」功能，否则所有用户拿到同一份未压缩缓存
• 若用 gzip_static，Nginx 不会改写 Vary 头——它发的是原始 .gz 文件，Content-Encoding 由文件本身决定

最易被忽略的一点：静态资源预压缩（.gz 文件）必须和源文件时间戳一致，否则某些 Nginx 版本会拒绝使用它；用 touch -r app.js app.js.gz 同步时间可避坑。

本篇关于《Nginx开启Gzip压缩提升加载速度》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于文章的相关知识，请关注golang学习网公众号！