網站 |
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毫秒的提升。不過這個試驗不能完全說明問題,因為這些被強行推送壓縮數據的用戶中有一些可能是誤傷的,因為它們可能真的是在比較老式的計算機上使用比較老的(不支持壓縮的)軟件(后面會講到,更多的可能并非如此)。
它們?yōu)樯恫恢С謮嚎s?
我們發(fā)現(xiàn)有4種常見的原因導致用戶接受不到壓縮內容:殺毒軟件,瀏覽器缺陷,網絡代理和服務器配置錯誤。前面3種影響了網絡請求導致了網絡服務器不知道瀏覽器其實能解壓內容,尤其是它們錯誤的吧瀏覽器本來應該在每個請求中發(fā)送給服務器的Accept-Encoding 這個http頭給去掉或者破壞了。
殺毒軟件可能是為了減少cpu占用,對網絡請求進行了攔截和篡改,這樣服務器就會發(fā)送不壓縮的數據給客戶端(這樣它們就不用先解壓后查毒而可以直接查毒了)。但是,如果CPU是系統(tǒng)的性能瓶頸,那么殺毒軟件這樣做根本不是在幫忙而是在添亂。一些著名的殺毒軟跟網絡壓縮有沖突。網友們自行可以到Browserscope.org上的 瀏覽器壓縮支持測試頁面 上驗證一下自己的殺毒軟件是否和網絡壓縮有沖突。
默認情況下IE6瀏覽器在通過代理服務器訪問網絡的時候會降級通訊協(xié)議為HTTP/1.0(在IE6的工具——Internet選項——高級 中的第2個選項叫做“ 通過代理連接使用 HTTP 1.1 ” ),其結果就是不會發(fā)送一個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 生成
該怎么做?
為了減少未壓縮的數據,我們需要一起努力
網站 | 資源類型 | 可壓縮的字節(jié)數 |
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 |