Compression GZIP压缩级别对解压缩有影响吗

我知道GZIP是LZ77和Huffman编码的组合，可以配置为1-9级，其中1表示最快的压缩（较少压缩），9表示最慢的压缩方法（最佳压缩）

我的问题是，级别的选择是否仅影响压缩过程，或者根据用于压缩的级别，在解压缩过程中是否还会产生额外的成本

我这样问是因为如果客户端支持GZIP响应，通常很多web服务器都会动态响应GZIP，例如，

接受编码：GZIP

。我明白，在运行中执行此操作时，对于一般情况，级别（如6）可能是一个不错的选择，因为它在速度和压缩之间提供了一个很好的平衡

然而，如果我有一堆静态资产，我可以提前GZIP一次，并且永远不需要再这样做，那么使用最高但最慢的压缩级别会有任何不利之处吗？也就是说，如果使用较低的压缩级别，客户端现在是否会产生额外的开销。

实际上，较高的压缩级别会产生较低的解压缩时间（这可能主要是因为您需要处理较少的永久存储和较少的RAM访问）

因为，事实上，和gunzipping相比，在有数据的客户机上发生的大多数事情都相当昂贵，所以您根本不应该真正关心这一点

还要注意的是，对于作为图像的静态资产，通常已经应用了huffman/zlib编码（PNG只是使用zlib！），并且通过gzip压缩这些内容不会获得太多好处。事实上，通常小图像（例如图标）可以放入一个TCP数据包（忽略HTTP头，它有时比图像本身大），因此您不会获得任何速度增益（但可以节省传输量上的钱——如果您发送TB的小图像。现在，我可以假定您不是Google本身

---

另外，我想向您指出更高级别的优化，比如可以将javascript代码转换为更紧凑的形状的工具（例如，删除空白，从

my_mother\u中重命名私有变量非常喜欢这个数量的独角兽

到

m1

）；此外，像JQuery这样的东西也是“预压缩”的表单。HTML也是如此。这并不会使调试变得更容易，但因为您似乎对最终节省空间感兴趣…

这是一个很好的问题，也是一个暴露不足的问题。您的直觉是可靠的–对于某些压缩算法，选择最大压缩级别可能需要解压器在解压时做更多的工作

幸运的是，gzip并非如此——客户端/浏览器解压缩更严重压缩的gzip文件没有额外开销（例如，选择9而不是6，假设大多数服务器使用标准zlib代码库）。最好的方法是解压速率，目前的解压速率是以MB/秒为单位的，同时还要监控内存和CPU等开销。简单地计算解压时间是不好的，因为文件在更高的压缩设置下更小，如果只使用秒表，我们无法控制该因素

gzip解压在解压时间和内存使用率方面都会很快趋于渐进，一旦您通过了第6级压缩内容。解压时间是由Marcus Müller链接的测试结果中第7、8和9级的扁平线，尽管这是以整秒给出的粗粒度数据

在这些结果中，您还会注意到，对于0.1 MiB的所有级别的压缩，解压缩的内存需求都是平坦的。这几乎是难以置信的，只是我们很少看到的软件的卓越程度。马克·阿德勒和同事们所取得的成就值得大力支持。gzip是一种非常好的格式

内存的使用直接涉及到你关于开销的问题。实际上没有。在浏览器解压速度方面，9级不会给你带来太多好处，但你不会损失任何东西

现在，请查看更多的纹理。您将看到第9级压缩内容的gzip解压缩速度比较低级别的压缩内容略快（例如，在第9级，解压缩速度比第6级快约0.9%）。这很有趣，也很令人惊讶。我不希望比率增加。这只是一组测试结果——它可能不适用于其他场景（而且在任何情况下差异都很小）

---

临别赠言：预压缩静态文件是一个好主意，但我不推荐gzip处于9级。使用zopfli或。zopfli是Google提供的一个成熟的gzip压缩器。libdeflate是新的，但非常优秀。在我的测试中，它始终优于gzip-9，但仍然落后于zopfli。您也可以使用7-Zip创建gzip文件，它将始终优于gzip-9。（在前面，gzip-9指的是使用Apache和nginx使用的规范gzip或zlib应用程序）.

不，当使用最大压缩级别时，在解压缩方面没有缺点。事实上，有一点好处，那就是更好的压缩数据解压更快。原因只是解压器必须处理的压缩位更少。

感谢响应和到基准的链接。我已经在使用作为我的Grunt构建的一部分，所有静态资产的缩小：）没错，我不是Google+带宽成本也不是一个真正的问题。但是，由于我正在gzip我的基于文本的资产（HTML/CSS/JS），因此除了在构建中添加几秒钟之外，在构建中使用-9标志而不是-6标志并不需要更多的努力。我主要担心的是这样做是否会给客户端带来额外的负担，使其不得不解压缩内容。根据这些结果，它似乎不会——事实上它可能更快