Hostease 专区实测讨论：Nginx gzip 与 Brotli 压缩配置：服务器传输优化实战需要验证哪些指标

为什么压缩配置值得单独验证

很多站长把 Nginx 配好 gzip 就以为传输优化完成了，但压缩这件事远不止”开个开关”这么简单。gzip 和 Brotli 是两种不同的压缩算法，压缩率、CPU 开销、浏览器兼容性都不一样。如果只看”压缩开了没”，很容易漏掉真正影响用户体验的指标。这篇文章从实测角度拆解 Nginx gzip 与 Brotli 压缩配置，说明压缩率、CPU 开销、TTFB（首字节时间）等关键指标如何验证，帮助站长判断服务器传输优化是否真正生效。

gzip 与 Brotli 的核心差异

先厘清两个概念。gzip 是 1992 年出现的压缩算法，兼容性极广，几乎所有浏览器和代理都支持，Nginx 默认就带 gzip 模块。Brotli 是 Google 在 2015 年推出的算法，压缩率通常比 gzip 高 10% 到 20%，但代价是压缩时更吃 CPU，而且需要额外安装 ngx_brotli 模块。

在实测中，一份 120KB 的 JavaScript 文件，gzip 压缩后大约 38KB，Brotli 压缩后大约 31KB，差距接近 18%。对带宽（单位时间内能传输的数据量）有限、或面向移动端用户的站点来说，这个差距会直接反映在加载速度上。但要注意，Brotli 的压缩等级越高，服务器 CPU 占用越大，如果用的是低配 VPS（虚拟专用服务器），压缩等级开太高反而可能拖慢响应。

配置前先确认浏览器协商逻辑

Nginx 的压缩不是”压缩了就行”，而是通过 HTTP 请求头里的 Accept-Encoding 字段和浏览器协商。浏览器声明支持 Brotli，Nginx 就返回 Brotli 版本；不支持就回退到 gzip。这个协商逻辑如果配错，会出现”配置了 Brotli 但实际没生效”的情况。

验证协商是否生效，最直接的办法是用 curl 模拟不同浏览器的请求头。比如用 curl -H "Accept-Encoding: br" -I 你的域名，看响应头里是否返回 Content-Encoding: br；再用 curl -H "Accept-Encoding: gzip" -I 你的域名，确认返回 Content-Encoding: gzip。如果两种请求都返回了正确的编码，说明协商链路是通的。

一份可落地的配置参考

下面是一份在 Nginx 里同时启用 gzip 和 Brotli 的参考配置，放在 http 块里即可生效。gzip 部分用 Nginx 自带的模块，Brotli 部分需要先确认编译时带了 ngx_brotli 模块。

gzip on;
gzip_comp_level 5;
gzip_min_length 1024;
gzip_types text/plain text/css application/javascript application/json image/svg+xml;

brotli on;
brotli_comp_level 6;
brotli_min_length 1024;
brotli_types text/plain text/css application/javascript application/json image/svg+xml;

这里 gzip 压缩等级用 5，Brotli 用 6，是静态资源场景下压缩率和 CPU 开销比较平衡的取值。gzip_min_length 和 brotli_min_length 都设成 1024 字节，小于这个体积的文件压缩收益不大，直接原样返回反而更快。改完配置后记得先执行 nginx -t 检查语法，再 reload 让配置生效。

需要重点验证的四个指标

压缩配置是否真正生效，不能只看”有没有压缩”，要落到四个可量化的指标上。

第一个是压缩率。用压缩前后文件大小相减再除以原大小，得到百分比。这个指标直接决定传输优化能省多少流量。第二个是 CPU 开销。压缩是 CPU 密集操作，尤其 Brotli 高等级压缩，压一次大文件可能让单核占用冲到 80% 以上。第三个是 TTFB（首字节时间），即从发起请求到收到第一个字节的耗时。如果压缩配置导致每次请求都重新压缩，TTFB 会明显变差。第四个是缓存命中率。Nginx 的 gzip 和 Brotli 都支持静态预压缩，把压缩好的文件存成 .gz 或 .br 后缀，请求时直接返回，避免每次动态压缩。

实测方法与判断标准

在测试环境里，我通常用一套固定流程验证。先准备一个未压缩的静态资源，比如一个 200KB 的 CSS 文件，分别记录 gzip 和 Brotli 压缩后的体积，算出压缩率。然后用 ab 或 wrk 压测工具，在开启和关闭压缩两种状态下各跑 1000 个请求，对比 CPU 占用和 TTFB 的中位数。

判断标准要分场景。对静态资源占比高的站点，优先看压缩率和缓存命中率，Brotli 高压缩等级值得开。对动态接口多的站点，CPU 开销和 TTFB 更重要，压缩等级要调低，甚至对某些接口关闭压缩。如果发现 TTFB 在开启压缩后明显上升，优先检查是不是每次都在动态压缩，而不是命中预压缩缓存。关于带宽（单位时间内能传输的数据量）对整体速度的影响，可以参考香港服务器租用带宽选择攻略：共享带宽 VS 独享带宽详解，把压缩和带宽放在一起评估。

常见坑与排查思路

配置压缩最常见的坑有三个。第一个是只配了 gzip 没配 Brotli，导致现代浏览器拿不到更优的压缩。第二个是压缩等级开太高，低配 VPS 上 CPU 被打满，反而拖慢整体响应。第三个是没做静态预压缩，每次请求都动态压缩，高并发下 TTFB 恶化。

排查时先看响应头里的 Content-Encoding，确认实际返回的是 br 还是 gzip。再看 Nginx 的 access log 里有没有压缩相关的耗时异常。如果用的是共享主机或托管面板，很多面板默认只开 gzip，Brotli 需要确认底层是否装了 ngx_brotli 模块，没有的话只能靠 gzip 或换支持 Brotli 的环境。

总结与行动建议

总结一下，Nginx gzip 与 Brotli 压缩配置不是”开了就完事”，压缩率、CPU 开销、TTFB、缓存命中率这四个指标必须逐一验证，才能确认传输优化真正生效。对静态资源多的站点，建议优先上 Brotli 并配合静态预压缩；对动态接口多的站点，建议控制压缩等级，避免 CPU 成为瓶颈。

如果你需要一套可以直接套用的验证流程，建议先在你的测试环境里跑一遍上面的 curl 和压测命令，把四个指标的数据记录下来，再决定压缩等级和是否启用 Brotli。如果你正在用 Hostease 的海外 VPS 部署 WordPress，可以参考这篇外贸建站新手如何用 Hostease 海外 VPS 部署 WordPress，把压缩配置和建站流程一起落地。关于服务器速度的整体优化，也可以看看影响美国 VPS 服务器速度的核心因素与优化指南，把压缩放到更大的优化框架里判断。总结来说，先验证再调优，是避免压缩配置白忙一场的最稳妥做法。