性能提升的14条规则（四）

规则4——压缩组件
前端工程师做出的决定可以显著的减少在网络上传送HTTP请求和响应所花的时间。的确，用户的带宽速度、Internet服务商、对等交换点的距离和其它因素超出了开发团队的控制范围。然而，仍然有很多变数可以影响响应时间。规则1和规则3通过限制不必要的HTTP请求解决了响应时间的问题。如果没有HTTP请求——理想的情况下——也就没有了网络活动。规则2通过将HTTP响应拉近用户来减少响应时间。
而规则4则是通过减小HTTP响应的大小来减少响应时间。如果HTTP请求产生的响应包很小，传输时间就会减少，因为只需要将很小的包从服务器传递到客户端。这一效果对速度较慢的带宽尤其明显。
用于减小文件体积的文件压缩已经在Email应用和FTP站点中使用了10年，同样的技术也可以用于向浏览器发布压缩的Web页面。从HTTP1开始，Web客户端可以通过HTTP请求中的Accept-Encoding头来标识对压缩的支持。
如果Web服务器看到请求中有这个请求头，就会使用客户端列出来的方法中的一种来压缩响应。Web服务器通过响应中的Content-Encoding头来通知Web客户端。
gzip是目前最流行的好最有效的压缩方法。这是BNU项目开发的一种免费的格式（也就是说在专利权和其它限制方面没有任何阻碍）并被标准化为RFC1952。你可能见到的另一种压缩格式是deflate，但其效果略逊且不太流行。支持deflate的浏览器也支持gzip，但很多浏览器支持gzip却不支持deflate，因此gzip是最理想的压缩方法。
压缩什么
服务器基于文件类型选择压缩什么，但这通常受限于对其进行的设置。很多网站会压缩其HTML文档。压缩脚本和样式表也是非常值得的，但很多网站没有这样做（实际上，值得压缩的内容包括XML和JSON在内的任何文本响应，但这里只关注脚本和样式表，因为它们用得最普遍）。图片和PDF不应该压缩，因为它们本来就已经被压缩了。试图对它们进行压缩只会浪费CPU资源，还可能会增加文件大小。
压缩的成本有——服务器端会花费额外的CPU周期来完成压缩，客户端要对压缩文件进行解压。要检测收益是否大于开销，需要考虑响应的大小，连接的带宽客户端与服务器之间的Internet距离。这些信息通常难以得到，即便得到了，也有很多其它变数需要考虑。根据经验通常大于1KB或2KB的文件进行压缩。mod_gzip_minimum_file_size指令控制着希望压缩的文件的最小值，默认值是500B。