锱铢必较的 gzip 设置方法

在设置 web 服务器的时候,很多人会把 gzip 或是 brotil 打开,以期获得更快的传输速度——毕竟文件压缩了,那传输就变快了。

事实真的如此吗?

众所周知,gzip 或是 brotil 这样的压缩算法是需要消耗 CPU 的。如果文件没有经过预先处理,那多半是在访问时进行压缩的。在小流量的站点上这其实并非问题,但对于某些大流量站点这可能是问题。

网上有很多教程教你如何静态压缩文件,并使用 gzip_static 模块来提供服务——这很好,因此在这里我们不谈论这个,感兴趣的读者可以自己找来学习。

这里要来讨论的是 gzip 的另一个盲区问题——经过 gzip 压缩之后,文件真的变小了吗?

我们来观察一下 Google 首页加载的 logo 图片

浏览器请求 Google 首页 logo 的 DevTools 截图。

从 Google 服务器的响应上来看,可以很清楚地看到,服务器并没有使用 gzip 或是 brotil 对这张图片进行压缩。

我们将这张图片下载回来,然后在本地使用 gzip 命令对其进行压缩:

wget https://www.google.com/images/branding/googlelogo/1x/googlelogo_color_272x92dp.png
gzip -k googlelogo_color_272x92dp.png
ls -l googlelogo_color_272x92dp.png*

输出结果如下:

-rw-r--r-- 1 oott123 oott123 5969 Oct 23  2019 googlelogo_color_272x92dp.png
-rw-r--r-- 1 oott123 oott123 6022 Oct 23  2019 googlelogo_color_272x92dp.png.gz

可以看到,gzip 之后的文件大小为 6022 字节,甚至比原始的 5969 字节还要更大一些。

聪明的你肯定知道为什么:PNG 格式本身就使用和 gzip 如出一辙的算法 DEFLATE 压缩过了,再用 gzip 压缩一遍反而是徒增烦恼,即使文件没有变大,也不会变小太多。

事实上许多网络上传输的文件都是有内部有压缩实现的,例如 png, jpg, zip, rar, 7z, docx 。在 web 服务器上对这些文件进行压缩,起不到什么压缩的效果,反而浪费了压缩解压的时间和功。因此,合理地配置需要压缩的文件类型才是正确的选择,一股脑全部打开只是浪费——当然了,也浪费不了多少,几乎不会产生什么显著影响。

当然,总会有些人觉得压缩两次不舒服,比如我。

这次我使用的是 traefik 作为我的流量入口,因此找到了它的 gzip middleware 配置

可以看到,traefik 支持使用 excludedContentTypes 配置 gzip 排除名单。懒人如我,自然开始上网搜寻现成的——然而没找到,只找到一份需要用 gzip 压缩的 mime 名单。事实上我也觉得在 gzip 这件事情上用白名单比较好,因为需要压缩(且压缩率大)的那些文件其实很明显:html, css, javascript,有时候还有 json。可是 traefik 没有提供设置白名单的方法,所以只能自己动手整理一份黑名单了。

于是我打开 nginx 内置的 mime 列表 ,挑出来一些常见的、我知道带压缩的格式,放进了排除名单里。

这份名单提供在这里,供有需要的人参考:

image/jpeg
image/png
image/webp
audio/webm
audio/mpeg
video/webm
video/mp4
video/mpeg
video/mp2t
application/zip
application/x-zip-compressed
application/x-rar-compressed
application/x-7z-compressed
application/java-archive
application/vnd.openxmlformats-officedocument.presentationml.presentation
application/vnd.openxmlformats-officedocument.wordprocessingml.document
application/vnd.openxmlformats-officedocument.spreadsheetml.sheet
application/x-bzip
application/x-bzip2
font/woff
font/woff2

其中还藏着一个冷知识:TTF 几乎没有压缩,而 woff / woff2 分别采用了 zlib 和 brotil 进行压缩,因而体积更小,更适合在 web 上传播。

总而言之,如果你的网站流量并不是很大,而且也不怎么在意这点微不可察的加载时间差距,那么我建议你还是别折腾,直接 gzip on 就完事了。如果你真的是锱铢必较,或者有所谓的强迫症,那这篇文章还是有参考价值的。

评论

依云

如果你的 HTTP 服务器不支持媒体文件不压缩的话,我建议还是完全不要压缩好了。压缩媒体文件太浪费 CPU 了,从磁盘上直接读静态文件会有很大的性能优势的。

发表评论

发表评论代表你授权本网站存储并在必要情况下使用你输入的邮箱地址、连接本站服务器使用的 IP 地址和用户代理字符串 (User Agent) 用于发送评论回复邮件,以及将上述信息分享给 Libravatar Akismet,用于显示头像和反垃圾。