Yahoo! 的 Exceptional Performance team 在 Web 前端方面作出了卓越的貢獻(xiàn)。廣為人知的優(yōu)化規(guī)則也由 13 條到 14 條，再到 20 條，乃至現(xiàn)在的 34 條–真是與時(shí)俱進(jìn)啊。
Excetional Performance團(tuán)隊(duì)總結(jié)出了一系列可以提高網(wǎng)站速度的方法。可以分為7大類34條。包括內(nèi)容、服務(wù)器、cookie、css、JavaScript、圖片、移動(dòng)應(yīng)用等七部分。

 

css文件都放入一個(gè)樣式表中。當(dāng)腳本或者樣式表在不同頁面中使用時(shí)需要做不同的修改，這可能會相對麻煩點(diǎn)，但即便如此也要把這個(gè)方法作為改善頁面性能的重要一步。

 

CSS Sprites：是減少圖像請求的有效方法。把所有的背景圖像都放到一個(gè)圖片文件中，然后通過CSS的background-image和background-position屬性來顯示圖片的不同部分；

 

圖片地圖：是 把多張圖片整合到一張圖片中。雖然文件的總體大小不會改變，但是可以減少HTTP請求次數(shù)。圖片地圖只有在圖片的所有組成部分在頁面中是緊挨在一起的時(shí)候 才能使用，如導(dǎo)航欄。確定圖片的坐標(biāo)和可能會比較繁瑣且容易出錯(cuò)，同時(shí)使用圖片地圖導(dǎo)航也不具有可讀性，因此不推薦這種方法；

內(nèi)聯(lián)圖像：是使用data:URL scheme的方法把圖像數(shù)據(jù)加載頁面中。這可能會增加頁面的大小。把內(nèi)聯(lián)圖像放到樣式表（可緩存）中可以減少HTTP請求同時(shí)又避免增加頁面文件的大小。但是內(nèi)聯(lián)圖像現(xiàn)在還沒有得到主流瀏覽器的支持。

 

減少頁面的HTTP請求次數(shù)是你首先要做的一步。這是改進(jìn)首次訪問用戶等待時(shí)間的最重要的方法。如同Tenni Theurer的他的博客Browser Cahe Usage-Exposed!中所說，HTTP請求在無緩存情況下占去了40%到60%的響應(yīng)時(shí)間。讓那些初次訪問你網(wǎng)站的人獲得更加快速的體驗(yàn)吧！

 

2、減少DNS查找次數(shù)

 

域名系統(tǒng)（DNS）提供了域名和IP的對應(yīng)關(guān)系，就像電話本中人名和他們的電話號碼的關(guān)系一樣。當(dāng)你在瀏覽器地址欄中輸入www.net-web.cn 時(shí)，DNS解析服務(wù)器就會返回這個(gè)域名對應(yīng)的IP地址。DNS解析的過程同樣也是需要時(shí)間的。一般情況下返回給定域名對應(yīng)的IP地址會花費(fèi)20到120毫秒的時(shí)間。而且在這個(gè)過程中瀏覽器什么都不會做直到DNS查找完畢。

 

緩存DNS查找可以改善頁面性能。這種緩存需要一個(gè)特定的緩存服務(wù)器，這種服務(wù)器一般屬于用戶的ISP提供商或者本地局域網(wǎng)控制，但是它同樣會在用戶使用 的計(jì)算機(jī)上產(chǎn)生緩存。DNS信息會保留在操作系統(tǒng)的DNS緩存中（微軟Windows系統(tǒng)中DNS Client Service）。大多數(shù)瀏覽器有獨(dú)立于操作系統(tǒng)以外的自己的緩存。由于瀏覽器有自己的緩存記錄，因此在一次請求中它不會受到操作系統(tǒng)的影響。

 

Internet Explorer默認(rèn)情況下對DNS查找記錄的緩存時(shí)間為30分鐘，它在注冊表中的鍵值為DnsCacheTimeout。Firefox對DNS的查找 記錄緩存時(shí)間為1分鐘，它在配置文件中的選項(xiàng)為network.dnsCacheExpiration（Fasterfox把這個(gè)選項(xiàng)改為了1小時(shí)）。

 

