网站 |
Alexa 排名 |
总 |
|
|
|
|
10.3KB (44%) |
0.12秒(12%) |
1.3秒 (25%) |
|
2 |
348 KB (175%) |
9.4秒 (414%) |
63秒(524%) |
|
3 |
331 KB (126%) |
1.2秒 (64%) |
9.4秒 (137%) |
数据来自Steve Souders的《 Even Faster Web Sites》中的“第9章:超越Gzip压缩”,经过作者许可。
Google的web搜索日志也显示,下载未经压缩数据的用户比下载压缩数据的用户评价多花费25%的页面装载时间。在一个随机试验中,我们强行给一些(声称)不接受压缩数据的用户推送了压缩数据,结果我们测量到它们的页面延迟有300毫秒的提升。不过这个试验不能完全说明问题,因为这些被强行推送压缩数据的用户中有一些可能是误伤的,因为它们可能真的是在比较老式的计算机上使用比较老的(不支持压缩的)软件(后面会讲到,更多的可能并非如此)。
它们为啥不支持压缩?
我们发现有4种常见的原因导致用户接受不到压缩内容:杀毒软件,浏览器缺陷,网络代理和服务器配置错误。前面3种影响了网络请求导致了网络服务器不知道浏览器其实能解压内容,尤其是它们错误的吧浏览器本来应该在每个请求中发送给服务器的Accept-Encoding 这个http头给去掉或者破坏了。
杀毒软件可能是为了减少cpu占用,对网络请求进行了拦截和篡改,这样服务器就会发送不压缩的数据给客户端(这样它们就不用先解压后查毒而可以直接查毒了)。但是,如果CPU是系统的性能瓶颈,那么杀毒软件这样做根本不是在帮忙而是在添乱。一些著名的杀毒软跟网络压缩有冲突。网友们自行可以到Browserscope.org上的 浏览器压缩支持测试页面 上验证一下自己的杀毒软件是否和网络压缩有冲突。
默认情况下IE6浏览器在通过代理服务器访问网络的时候会降级通讯协议为HTTP/1.0(在IE6的工具——Internet选项——高级 中的第2个选项叫做“ 通过代理连接使用 HTTP 1.1 ” ),其结果就是不会发送一个Accept-Encoding的请求头部。下面的表格是从Google的网络搜索日志中生成出来的,显示出来自IE6的搜索在所有“未声明接受压缩结果”的搜索中占了36%。这个比例比IE6的实际使用比例要高。
浏览器 |
搜索结果中要求不压缩的比例 |
在所有未声明支持压缩的搜索中所占的比例 |
Google Chrome |
1 |
1 |
Safari |
1 |
1 |
Firefox 3.5 |
3 |
4 |
|
6 |
5 |
Firefox 3.0 |
6 |
7 |
Other |
46 |
22 |
|
7 |
24 |
|
20 |
36 |
数据来自Google网络搜索日志
还有那么一小撮ISP,它们的未压缩内容(未声明接受压缩的请求)的比例超过了95%。一个看起来有道理的假设是,这些ISP或者公司代理去掉或者篡改了Accept-Encoding这个HTTP头部。和杀毒软件的情况一样,怀疑自己的ISP和网络压缩有冲突的网友们自行可以到Browserscope.org上的 浏览器压缩支持测试页面 上验证一下。
数据使用 Page Speed 生成
该怎么做?
为了减少未压缩的数据,我们需要一起努力
网站 | 资源类型 | 可压缩的字节数 |
www.cnn.com | CSS and JavaScript | 330 kB |
www.twitter.com | CSS and JavaScript | 40 kB |
www.bbc.co.uk | CSS and JavaScript | 201 kB |
下一篇:中化商务CRM系统成功投入运营