这是一个创建于 3530 天前的主题，其中的信息可能已经有所发展或是发生改变。
随时时间推移和技术更新，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