當(dāng)客戶端中的DNS緩存都為空時(shí)（瀏覽器和操作系統(tǒng)都為空），DNS查找的次數(shù)和頁面中主機(jī)名的數(shù)量相同。這其中包括頁面中URL、圖片、腳本文件、樣式表、Flash對象等包含的主機(jī)名。減少主機(jī)名的數(shù)量可以減少DNS查找次數(shù)。

 

減少主機(jī)名的數(shù)量還可以減少頁面中并行下載的數(shù)量。減少DNS查找次數(shù)可以節(jié)省響應(yīng)時(shí)間，但是減少并行下載卻會增加響應(yīng)時(shí)間。我的指導(dǎo)原則是把這些頁面中 的內(nèi)容分割成至少兩部分但不超過四部分。這種結(jié)果就是在減少DNS查找次數(shù)和保持較高程度并行下載兩者之間的權(quán)衡了。

 

 

3、避免跳轉(zhuǎn)

 

跳轉(zhuǎn)是使用301和302代碼實(shí)現(xiàn)的。下面是一個(gè)響應(yīng)代碼為301的HTTP頭：
 

HTTP/1.1 301 Moved Permanently
 

Location: http://example.com/newuri
 

Content-Type: text/html
 

瀏覽器會把用戶指向到Location中指定的URL。頭文件中的所有信息在一次跳轉(zhuǎn)中都是必需的，內(nèi)容部分可以為空。不管他們的名稱，301和302響 應(yīng)都不會被緩存除非增加一個(gè)額外的頭選項(xiàng)，如Expires或者Cache-Control來指定它緩存。<meat />元素的刷新標(biāo)簽和JavaScript也可以實(shí)現(xiàn)URL的跳轉(zhuǎn)，但是如果你必須要跳轉(zhuǎn)的時(shí)候，最好的方法就是使用標(biāo)準(zhǔn)的3XXHTTP狀態(tài)代 碼，這主要是為了確保“后退”按鈕可以正確地使用。

但是要記住跳轉(zhuǎn)會降低用戶體驗(yàn)。在用戶和HTML文檔中間增加一個(gè)跳轉(zhuǎn)，會拖延頁面中所有元素的顯示，因?yàn)樵贖TML文件被加載前任何文件（圖像、Flash等）都不會被下載。

有一種經(jīng)常被網(wǎng)頁開發(fā)者忽略卻往往十分浪費(fèi)響應(yīng)時(shí)間的跳轉(zhuǎn)現(xiàn)象。這種現(xiàn)象發(fā)生在當(dāng)URL本該有斜杠（/）卻被忽略掉時(shí)。例如，當(dāng)我們要訪問http: //astrology.yahoo.com/astrology 時(shí)，實(shí)際上返回的是一個(gè)包含301代碼的跳轉(zhuǎn)，它指向的是http://astrology.yahoo.com/astrology/ （注意末尾的斜杠）。在Apache服務(wù)器中可以使用Alias 或者 mod_rewrite或者the DirectorySlash來避免。

連接新網(wǎng)站和舊網(wǎng)站是跳轉(zhuǎn)功能經(jīng)常被用到的另一種情況。這種情況下往往要連接網(wǎng)站的不同內(nèi)容然后根據(jù)用戶的不同類型（如瀏覽器類型、用戶賬號所屬類型）來 進(jìn)行跳轉(zhuǎn)。使用跳轉(zhuǎn)來實(shí)現(xiàn)兩個(gè)網(wǎng)站的切換十分簡單，需要的代碼量也不多。盡管使用這種方法對于開發(fā)者來說可以降低復(fù)雜程度，但是它同樣降低用戶體驗(yàn)。一個(gè) 可替代方法就是如果兩者在同一臺服務(wù)器上時(shí)使用Alias和mod_rewrite和實(shí)現(xiàn)。如果是因?yàn)橛蛎牟煌捎锰D(zhuǎn)，那么可以通過使用Alias 或者mod_rewirte建立CNAME（保存一個(gè)域名和另外一個(gè)域名之間關(guān)系的DNS記錄）來替代。

 

4、可緩存的AJAX

