Nginx 开启 gzip 与 brotli 压缩

HTML、CSS、JS 这类文本资源压缩后体积能降六到八成，Nginx 十行配置就能拿到这份收益。常用的两种：gzip（GNU zip 压缩，所有浏览器都支持）与 brotli（新一代压缩算法，压缩率更高，现代浏览器支持）。 一、开启 gzip 编辑 nginx.conf 的 http 段： ``` gzip on; gzip_comp_level 5; gzip_min_length 1k; gzip_vary on; gzip_types text/css application/json application/javascript; ``` gzip_comp_level 取 1 到 9，级别越高压缩率越高、CPU 消耗越大。实践上 4 到 6 是甜点区，再往上体积只省一两个百分点，CPU 却明显变热。gzip_vary on 会补一个 Vary: Accept-Encoding 响应头，走 CDN 时必备，避免缓存层把未压缩版本发给支持的浏览器。text/html 默认就在压缩列表里，再写进 gzip_types 反而报 duplicate 警告。 二、brotli 怎么开 官方主线包没内置 brotli，两条路：发行版仓库选带 brotli 模块的 Nginx 包，或自编译时加上 ngx_brotli 模块。开启后同样三行：brotli on、brotli_comp_level 5、brotli_types 与上面 gzip_types 填同样的类型。brotli 与 gzip 可以同时开：浏览器请求头 Accept-Encoding 里带 br 的走 brotli，其余自动回落 gzip，互不冲突。改动不频繁的静态资源还可以开 brotli_static 预压缩，提前把文件压好存盘，请求来了直接发送，运行时 CPU 开销几乎为零。 三、别压这些类型 图片（jpg、png、webp）、视频、已经压缩过的文件（zip、gz、mp4）不要加进压缩列表。这类文件本身已是压缩格式，再压一遍 CPU 白烧，体积几乎不变，个别情况反而更大。很多站点开了压缩没效果，原因就是压错了对象。压缩率还和内容有关：文本重复度越高压得越狠，代码与 JSON 普遍好过普通文章，验证时按资源类型分别看数字，别拿一个页面的结果代表全站。 四、验证响应头 ``` curl -sI -H "Accept-Encoding: gzip" https://example.com/ | grep -i content-encoding ``` 输出 content-encoding: gzip 即生效。想对比压缩前后的大小，把 -I 换成 -s 再数一数字节数，差距一目了然。如果响应头里没有 content-encoding，按顺序查三处：gzip_types 是否漏了该类型、文件是否小于 gzip_min_length、中间的 CDN 是否剥掉了头。 改完 nginx -t && nginx -s reload。CPU 本来就紧张的机器，压缩级别宁可保守，别为省流量把处理器打满。