这两种方法对由LAMP服务器提供服务的html，css和javascript文件都具有什么优势。有更好的选择吗？
服务器使用Json向地图应用程序提供信息，因此大量的小文件。
Answers:
为什么对Apache提供的文本文件使用deflate而不是gzip？
简单的答案是不。
RFC 2616将deflate定义为：
deflate RFC 1950中定义的“ zlib”格式与RFC 1951中描述的“ deflate”压缩机制结合使用
zlib格式在RFC 1950中定义为：
0 1
+---+---+
|CMF|FLG| (more-->)
+---+---+
0 1 2 3
+---+---+---+---+
| DICTID | (more-->)
+---+---+---+---+
+=====================+---+---+---+---+
|...compressed data...| ADLER32 |
+=====================+---+---+---+---+
因此，有几个标头和一个ADLER32校验和
RFC 2616将gzip定义为：
gzip由文件压缩程序“ gzip”（GNU zip）产生的编码格式，如RFC 1952 [25]中所述。此格式是具有32位CRC的Lempel-Ziv编码（LZ77）。
RFC 1952将压缩数据定义为：
该格式目前使用DEFLATE压缩方法，但可以轻松扩展为使用其他压缩方法。
CRC-32 比ADLER32慢
与相同长度的循环冗余校验相比，它以可靠性换取速度（优先选择后者）。
所以...我们有2种压缩机制，它们使用相同的算法进行压缩，但使用不同的头和校验和算法。
现在，底层的TCP数据包已经相当可靠了，所以这里的问题不是GZIP使用的Adler 32 vs CRC-32。
事实证明，多年来许多浏览器都实施了不正确的放气算法。与其期望RFC 1950中没有zlib标头，他们只是期望压缩的有效载荷。同样，各种Web服务器也犯了相同的错误。
因此，多年来，浏览器开始实现模糊逻辑 deflate实现，他们尝试使用zlib标头和adler校验和，如果失败，则尝试使用有效负载。
这样的复杂逻辑的结果是它经常被破坏。Verve Studio有一个由用户提供的测试部分，用于显示情况有多严重。
例如：deflate在Safari 4.0中可用，但在Safari 5.1中已损坏，它在IE上也始终存在问题。
因此，最好的办法是完全避免放气，较小的速度提升（由于adler 32）不值得破坏有效载荷。
gzip和deflate的解压缩应该没有任何区别。Gzip压缩了几十个字节的标头，包括校验和。校验和是压缩速度较慢的原因。但是，当您预压缩大量文件时，您希望这些校验和作为文件系统中的完整性检查。另外，您可以利用命令行工具来获取文件的统计信息。对于我们的网站，我们正在预压缩大量静态数据（整个打开目录，13,000个游戏，数百万个关键字的自动完成等），并且Alexa的排名比所有网站都快95％。 传真搜索。但是，我们确实使用了本地专有的Web服务器。Apache / mod_deflate只是没有削减。将这些文件压缩到文件系统中后，您不仅会以最小的文件系统块大小来破坏文件，而且会在网络服务器可能不太在意的文件系统中管理文件时产生所有不必要的开销。您需要考虑的是磁盘总空间和访问/解压缩时间，其次要是能够对这些数据进行预压缩。占用空间很重要，因为即使磁盘空间很便宜，您也要尽可能多地放入缓存中。
在已安装Apache2并且已安装deflate模块的Ubuntu（默认情况下）上，您可以通过两个简单的步骤启用deflate gzip压缩：
a2enmod deflate
/etc/init.d/apache2 force-reload
而你走了！我发现通过我的adsl连接投放的网页加载速度更快。
编辑：根据@GertvandenBerg的评论，这将启用gzip压缩，而不是缩小。
如果我没记错的话