网页 gzip 为何不会被代替？

[kmvan]

随时时间推移和技术更新，ie678 之类的老一代浏览器也化为尘土。但为什么网页压缩却没有被革新呢？gz 这格式算法，并不是十分优秀，7z 默认算法比他强的不少。

那么为什么chrome等各大领航浏览器都不关注这些新一代的压缩算法呢？

[FrankFang128]

不是瓶颈吧，能再降低多少体积？

[zealic]

现有的压缩算法的压缩率一般时以时间为代价换来的，如 7z。
换用这些算法很有可能会导致压缩时间增多，影响网页加载时间，总体来说得不偿失。
gzip 算是时间和空间上都比较均衡的压缩算法，因此也就一直沿用下来。

[binux]

7z 压缩慢，服务器撑不住

[155]

chrome有sdch.

[kmvan]

@FrankFang128 不是瓶颈吧，能再降低多少体积？
这想法不对啊。网页都是纯文本，这种状态下，7z 可以比gz少10%左右的体积，意味着网页能快10%加载显示。我认为不是瓶颈的问题，你看http1对于一般网民来说不是也够用吗，为啥还去开发http2呢？这是一种技术更新。


@zealic 现有的压缩算法的压缩率一般时以时间为代价换来的……因此也就一直沿用下来
@binux 7z 压缩慢，服务器撑不住
实际上7z没你们想的这么慢，刚刚测试压缩一个100kb的网页，7z格式还没显示出进度ui就生成文件了，但gz至少会显示进度ui。7z的算法，压缩html文本，还是十分快速的，体积更小。


不过估计没有任何浏览器和服务端敢尝试，应该是因为这不是兼容的问题，而是导致网页能不能访问的问题。

[ryd994]

marginal utility
gzip哪怕最快的参数，随便压压都有一半
7z高参数用的时间是gz百倍不止，就算压到30%，成本收益比一比

[sujin190]

服务器面对十万百万的访问量的时候这个时间cpu的消耗就不是小数了，况且你从10kb压到9kb 8kb有意义么？对于用户感觉来说都一样

[FrankFang128]

@kmvan HTTP 2 相当解决瓶颈问题。尤其是网页外部资源很多的时候

[muzuiget]

@kmvan 拿桌面的GUI程序和主观来做评定「快」…… 比就应该比算法本身，而不是各种GUI前端（冷启动热启动文件系统等等各种方面都有影响）

[glasslion]

@ryd994 如果压缩时间百倍能换来30%的压缩比，那是赚翻了。Google 2013年公布的 Zopfli 算法，相比于zlibc， 压缩时间也是百倍，只比zlibc 减少了3%

[otakustay]

更大的压缩比往往伴随着更多的CPU使用，而服务器是以万、十万、百万QPS来计算的，每个资源多10%的CPU使用，服务器的QPS是否就直接下降了，硬件成本要如何平衡，都是很麻烦的事情

兼容问题本就不是问题，从没有gzip到有gzip怎么过来的，就能gzip到7z怎么过来，Accept-Encoding和Content-Encoding都给你设计好放在那了，完全不会出现兼容的问题

HTTP/2里针对Header弄了个特殊的压缩格式来着

[jasontse]

lzma 算法压缩慢，消耗的内存太多。

[em70]

7z极限压缩经常要用到几个G的内存，高压缩比是用计算时间作为代价的，对服务器来说cpu,内存资源也同样珍贵