Ajax經(jīng)常被提及的一個(gè)好處就是由于其從后臺服務(wù)器傳輸信息的異步性而為用戶帶來的反饋的即時(shí)性。但是，使用Ajax并不能保證用戶不會在等待異步的 JavaScript和XML響應(yīng)上花費(fèi)時(shí)間。在很多應(yīng)用中，用戶是否需要等待響應(yīng)取決于Ajax如何來使用。例如，在一個(gè)基于Web的Email客戶端 中，用戶必須等待Ajax返回符合他們條件的郵件查詢結(jié)果。記住一點(diǎn)，“異步”并不異味著“即時(shí)”，這很重要。

 

為了提高性能，優(yōu)化Ajax響應(yīng)是很重要的。提高Ajxa性能的措施中最重要的方法就是使響應(yīng)具有可緩存性，具體的討論可以查看Add an Expires or a Cache-Control Header。

其它的幾條規(guī)則也同樣適用于Ajax：

Gizp壓縮文件

減少DNS查找次數(shù)

精簡JavaScript

避免跳轉(zhuǎn)

配置ETags

 

讓我們來看一個(gè)例子：一個(gè)Web2.0的Email客戶端會使用Ajax來自動(dòng)完成對用戶地址薄的下載。如果用戶在上次使用過Email web應(yīng)用程序后沒有對地址薄作任何的修改，而且Ajax響應(yīng)通過Expire或者Cacke-Control頭來實(shí)現(xiàn)緩存，那么就可以直接從上一次的緩 存中讀取地址薄了。必須告知瀏覽器是使用緩存中的地址薄還是發(fā)送一個(gè)新的請求。這可以通過為讀取地址薄的Ajax URL增加一個(gè)含有上次編輯時(shí)間的時(shí)間戳來實(shí)現(xiàn)，例如，&t=11900241612等。如果地址薄在上次下載后沒有被編輯過，時(shí)間戳就不變，則 從瀏覽器的緩存中加載從而減少了一次HTTP請求過程。如果用戶修改過地址薄，時(shí)間戳就會用來確定新的URL和緩存響應(yīng)并不匹配，瀏覽器就會重要請求更新 地址薄。

即使你的Ajxa響應(yīng)是動(dòng)態(tài)生成的，哪怕它只適用于一個(gè)用戶，那么它也應(yīng)該被緩存起來。這樣做可以使你的Web2.0應(yīng)用程序更加快捷。

 

 

5、推遲加載內(nèi)容

 

你可以仔細(xì)看一下你的網(wǎng)頁，問問自己“哪些內(nèi)容是頁面呈現(xiàn)時(shí)所必需首先加載的？哪些內(nèi)容和結(jié)構(gòu)可以稍后再加載？

把整個(gè)過程按照onload事件分隔成兩部分，JavaScript是一個(gè)理想的選擇。例如，如果你有用于實(shí)現(xiàn)拖放和動(dòng)畫的JavaScript，那么它 就以等待稍后加載，因?yàn)轫撁嫔系耐戏旁厥窃诔跏蓟尸F(xiàn)之后才發(fā)生的。其它的例如隱藏部分的內(nèi)容（用戶操作之后才顯現(xiàn)的內(nèi)容）和處于折疊部分的圖像也可以推遲加載。

工具可以節(jié)省你的工作量：YUI Image Loader可以幫你推遲加載折疊部分的圖片，YUI Get utility是包含JS和 CSS的便捷方法。比如你可以打開Firebug的Net選項(xiàng)卡看一下Yahoo的首頁。

當(dāng)性能目標(biāo)和其它網(wǎng)站開發(fā)實(shí)踐一致時(shí)就會相得益彰。這種情況下，通過程序提高網(wǎng)站性能的方法告訴我們，在支持JavaScript的情況下，可以先去除用 戶體驗(yàn)，不過這要保證你的網(wǎng)站在沒有JavaScript也可以正常運(yùn)行。在確定頁面運(yùn)行正常后，再加載腳本來實(shí)現(xiàn)如拖放和動(dòng)畫等更加花哨的效果。

 

 

6、預(yù)加載

 

預(yù)加載和后加載看起來似乎恰恰相反，但實(shí)際上預(yù)加載是為了實(shí)現(xiàn)另外一種目標(biāo)。預(yù)加載是在瀏覽器空閑時(shí)請求將來可能會用到的頁面內(nèi)容（如圖像、樣式表和腳 本）。使用這種方法，當(dāng)用戶要訪問下一個(gè)頁面時(shí)，頁面中的內(nèi)容大部分已經(jīng)加載到緩存中了，因此可以大大改善訪問速度。

 

