原文：Use compression to make the web faster
作者：By Arvind Jain, Engineering Director and Jason Glasgow,
Staff Software Engineer
翻譯：http://www.blogjava.net/emu/archive/2010/02/18/313398.html
壓縮，讓網(wǎng)絡(luò)更快
簡(jiǎn)介
互聯(lián)網(wǎng)上，每天有超過(guò)99人年浪費(fèi)在下載 未經(jīng)壓縮的內(nèi)容 上面。雖然支持壓縮已經(jīng)是每個(gè)現(xiàn)代的瀏覽器的標(biāo)準(zhǔn)功能了，但是它們的使用者們往往還是由于這樣那樣的原因不能下載到壓縮的數(shù)據(jù)。這樣就造成了帶寬浪費(fèi)并且拖慢了用戶(hù)和網(wǎng)頁(yè)的交互。
數(shù)據(jù)不壓縮對(duì)所有的使用者都是一種傷害。對(duì)于窄帶用戶(hù)，下載那些多余的數(shù)據(jù)花費(fèi)了更多的時(shí)間。而對(duì)于寬帶用戶(hù)，雖然數(shù)據(jù)傳輸非?？?，但是在進(jìn)入所能達(dá)到的最高速的數(shù)據(jù)傳輸之前，不壓縮的數(shù)據(jù)也需要更多的網(wǎng)絡(luò)間往返（IP包）（emu注：這里指的大概是寬帶用戶(hù)在訪(fǎng)問(wèn)多媒體網(wǎng)站時(shí)，在高速下載多媒體內(nèi)容之前，需要先下載網(wǎng)頁(yè)、css和腳本的資源），這種情況下，網(wǎng)絡(luò)間的往返次數(shù)（IP包個(gè)數(shù)）在裝載一個(gè)完整的網(wǎng)頁(yè)所需要的時(shí)間中是一個(gè)比網(wǎng)速更大的影響因素。即使網(wǎng)絡(luò)狀況非常好的用戶(hù)哪里，這些多余的網(wǎng)絡(luò)間往返也經(jīng)常會(huì)多耗費(fèi)數(shù)十甚至上百毫秒的時(shí)間。
在Steve Souders 的《Even Faster Web Sites》里面，Tony Gentilcore用數(shù)據(jù)展現(xiàn)出了禁止壓縮時(shí)頁(yè)面裝載時(shí)間的增加的情況。在得到了許可后，我們也重現(xiàn)了其總?cè)齻€(gè)Alexa 排名最高等級(jí)的網(wǎng)站的測(cè)速結(jié)果：
網(wǎng)站 | 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%) |
數(shù)據(jù)來(lái)自Steve Souders的《 Even Faster Web Sites》中的“第9章：超越Gzip壓縮”，經(jīng)過(guò)作者許可。
Google的web搜索日志也顯示，下載未經(jīng)壓縮數(shù)據(jù)的用戶(hù)比下載壓縮數(shù)據(jù)的用戶(hù)評(píng)價(jià)多花費(fèi)25％的頁(yè)面裝載時(shí)間。在一個(gè)隨機(jī)試驗(yàn)中，我們強(qiáng)行給一些（聲稱(chēng)）不接受壓縮數(shù)據(jù)的用戶(hù)推送了壓縮數(shù)據(jù)，結(jié)果我們測(cè)量到它們的頁(yè)面延遲有300毫秒的提升。不過(guò)這個(gè)試驗(yàn)不能完全說(shuō)明問(wèn)題，因?yàn)檫@些被強(qiáng)行推送壓縮數(shù)據(jù)的用戶(hù)中有一些可能是誤傷的，因?yàn)樗鼈兛赡苷娴氖窃诒容^老式的計(jì)算機(jī)上使用比較老的（不支持壓縮的）軟件（后面會(huì)講到，更多的可能并非如此）。
它們?yōu)樯恫恢С謮嚎s?
我們發(fā)現(xiàn)有4種常見(jiàn)的原因?qū)е掠脩?hù)接受不到壓縮內(nèi)容：殺毒軟件，瀏覽器缺陷，網(wǎng)絡(luò)代理和服務(wù)器配置錯(cuò)誤。前面3種影響了網(wǎng)絡(luò)請(qǐng)求導(dǎo)致了網(wǎng)絡(luò)服務(wù)器不知道瀏覽器其實(shí)能解壓內(nèi)容，尤其是它們錯(cuò)誤的吧瀏覽器本來(lái)應(yīng)該在每個(gè)請(qǐng)求中發(fā)送給服務(wù)器的Accept-Encoding 這個(gè)http頭給去掉或者破壞了。
殺毒軟件可能是為了減少cpu占用，對(duì)網(wǎng)絡(luò)請(qǐng)求進(jìn)行了攔截和篡改，這樣服務(wù)器就會(huì)發(fā)送不壓縮的數(shù)據(jù)給客戶(hù)端（這樣它們就不用先解壓后查毒而可以直接查毒了）。但是，如果CPU是系統(tǒng)的性能瓶頸，那么殺毒軟件這樣做根本不是在幫忙而是在添亂。一些著名的殺毒軟跟網(wǎng)絡(luò)壓縮有沖突。網(wǎng)友們自行可以到Browserscope.org上的 瀏覽器壓縮支持測(cè)試頁(yè)面 上驗(yàn)證一下自己的殺毒軟件是否和網(wǎng)絡(luò)壓縮有沖突。
默認(rèn)情況下IE6瀏覽器在通過(guò)代理服務(wù)器訪(fǎng)問(wèn)網(wǎng)絡(luò)的時(shí)候會(huì)降級(jí)通訊協(xié)議為HTTP/1.0（在IE6的工具――Internet選項(xiàng)――高級(jí) 中的第2個(gè)選項(xiàng)叫做“ 通過(guò)代理連接使用 HTTP 1.1 ” ），其結(jié)果就是不會(huì)發(fā)送一個(gè)Accept-Encoding的請(qǐng)求頭部。下面的表格是從Google的網(wǎng)絡(luò)搜索日志中生成出來(lái)的，顯示出來(lái)自IE6的搜索在所有“未聲明接受壓縮結(jié)果”的搜索中占了36％。這個(gè)比例比IE6的實(shí)際使用比例要高。
瀏覽器 | 搜索結(jié)果中要求不壓縮的比例 | 在所有未聲明支持壓縮的搜索中所占的比例 |
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 |
數(shù)據(jù)來(lái)自Google網(wǎng)絡(luò)搜索日志
還有那么一小撮ISP，它們的未壓縮內(nèi)容（未聲明接受壓縮的請(qǐng)求）的比例超過(guò)了95％。一個(gè)看起來(lái)有道理的假設(shè)是，這些ISP或者公司代理去掉或者篡改了Accept-Encoding這個(gè)HTTP頭部。和殺毒軟件的情況一樣，懷疑自己的ISP和網(wǎng)絡(luò)壓縮有沖突的網(wǎng)友們自行可以到Browserscope.org上的 瀏覽器壓縮支持測(cè)試頁(yè)面 上驗(yàn)證一下。
| 網(wǎng)站 | 資源類(lèi)型 | 可壓縮的字節(jié)數(shù) |
| 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 |
數(shù)據(jù)使用 Page Speed 生成
該怎么做?
為了減少未壓縮的數(shù)據(jù)，我們需要一起努力