我了解 GZIP 是 LZ77 和 Huffman 编码的组合，可以配置 1-9 之间的级别，其中 1 表示最快的压缩（较少压缩），9 表示最慢的压缩方法（最佳压缩）。
我的问题是，级别的选择仅会影响压缩过程，还是根据用于压缩的级别在解压过程中也会产生额外的费用？
我问是因为如果客户端支持，通常许多 Web 服务器会即时 GZIP 响应，例如Accept-Encoding: gzip。我很欣赏在运行中执行此操作时，对于一般情况而言，诸如 6 之类的级别可能是不错的选择，因为它在速度和压缩之间取得了良好的平衡。
但是，如果我有一堆静态资产，我可以提前 GZIP 一次 - 并且再也不需要这样做 - 使用最高但最慢的压缩级别会有什么缺点吗？ IE。如果使用较低的压缩级别，现在是否会有额外的客户端开销。
【问题讨论】：
标签： compression gzip
很好的问题，但曝光不足。您的直觉是可靠的 - 对于某些压缩算法，选择最大压缩级别可能需要解压缩器在解压缩时进行更多工作。
幸运的是，gzip 并非如此——客户端/浏览器无需额外的开销来解压缩压缩程度更高的 gzip 文件（例如，选择 9 而非 6 进行压缩，假设大多数服务器使用标准 zlib 代码库）。对此最好的衡量标准是解压缩率，目前以 MB/秒为单位，同时还监控内存和 CPU 等开销。简单地按解压缩时间来衡量是不好的，因为在较高的压缩设置下文件会更小，而且如果我们只使用秒表，我们就无法控制该因素。
一旦超过 6 级压缩内容，gzip 解压缩在解压缩时间和内存使用方面都会迅速变得渐近。 Marcus Müller 链接的测试结果中 7、8 和 9 级的解压时间平坦线，尽管这是以整秒为单位给出的粗粒度数据。
您还会在这些结果中注意到，对于所有级别的压缩，解压缩的内存要求都是 0.1 MiB。这几乎令人难以置信，这只是我们很少见到的软件的卓越程度。 Mark Adler 和他的同事们应该为他们所取得的成就获得巨大的支持。 gzip 是一种非常好的格式。
内存使用解决了您关于开销的问题。真的没有。 9级在浏览器解压速度方面并没有什么收获，但也不会损失什么。
现在，查看these test results 了解更多纹理。您将看到使用第 9 级压缩内容的 gzip 解压缩率比使用较低级别的压缩内容略快（例如，在第 9 级，解压缩率比在第 6 级时快大约 0.9%）。这是有趣和令人惊讶的。我不认为利率会增加。这只是一组测试结果——它可能不适用于其他场景（在任何情况下差异都非常小）。
分页说明：预压缩静态文件是个好主意，但我不建议在级别 9 使用 gzip。如果使用 zopfli 或 libdeflate，您将获得比 gzip-9 更小的文件。 Zopfli 是来自 Google 的成熟的 gzip 压缩器。 libdeflate 是新的，但非常出色。在我的测试中，它始终优于 gzip-9，但仍然落后于 zopfli。你也可以使用 7-Zip 来创建 gzip 文件，而且它会始终胜过 gzip-9。 （上文中，gzip-9 是指使用 Apache 和 nginx 使用的规范 gzip 或 zlib 应用程序）。
【讨论】：
不，使用最大压缩级别时，解压缩方面没有任何不利之处。事实上，有一点好处，因为压缩得更好的数据解压缩得更快。原因只是解压缩器必须处理的压缩位更少。
【讨论】：
实际上，在real world measurements 中，较高的压缩级别会产生较短的解压缩时间（这可能主要是因为您需要处理较少的永久存储和较少的 RAM 访问）。
实际上，与压缩包相比，在客户端发生的大多数事情都相当昂贵，因此您根本不应该真正关心这一点。
另外请注意，对于图像静态资源，通常已经应用了 huffman/zlib 编码（PNG 只是使用 zlib！），并且通过 gzip 压缩这些资源不会获得太多收益。实际上，通常小图像（例如，图标）适合单个 TCP 数据包（忽略 HTTP 标头，有时比图像本身大），因此您不会获得任何速度提升（但可以节省传输量 - - 如果您提供 TB 小图像。现在，我可以假设您不是 Google 本身...
另外，我想向您指出更高级别的优化，例如可以将您的 javascript 代码转换为更紧凑形状的工具（例如，删除空格，将私有变量从 my_mother_really_likes_this_number_of_unicorns 重命名为 m1）；此外，像 JQuery 这样的东西以“预压缩”的形式出现。 HTML 也是如此。不会让事情更容易调试，但因为您似乎对最终节省空间感兴趣......
【讨论】：