下面提供了幾種預(yù)加載方法：

無條件加載：觸發(fā)onload事件時(shí)，直接加載額外的頁面內(nèi)容。以Google.com為例，你可以看一下它的spirit image圖像是怎樣在onload中加載的。這個(gè)spirit image圖像在google.com主頁中是不需要的，但是卻可以在搜索結(jié)果頁面中用到它。

 

有條件加載：根據(jù)用戶的操作來有根據(jù)地判斷用戶下面可能去往的頁面并相應(yīng)的預(yù)加載頁面內(nèi)容。在search.yahoo.com中你可以看到如何在你輸入內(nèi)容時(shí)加載額外的頁面內(nèi)容。

 

有預(yù)期的加載：載入重新設(shè)計(jì)過的頁面時(shí)使用預(yù)加載。這種情況經(jīng)常出現(xiàn)在頁面經(jīng)過重新設(shè)計(jì)后用戶抱怨“新的頁面看起來很酷，但是卻比以前慢”。問題可能出在用戶對于你的舊站 點(diǎn)建立了完整的緩存，而對于新站點(diǎn)卻沒有任何緩存內(nèi)容。因此你可以在訪問新站之前就加載一部內(nèi)容來避免這種結(jié)果的出現(xiàn)。在你的舊站中利用瀏覽器的空余時(shí)間 加載新站中用到的圖像的和腳本來提高訪問速度。

 

 

7、減少DOM元素?cái)?shù)量

 

一個(gè)復(fù)雜的頁面意味著需要下載更多數(shù)據(jù)，同時(shí)也意味著JavaScript遍歷DOM的效率越慢。比如當(dāng)你增加一個(gè)事件句柄時(shí)在500和5000個(gè)DOM元素中循環(huán)效果肯定是不一樣的。

大量的DOM元素的存在意味著頁面中有可以不用移除內(nèi)容只需要替換元素標(biāo)簽就可以精簡的部分。你在頁面布局中使用表格了嗎？你有沒有僅僅為了布局而引入更多的<div>元素呢？也許會存在一個(gè)適合或者在語意是更貼切的標(biāo)簽可以供你使用。

YUI CSS utilities可以給你的布局帶來巨大幫助：grids.css可以幫你實(shí)現(xiàn)整體布局，font.css和reset.css可以幫助你移除瀏覽器默 認(rèn)格式。它提供了一個(gè)重新審視你頁面中標(biāo)簽的機(jī)會，比如只有在語意上有意義時(shí)才使用<div>，而不是因?yàn)樗哂袚Q行效果才使用它。

DOM元素?cái)?shù)量很容易計(jì)算出來，只需要在Firebug的控制臺內(nèi)輸入：

document.getElementsByTagName(‘*’).length

那么多少個(gè)DOM元素算是多呢？這可以對照有很好標(biāo)記使用的類似頁面。比如Yahoo!主頁是一個(gè)內(nèi)容非常多的頁面，但是它只使用了700個(gè)元素（HTML標(biāo)簽）。

 

 

8、根據(jù)域名劃分頁面內(nèi)容

 

把頁面內(nèi)容劃分成若干部分可以使你最大限度地實(shí)現(xiàn)平行下載。由于DNS查找?guī)淼挠绊懩闶紫纫_保你使用的域名數(shù)量在2個(gè)到4個(gè)之間。例如，你可以把用到 的HTML內(nèi)容和動(dòng)態(tài)內(nèi)容放在www.example.org上，而把頁面各種組件（圖片、腳本、CSS)分別存放在 statics1.example.org和statics.example.org上。

你可在Tenni Theurer和Patty Chi合寫的文章Maximizing Parallel Downloads in the Carpool Lane找到更多相關(guān)信息。

 

 

9、使iframe的數(shù)量最小

 

ifrmae元素可以在父文檔中插入一個(gè)新的HTML文檔。了解iframe的工作理然后才能更加有效地使用它，這一點(diǎn)很重要。

<iframe>優(yōu)點(diǎn)：解決加載緩慢的第三方內(nèi)容如圖標(biāo)和廣告等的加載問題Security sandbox并行加載腳本

<iframe>的缺點(diǎn)：即時(shí)內(nèi)容為空，加載也需要時(shí)間會阻止頁面加載沒有語意

 

 

