可以禁用 Gzip 的一种情况

高性能网站建设指南》一书中用了整整一章来介绍压缩,在这本书的影响下,各个网站几乎都启用了 Gzip 压缩,以便让网站取得更好的性能。应该说,Gzip 压缩对大部分应用场景来说都是利大于弊的,不过凡事无绝对,最近我就遇到一个例外。

最近我们用 YSlow 做页面的性能分析时,发现有一个 js 不知什么原因没有被 Gzip 压缩。于是我找到负责服务器配置的相关同学咨询,这个过程中巧遇淘叔度,听了他的解释才知道这是他们有意为之。

我们知道,数据在网络上是以包的形式传输的,在 TCP/IP 协议中,大块的数据会被切分成小块,然后每一块会被加上一些头信息,最后,这些头信息加上原始数据的一个片断组成一个 IP 数据报,即一个数据包。如下图所示:

(图:TCP/IP数据包的封装,图片来自互联网)

对于以太网来说,一个最大传输单元(MTU)为 1500 字节,也即一个 IP 数据报最大不能超过 1500 字节,除去头信息和,最终的数据信息的长度一般最多可以比 1400 字节略多一些。

在 TCP/IP 协议中,数据传输的最小单位是包,也就是说,如果用户请求一个文件,无论这个文件有多小,服务器端至少需要发送一个数据包。这就带来一个有趣的问题:如果我们的文件内容非常小,加上头信息之后还不足一个包的长度,是否还有必要启用 Gzip 压缩呢?

比如我们之前发现的那个 js 文件,内容其实只有 944 字节,加上 HTTP 头信息,也还是不足 1400 字节。对这么小的文件来说,无论是否启用 Gzip 压缩,总是需要一个数据包来传送。也就是说,对这个文件而言,Gzip 压缩与否,网络传送的速度是一样的,同时,如果对它启用压缩,反而需要多耗费一些服务器压缩以及客户端解压的时间。

因此,对这样的小文件来说,不用 Gzip 可能页面性能更好,尽管这会让 YSlow 的评分看起来低一些。考虑到 HTTP 头的长度,禁用 Gzip 压缩的文件一般应该在 1024 字节以内。当然,从另一个角度来说,大部分情况下,这样的小 js 不应该存在,而是应该合并到某个更大的 js 中。不过,如果真的有某些特殊的无法合并的小文件,还是可以考虑一下这种禁用小文件 Gzip 的可能性的。

分类:编程标签:JavaScript

相关文章:

评论:

暂无评论

发表评论: