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

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

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

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

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

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

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