10、不要出現(xiàn)404錯(cuò)誤

 

HTTP請求時(shí)間消耗是很大的，因此使用HTTP請求來獲得一個(gè)沒有用處的響應(yīng)（例如404沒有找到頁面）是完全沒有必要的，它只會降低用戶體驗(yàn)而不會有一點(diǎn)好處。

有些站點(diǎn)把404錯(cuò)誤響應(yīng)頁面改為“你是不是要找***”，這雖然改進(jìn)了用戶體驗(yàn)但是同樣也會浪費(fèi)服務(wù)器資源（如數(shù)據(jù)庫等）。最糟糕的情況是指向外部 JavaScript的鏈接出現(xiàn)問題并返回404代碼。首先，這種加載會破壞并行加載；其次瀏覽器會把試圖在返回的404響應(yīng)內(nèi)容中找到可能有用的部分當(dāng) 作JavaScript代碼來執(zhí)行。

 

 

二、網(wǎng)站前端性能優(yōu)化之：——服務(wù)器Server篇

使用內(nèi)容分發(fā)網(wǎng)絡(luò)、為文件頭指定Expires或Cache-Control、Gzip壓縮文件內(nèi)容、配置ETag、盡早刷新輸出緩沖、使用GET來完成AJAX請求

 

 

11、使用內(nèi)容分發(fā)網(wǎng)絡(luò)

 

用戶與你網(wǎng)站服務(wù)器的接近程度會影響響應(yīng)時(shí)間的長短。把你的網(wǎng)站內(nèi)容分散到多個(gè)、處于不同地域位置的服務(wù)器上可以加快下載速度。但是首先我們應(yīng)該做些什么呢？

按地域布置網(wǎng)站內(nèi)容的第一步并不是要嘗試重新架構(gòu)你的網(wǎng)站讓他們在分發(fā)服務(wù)器上正常運(yùn)行。根據(jù)應(yīng)用的需求來改變網(wǎng)站結(jié)構(gòu)，這可能會包括一些比較復(fù)雜的任 務(wù)，如在服務(wù)器間同步Session狀態(tài)和合并數(shù)據(jù)庫更新等。要想縮短用戶和內(nèi)容服務(wù)器的距離，這些架構(gòu)步驟可能是不可避免的。

要記住，在終端用戶的響應(yīng)時(shí)間中有80%到90%的響應(yīng)時(shí)間用于下載圖像、樣式表、腳本、Flash等頁面內(nèi)容。這就是網(wǎng)站性能黃金守則。和重新設(shè)計(jì)你的 應(yīng)用程序架構(gòu)這樣比較困難的任務(wù)相比，首先來分布靜態(tài)內(nèi)容會更好一點(diǎn)。這不僅會縮短響應(yīng)時(shí)間，而且對于內(nèi)容分發(fā)網(wǎng)絡(luò)來說它更容易實(shí)現(xiàn)。

 

內(nèi)容分發(fā)網(wǎng)絡(luò)（Content Delivery Network，CDN）是由一系列分散到各個(gè)不同地理位置上的Web服務(wù)器組成的，它提高了網(wǎng)站內(nèi)容的傳輸速度。用于向用戶傳輸內(nèi)容的服務(wù)器主要是根據(jù) 和用戶在網(wǎng)絡(luò)上的靠近程度來指定的。例如，擁有最少網(wǎng)絡(luò)跳數(shù)（network hops）和響應(yīng)速度最快的服務(wù)器會被選定。

一些大型的網(wǎng)絡(luò)公司擁有自己的CDN，但是使用像Akamai Technologies，Mirror Image Internet， 或者Limelight Networks這 樣的CDN服務(wù)成本卻非常高。對于剛剛起步的企業(yè)和個(gè)人網(wǎng)站來說，可能沒有使用CDN的成本預(yù)算，但是隨著目標(biāo)用戶群的不斷擴(kuò)大和更加全球化，CDN就是 實(shí)現(xiàn)快速響應(yīng)所必需的了。以Yahoo來說，他們轉(zhuǎn)移到CDN上的網(wǎng)站程序靜態(tài)內(nèi)容節(jié)省了終端用戶20%以上的響應(yīng)時(shí)間。使用CDN是一個(gè)只需要相對簡單 地修改代碼實(shí)現(xiàn)顯著改善網(wǎng)站訪問速度的方法。

 

 

