据我所知，GZIP是LZ77和Huffman编码的组合，可以配置1-9之间的级别，其中1表示最快压缩（压缩较少），9表示最慢压缩方法（最佳压缩）。
我的问题是， 级别的选择是否会影响压缩过程，还是因为压缩程度而导致解压缩还会产生额外成本？
我问，因为通常很多网络服务器会在客户支持时动态地进行GZIP响应，例如： Accept-Encoding: gzip。我很欣赏在飞行时这样做6级的水平可能是普通情况的好选择，因为它在速度和压缩之间提供了良好的平衡。
但是，如果我有一堆静态资产，我可以提前GZIP一次 - 而且永远不需要再次这样做 - 那么使用最高但最慢的压缩级别会有任何不利之处吗？即如果使用较低的压缩级别，客户端现在会产生额外的开销。
答案 0 :(得分：20)
很好的问题，以及曝光不足的问题。你的直觉是可靠的 - 对于某些压缩算法，选择最大压缩级别可能需要解压缩器解压缩时的更多工作。
幸运的是，对于gzip来说并非如此 - 客户端/浏览器没有额外的开销来解压缩压缩程度更高的gzip文件（例如，假设大多数服务器使用的标准zlib代码库，选择9代表压缩而不是6代）。对此最好的衡量方法是解压缩率，目前用于以MB /秒为单位，同时还监控内存和CPU等开销。简单地通过减压时间是不好的，因为在较高的压缩设置下文件较小，如果我们只使用秒表，我们就无法控制该因素。
一旦超过6级压缩内容，gzip解压缩在解压缩时间和内存使用方面很快就会渐近变化。测试结果中由MarcusMüller链接的7,8和9级的解压缩时间线，尽管这是在几秒钟内给出的粗粒度数据。
您还会注意到，在这些结果中，对于0.1 MiB的所有压缩级别，解压缩的内存要求是平坦的。这几乎令人难以置信，只是我们很少看到的软件程度。 Mark Adler及其同事应该获得大量的道具。 gzip是一种非常好的格式。
内存使用可以解决您的开销问题。真的没有。在浏览器解压缩速度方面你没有从9级获得太多收益，但你不会丢失任何东西。
现在，查看these test results以获得更多纹理。您将看到gzip解压缩率如何更快 9级压缩内容而不是较低级别（例如，在级别9，分解率比级别6快约0.9％）。这很有趣也很令人惊讶。我不希望这个比率增加。这只是一组测试结果 - 它可能不适用于其他场景（在任何情况下差异都很小）。
分手注意事项：预压缩静态文件是一个好主意，但我不建议在第9级使用gzip。通过使用zopfli或libdeflate，您将获得比gzip-9更小的文件。 Zopfli是来自谷歌的成熟的gzip压缩器。 libdeflate是新的但非常优秀。在我的测试中，它始终胜过gzip-9，但仍然落后于zopfli。您也可以使用7-Zip创建gzip文件，它将始终击败gzip-9。 （在上文中，gzip-9指的是使用Apache和nginx使用的规范gzip或zlib应用程序。）
答案 1 :(得分：7)
不，使用最大压缩级别时，解压缩方面没有任何缺点。事实上，有一个小小的好处，因为更好压缩的数据解压缩得更快。原因是解压缩器必须处理的压缩位更少。
答案 2 :(得分：6)
实际上，在real world measurements中，较高的压缩级别会产生较低的解压缩时间（这可能主要是因为您需要处理较少的永久存储和较少的RAM访问）。
实际上，与枪支相比，在客户端发生数据的大多数事情相当昂贵，你根本不应该真的关心这一点。
另外请注意，对于作为图像的静态资源，通常使用huffman / zlib编码（PNG只使用zlib！），并且通过压缩这些来获得更多收益。实际上，通常小图像（例如，图标）适合单个TCP数据包（忽略HTTP标头，有时比图像本身大），因此您无法获得任何速度增益（但在转移时节省资金）音量 - 如果你提供太字节的小图片。现在，我可以假设你不是谷歌本身......
此外，我想指出更高级别的优化，例如可以将您的javascript代码转换为更加紧凑的形状的工具（例如，删除空格，将私有变量从my_mother_really_likes_this_number_of_unicorns重命名为{{1 }}）;此外，像JQuery这样的东西来自预压缩＆＃34;形成。 HTML也存在相同的情况。不会让事情变得更容易调试，但是因为你似乎对终极空间节省感兴趣......