这是一个创建于 3855 天前的主题，其中的信息可能已经有所发展或是发生改变。
随时时间推移和技术更新，ie678 之类的老一代浏览器也化为尘土。但为什么网页压缩却没有被革新呢？gz 这格式算法，并不是十分优秀，7z 默认算法比他强的不少。
那么为什么chrome等各大领航浏览器都不关注这些新一代的压缩算法呢？
 | 1 FrankFang128 2015-03-21 12:16:18 +08:00 via Android 不是瓶颈吧，能再降低多少体积？ |
 | 2 zealic 2015-03-21 12:23:33 +08:00 现有的压缩算法的压缩率一般时以时间为代价换来的，如 7z。 换用这些算法很有可能会导致压缩时间增多，影响网页加载时间，总体来说得不偿失。 gzip 算是时间和空间上都比较均衡的压缩算法，因此也就一直沿用下来。 |
 | 3 binux 2015-03-21 12:35:31 +08:00 7z 压缩慢，服务器撑不住 |
 | 4 155 2015-03-21 12:47:12 +08:00 chrome有sdch. |
 | 5 kmvan OP @FrankFang128 不是瓶颈吧，能再降低多少体积？ 这想法不对啊。网页都是纯文本，这种状态下，7z 可以比gz少10%左右的体积，意味着网页能快10%加载显示。我认为不是瓶颈的问题，你看http1对于一般网民来说不是也够用吗，为啥还去开发http2呢？这是一种技术更新。 @zealic 现有的压缩算法的压缩率一般时以时间为代价换来的……因此也就一直沿用下来 @binux 7z 压缩慢，服务器撑不住 实际上7z没你们想的这么慢，刚刚测试压缩一个100kb的网页，7z格式还没显示出进度ui就生成文件了，但gz至少会显示进度ui。7z的算法，压缩html文本，还是十分快速的，体积更小。 不过估计没有任何浏览器和服务端敢尝试，应该是因为这不是兼容的问题，而是导致网页能不能访问的问题。 |
 | 6 ryd994 2015-03-21 13:23:28 +08:00 via Android marginal utility gzip哪怕最快的参数，随便压压都有一半 7z高参数用的时间是gz百倍不止，就算压到30%，成本收益比一比 |
 | 7 sujin190 2015-03-21 14:19:42 +08:00 服务器面对十万百万的访问量的时候这个时间cpu的消耗就不是小数了，况且你从10kb压到9kb 8kb有意义么？对于用户感觉来说都一样 |
| 8 FrankFang128 2015-03-21 14:36:09 +08:00 via Android @kmvan HTTP 2 相当解决瓶颈问题。尤其是网页外部资源很多的时候 |
 | 9 muzuiget 2015-03-21 15:43:22 +08:00 @kmvan 拿桌面的GUI程序和主观来做评定「快」…… 比就应该比算法本身，而不是各种GUI前端（冷启动热启动文件系统等等各种方面都有影响） |
 | 10 glasslion 2015-03-21 16:03:10 +08:00 @ryd994 如果压缩时间百倍能换来30%的压缩比，那是赚翻了。Google 2013年公布的 Zopfli 算法，相比于zlibc， 压缩时间也是百倍，只比zlibc 减少了3% |
 | 11 otakustay 2015-03-21 16:30:38 +08:00 更大的压缩比往往伴随着更多的CPU使用，而服务器是以万、十万、百万QPS来计算的，每个资源多10%的CPU使用，服务器的QPS是否就直接下降了，硬件成本要如何平衡，都是很麻烦的事情 兼容问题本就不是问题，从没有gzip到有gzip怎么过来的，就能gzip到7z怎么过来，Accept-Encoding和Content-Encoding都给你设计好放在那了，完全不会出现兼容的问题 HTTP/2里针对Header弄了个特殊的压缩格式来着 |
 | 12 jasontse 2015-03-21 16:32:28 +08:00 via iPad lzma 算法压缩慢，消耗的内存太多。 |
 | 13 em70 2015-03-21 16:35:26 +08:00 via Android 7z极限压缩经常要用到几个G的内存，高压缩比是用计算时间作为代价的，对服务器来说cpu,内存资源也同样珍贵 |
Select Language