12、為文件頭指定Expires或Cache-Control 

 

這條守則包括兩方面的內(nèi)容：

對于靜態(tài)內(nèi)容：設(shè)置文件頭過期時(shí)間Expires的值為“Never expire”（永不過期）

對于動(dòng)態(tài)內(nèi)容：使用恰當(dāng)?shù)腃ache-Control文件頭來幫助瀏覽器進(jìn)行有條件的請求

 

網(wǎng)頁內(nèi)容設(shè)計(jì)現(xiàn)在越來越豐富，這就意味著頁面中要包含更多的腳本、樣式表、圖片和Flash。第一次訪問你頁面的用戶就意味著進(jìn)行多次的HTTP請求，但 是通過使用Expires文件頭就可以使這樣內(nèi)容具有緩存性。它避免了接下來的頁面訪問中不必要的HTTP請求。Expires文件頭經(jīng)常用于圖像文件， 但是應(yīng)該在所有的內(nèi)容都使用他，包括腳本、樣式表和Flash等。

瀏覽器（和代理）使用緩存來減少HTTP請求的大小和次數(shù)以加快頁面訪問速度。

Web服務(wù)器在HTTP響應(yīng)中使用Expires文件頭來告訴客戶端內(nèi)容需 要緩存多長時(shí)間。

 

下面這個(gè)例子是一個(gè)較長時(shí)間的Expires文件頭，它告訴瀏覽器這個(gè)響應(yīng)直到2010年4月15日才過期。

Expires: Thu, 15 Apr 2010 20:00:00 GMT 

如果你使用的是Apache服務(wù)器，可以使用ExpiresDefault來設(shè)定相對當(dāng)前日期的過期時(shí)間。

 

下面這個(gè)例子是使用ExpiresDefault來設(shè)定請求時(shí)間后10年過期的文件頭：

ExpiresDefault “access plus 10 years” 

要切記，如果使用了Expires文件頭，當(dāng)頁面內(nèi)容改變時(shí)就必須改變內(nèi)容的文件名。

依Yahoo!來說我們經(jīng)常使用這樣的步驟：在內(nèi)容的文件名中加上版本號，如yahoo_2.0.6.js。

 

使用Expires文件頭只有會在用戶已經(jīng)訪問過你的網(wǎng)站后才會起作用。當(dāng)用戶首次訪問你的網(wǎng)站時(shí)這對減少HTTP請求次數(shù)來說是無效的，因?yàn)闉g覽器的緩 存是空的。因此這種方法對于你網(wǎng)站性能的改進(jìn)情況要依據(jù)他們“預(yù)緩存”存在時(shí)對你頁面的點(diǎn)擊頻率（“預(yù)緩存”中已經(jīng)包含了頁面中的所有內(nèi)容）。Yahoo!建立了一套測量方法，我們發(fā)現(xiàn)所有的頁面瀏覽量中有75~85%都有“預(yù)緩存”。通過使用Expires文件頭，增加了緩存在瀏覽器中內(nèi)容的數(shù)量，并且可以在用戶接下來的請求中再次使用這些內(nèi)容，這甚至都不需要通過用戶發(fā)送一個(gè)字節(jié)的請求。

 

 

13、Gzip壓縮文件內(nèi)容

 

網(wǎng)絡(luò)傳輸中的HTTP請求和應(yīng)答時(shí)間可以通過前端機(jī)制得到顯著改善。的確，終端用戶的帶寬、互聯(lián)網(wǎng)提供者、與對等交換點(diǎn)的靠近程度等都不是網(wǎng)站開發(fā)者所能決定的。但是還有其他因素影響著響應(yīng)時(shí)間。通過減小HTTP響應(yīng)的大小可以節(jié)省HTTP響應(yīng)時(shí)間。

 

從HTTP/1.1開始，web客戶端都默認(rèn)支持HTTP請求中有Accept-Encoding文件頭的壓縮格式：   

Accept-Encoding: gzip, deflate 

如果web服務(wù)器在請求的文件頭中檢測到上面的代碼，就會以客戶端列出的方式壓縮響應(yīng)內(nèi)容。Web服務(wù)器把壓縮方式通過響應(yīng)文件頭中的Content-Encoding來返回給瀏覽器。

Content-Encoding: gzip 

