我知道GZIP是LZ77和Huffman编码的组合,可以配置1-9之间的级别,其中1表示最快的压缩(压缩较少),9表示最慢的压缩方法(最佳压缩).
我的问题是,级别的选择是否只会影响压缩过程,还是因为压缩的级别而导致解压缩还会产生额外的成本？
我问,因为如果客户支持它,通常很多Web服务器会动态地进行GZIP响应,例如Accept-Encoding: gzip.我很欣赏在飞行时这样做6级的水平可能是普通情况的好选择,因为它在速度和压缩之间提供了良好的平衡.
但是,如果我有一堆静态资产,我可以提前GZIP一次 - 而且永远不需要再次这样做 - 使用最高但最慢的压缩级别会有任何不利之处吗？即,如果使用较低的压缩级别,则客户端现在会产生额外的开销.
Lea*_*ast 24
好问题,以及曝光不足的问题.你的直觉是可靠的 - 对于某些压缩算法,选择最大压缩级别可能需要解压缩器解压缩时的更多工作.
幸运的是,对于gzip来说并非如此 - 客户端/浏览器没有额外的开销来解压缩更多压缩的gzip文件(例如,假设大多数服务器使用的标准zlib代码库,选择9代表压缩而不是6代).对此最好的衡量方法是减压率,目前用于以MB /秒为单位,同时还监控内存和CPU等开销.简单地通过解压缩时间是不好的,因为在较高的压缩设置下文件较小,如果我们只使用秒表,我们就无法控制该因素.
一旦你超过6级压缩内容,gzip解压缩在解压缩时间和内存使用方面很快就会渐近变得渐近.测试结果中由MarcusMüller链接的7,8和9级的解压缩时间线,尽管这是在几秒钟内给出的粗粒度数据.
您还会注意到,在这些结果中,对于0.1 MiB的所有压缩级别,解压缩的内存要求是平坦的.这几乎令人难以置信,只是我们很少看到的软件程度.Mark Adler及其同事应该获得大量的道具.gzip是一个非常好的格式.
内存使用可以解决您的开销问题.真的没有.在浏览器解压缩速度方面你没有从9级获得太多收益,但你不会丢失任何东西.
现在,查看这些测试结果以获得更多纹理.您将看到如何使用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应用程序).
实际上,在实际测量中,较高的压缩级别会产生较低的解压缩时间(这可能主要是由于您需要处理较少的永久存储和较少的RAM访问).
实际上,实际上,与枪支相比,在数据客户端发生的大多数事情相当昂贵,你根本不应该真正关心这一点.
另外请注意,对于作为图像的静态资产,通常使用huffman/zlib编码(PNG只使用zlib!)已经应用,并且通过压缩这些来获得很多.实际上,通常小图像(例如,图标)适合单个TCP数据包(忽略HTTP标头,有时比图像本身更大),因此您无法获得任何速度增益(但节省了传输量 - - 如果你提供了数TB的小图片.现在,我可以假设你不是谷歌本身......
另外,我想指出更高级别的优化,比如可以将你的javascript代码转换为compacter形状的工具(例如,删除空格,将私有变量重命名my_mother_really_likes_this_number_of_unicorns为m1); 此外,像JQuery这样的东西是以"预压缩"的形式出现的.HTML也存在相同的情况.不会让事情更容易调试,但因为你似乎对终极节省空间感兴趣...