Gzip是目前最流行也是最有效的壓縮方式。這是由GNU項(xiàng)目開發(fā)并通過RFC 1952來標(biāo)準(zhǔn)化的。另外僅有的一個(gè)壓縮格式是deflate，但是它的使用范圍有限效果也稍稍遜色。

Gzip大概可以減少70%的響應(yīng)規(guī)模。目前大約有90%通過瀏覽器傳輸?shù)幕ヂ?lián)網(wǎng)交換支持gzip格式。如果你使用的是Apache，gzip模塊配置和你的版本有關(guān)：Apache 1.3使用mod_zip，而Apache 2.x使用moflate。

 

瀏覽器和代理都會存在這樣的問題：瀏覽器期望收到的和實(shí)際接收到的內(nèi)容會存在不匹配的現(xiàn)象。幸好，這種特殊情況隨著舊式瀏覽器使用量的減少在減少。Apache模塊會通過自動(dòng)添加適當(dāng)?shù)腣ary響應(yīng)文件頭來避免這種狀況的出現(xiàn)。

 

服務(wù)器根據(jù)文件類型來選擇需要進(jìn)行g(shù)zip壓縮的文件，但是這過于限制了可壓縮的文件。大多數(shù)web服務(wù)器會壓縮HTML文檔。對腳本和樣式表進(jìn)行壓縮同 樣也是值得做的事情，但是很多web服務(wù)器都沒有這個(gè)功能。實(shí)際上，壓縮任何一個(gè)文本類型的響應(yīng)，包括XML和JSON，都值得的。圖像和PDF文件由于 已經(jīng)壓縮過了所以不能再進(jìn)行g(shù)zip壓縮。如果試圖gizp壓縮這些文件的話不但會浪費(fèi)CPU資源還會增加文件的大小。

 

Gzip壓縮所有可能的文件類型是減少文件體積增加用戶體驗(yàn)的簡單方法。 

 

14、配置ETag 

 

Entity tags（ETags）（實(shí)體標(biāo)簽）是web服務(wù)器和瀏覽器用于判斷瀏覽器緩存中的內(nèi)容和服務(wù)器中的原始內(nèi)容是否匹配的一種機(jī)制（“實(shí)體”就是所說的“內(nèi) 容”，包括圖片、腳本、樣式表等）。增加ETag為實(shí)體的驗(yàn)證提供了一個(gè)比使用“last-modified date（上次編輯時(shí)間）”更加靈活的機(jī)制。Etag是一個(gè)識別內(nèi)容版本號的唯一字符串。唯一的格式限制就是它必須包含在雙引號內(nèi)。原始服務(wù)器通過含有 ETag文件頭的響應(yīng)指定頁面內(nèi)容的ETag。 

HTTP/1.1 200 OK

Last-Modified: Tue, 12 Dec 2006 03:03:59 GMT

ETag: “10c24bc-4ab-457e1c1f”

Content-Length: 12195

 

稍后，如果瀏覽器要驗(yàn)證一個(gè)文件，它會使用If-None-Match文件頭來把ETag傳回給原始服務(wù)器。

在這個(gè)例子中，如果ETag匹配，就會返回一 個(gè)304狀態(tài)碼，這就節(jié)省了12195字節(jié)的響應(yīng)。

GET /i/yahoo.gif HTTP/1.1

Host: us.yimg.com

If-Modified-Since: Tue, 12 Dec 2006 03:03:59 GMT

If-None-Match: “10c24bc-4ab-457e1c1f”

HTTP/1.1 304 Not Modified

 

ETag的問題在于，它是根據(jù)可以辨別網(wǎng)站所在的服務(wù)器的具有唯一性的屬性來生成的。當(dāng)瀏覽器從一臺服務(wù)器上獲得頁面內(nèi)容后到另外一臺服務(wù)器上進(jìn)行驗(yàn)證時(shí) ETag就會不匹配，這種情況對于使用服務(wù)器組和處理請求的網(wǎng)站來說是非常常見的。默認(rèn)情況下，Apache和IIS都會把數(shù)據(jù)嵌入ETag中，這會顯著 減少多服務(wù)器間的文件驗(yàn)證沖突。

 

Apache 1.3和2.x中的ETag格式為inode-size-timestamp。即使某個(gè)文件在不同的服務(wù)器上會處于相同的目錄下，文件大小、權(quán)限、時(shí)間戳等都完全相同，但是在不同服務(wù)器上他們的內(nèi)碼也是不同的。 

 

IIS 5.0和IIS 6.0處理ETag的機(jī)制相似。IIS中的ETag格式為Filetimestamp:ChangeNumber。用ChangeNumber來跟蹤 IIS配置的改變。網(wǎng)站所用的不同IIS服務(wù)器間ChangeNumber也不相同。 不同的服務(wù)器上的Apache和IIS即使對于完全相同的內(nèi)容產(chǎn)生的ETag在也不相同，用戶并不會接收到一個(gè)小而快的304響應(yīng)；相反他們會接收一個(gè)正 常的200響應(yīng)并下載全部內(nèi)容。如果你的網(wǎng)站只放在一臺服務(wù)器上，就不會存在這個(gè)問題。但是如果你的網(wǎng)站是架設(shè)在多個(gè)服務(wù)器上，并且使用Apache和 IIS產(chǎn)生默認(rèn)的ETag配置，你的用戶獲得頁面就會相對慢一點(diǎn)，服務(wù)器會傳輸更多的內(nèi)容，占用更多的帶寬，代理也不會有效地緩存你的網(wǎng)站內(nèi)容。即使你的 內(nèi)容擁有Expires文件頭，無論用戶什么時(shí)候點(diǎn)擊“刷新”或者“重載”按鈕都會發(fā)送相應(yīng)的GET請求。

 

如果你沒有使用ETag提供的靈活的驗(yàn)證模式，那么干脆把所有的ETag都去掉會更好。Last-Modified文件頭驗(yàn)證是基于內(nèi)容的時(shí)間戳的。去掉ETag文件頭會減少響應(yīng)和下次請求中文件的大小。微軟的這篇支持文稿講述了如何去掉ETag。在Apache中，只需要在配置文件中簡單添加下面一行代碼就可以了：

FileETag none 

 

 

15、盡早刷新輸出緩沖

 

當(dāng)用戶請求一個(gè)頁面時(shí)，無論如何都會花費(fèi)200到500毫秒用于后臺組織HTML文件。在這期間，瀏覽器會一直空閑等待數(shù)據(jù)返回。在PHP中，你可以使用 flush()方法，它允許你把已經(jīng)編譯的好的部分HTML響應(yīng)文件先發(fā)送給瀏覽器，這時(shí)瀏覽器就會可以下載文件中的內(nèi)容（腳本等）而后臺同時(shí)處理剩余的 HTML頁面。這樣做的效果會在后臺煩惱或者前臺較空閑時(shí)更加明顯。

 

輸出緩沖應(yīng)用最好的一個(gè)地方就是緊跟在<head />之后，因?yàn)镠TML的頭部分容易生成而且頭部往往包含CSS和JavaScript文件，這樣瀏覽器就可以在后臺編譯剩余HTML的同時(shí)并行下載它們。

例子： 

… <!– css, js –>

</head>

<?php flush(); ?>

<body>

… <!– content –>

為了證明使用這項(xiàng)技術(shù)的好處，，Yahoo!搜索率先研究并完成了用戶測試。 

 

 

16、使用GET來完成AJAX請求

 

Yahoo!Mail團(tuán) 隊(duì)發(fā)現(xiàn)，當(dāng)使用XMLHttpRequest時(shí)，瀏覽器中的POST方法是一個(gè)“兩步走”的過程：首先發(fā)送文件頭，然后才發(fā)送數(shù)據(jù)。因此使用GET最為恰 當(dāng)，因?yàn)樗恍璋l(fā)送一個(gè)TCP包（除非你有很多cookie）。IE中URL的最大長度為2K，因此如果你要發(fā)送一個(gè)超過2K的數(shù)據(jù)時(shí)就不能使用GET 了。

 

一個(gè)有趣的不同就是POST并不像GET那樣實(shí)際發(fā)送數(shù)據(jù)。根據(jù)HTTP規(guī)范，GET意味著“獲取”數(shù)據(jù)，因此當(dāng)你僅僅獲取數(shù)據(jù)時(shí)使用GET更加有意義（從語意上講也是如此），相反，發(fā)送并在服務(wù)端保存數(shù)據(jù)時(shí)使用POST。