Yahoo團隊經驗：網站效能最佳化的34條黃金法則

標籤：條件   http請求   網路傳輸   地方   menu   frame   顯示圖片   大網   工具   

Yahoo團隊總結的關於網站效能最佳化的經驗，非常有參考價值。
英文原文：http://developer.yahoo.com/performance/rules.html

1、盡量減少HTTP請求次數

終端使用者響應的時間中，有80%用於下載各項內容。這部分時間包括下載頁面中的映像、樣式表、指令碼、Flash等。通過減少頁面中的元素可以減少 HTTP請求的次數。這是提高網頁速度的關鍵步驟。
減少頁面組件的方法其實就是簡化頁面設計。那麼有沒有一種方法既能保持頁面內容的豐富性又能達到加快回應時間的目的呢？這裡有幾條減少HTTP請求次數同時又可能保持頁面內容豐富的技術。
合并檔案是通過把所有的指令碼放到一個檔案中來減少HTTP請求的方法，如可以簡單地把所有的CSS檔案都放入一個樣式表中。當指令碼或者樣式表在不同頁面中使用時需要做不同的修改，這可能會相對麻煩點，但即便如此也要把這個方法作為改善頁面效能的重要一步。
CSS Sprites是減少映像請求的有效方法。把所有的背景映像都放到一個圖片檔案中，然後通過CSS的background-image和 background-position屬性來顯示圖片的不同部分；
圖片地圖是把多張圖片整合到一張圖片中。雖然檔案的總體大小不會改變，但是可以減少HTTP請求次數。圖片地圖只有在圖片的所有組成部分在頁面中是緊挨在 一起的時候才能使用，如導覽列。確定圖片的座標和可能會比較繁瑣且容易出錯，同時使用圖片地圖導航也不具有可讀性，因此不推薦這種方法；
內嵌影像是使用data:URL scheme的方法把映像資料載入頁面中。這可能會增加頁面的大小。把內嵌影像放到樣式表（可緩衝）中可以減少HTTP請求同時又避免增加分頁檔的大小。但是內嵌影像現在還沒有得到主流瀏覽器的支援。
減少頁面的HTTP請求次數是你首先要做的一步。這是改進首次訪問使用者等待時間的最重要的方法。如同Tenni Theurer的他的部落格Browser Cahe Usage – Exposed!中所說，HTTP請求在無緩衝情況下佔去了40%到60%的回應時間。讓那些初次訪問你網站的人獲得更加快速的體驗吧！

2、減少DNS尋找次數

網域名稱系統（DNS）提供了網域名稱和IP的對應關係，就像電話本中人名和他們的電話號碼的關係一樣。當你在瀏覽器地址欄中輸入www.dudo.org 時，DNS解析伺服器就會返回這個網域名稱對應的IP地址。DNS解析的過程同樣也是需要時間的。一般情況下返回給定網域名稱對應的IP地址會花費20到120毫秒的時間。而且在這個過程中瀏覽器什麼都不會做直到DNS尋找完畢。
緩衝DNS尋找可以改善頁面效能。這種緩衝需要一個特定的快取服務器，這種伺服器一般屬於使用者的ISP供應商或者本地區域網路控制，但是它同樣會在使用者使用 的電腦上產生緩衝。DNS資訊會保留在作業系統的DNS緩衝中（微軟Windows系統中DNS Client Service）。大多數瀏覽器有獨立於作業系統以外的自己的緩衝。由於瀏覽器有自己的緩衝記錄，因此在一次請求中它不會受到作業系統的影響。
Internet Explorer預設情況下對DNS尋找記錄的緩衝時間為30分鐘，它在註冊表中的索引值為DnsCacheTimeout。Firefox對DNS的尋找 記錄緩衝時間為1分鐘，它在設定檔中的選項為network.dnsCacheExpiration（Fasterfox把這個選項改為了1小時）。
當用戶端中的DNS緩衝都為空白時（瀏覽器和作業系統都為空白），DNS尋找的次數和頁面中主機名稱的數量相同。這其中包括頁面中URL、圖片、指令檔、樣式表、Flash對象等包含的主機名稱。減少主機名稱的數量可以減少DNS尋找次數。
減少主機名稱的數量還可以減少頁面中並行下載的數量。減少DNS尋找次數可以節省回應時間，但是減少並行下載卻會增加回應時間。我的指導原則是把這些頁面中 的內容分割成至少兩部分但不超過四部分。這種結果就是在減少DNS尋找次數和保持較高程度並行下載兩者之間的權衡了。

3、避免跳轉

跳轉是使用301和302代碼實現的。下面是一個響應代碼為301的HTTP頭：
HTTP/1.1 301 Moved Permanently
Location: http://example.com/newuri
Content-Type: text/html
瀏覽器會把使用者指向到Location中指定的URL。標頭檔中的所有資訊在一次跳轉中都是必需的，內容部分可以為空白。不管他們的名稱，301和302 響應都不會被緩衝除非增加一個額外的頭選項，如Expires或者Cache-Control來指定它緩衝。<meat />元素的重新整理標籤和JavaScript也可以實現URL的跳轉，但是如果你必須要跳轉的時候，最好的方法就是使用標準的3XXHTTP狀態代 碼，這主要是為了確保[上一頁] 按鈕可以正確地使用。
但是要記住跳轉會降低使用者體驗。在使用者和HTML文檔中間增加一個跳轉，會拖延頁面中所有元素的顯示，因為在HTML檔案被載入前任何檔案（映像、 Flash等）都不會被下載。
有一種經常被網頁開發人員忽略卻往往十分浪費回應時間的跳轉現象。這種現象發生在當URL本該有斜杠（/）卻被忽略掉時。例如，當我們要訪問http: //astrology.yahoo.com/astrology 時，實際上返回的是一個包含301代碼的跳轉，它指向的是http://astrology.yahoo.com/astrology/ （注意末尾的斜杠）。在Apache伺服器中可以使用Alias 或者 mod_rewrite或者the DirectorySlash來避免。
串連新網站和舊網站是跳轉功能經常被用到的另一種情況。這種情況下往往要串連網站的不同內容然後根據使用者的不同類型（如瀏覽器類型、使用者帳號所屬類型）來 進行跳轉。使用跳轉來實現兩個網站的切換十分簡單，需要的代碼量也不多。儘管使用這種方法對於開發人員來說可以降低複雜程度，但是它同樣降低使用者體驗。一個 可替代方法就是如果兩者在同一台伺服器上時使用Alias和mod_rewrite和實現。如果是因為網域名稱的不同而採用跳轉，那麼可以通過使用 Alias或者mod_rewirte建立CNAME（儲存一個網域名稱和另外一個網域名稱之間關係的DNS記錄）來替代。

4、可快取的AJAX

Ajax經常被提及的一個好處就是由於其從後台伺服器傳輸資訊的非同步性而為使用者帶來的反饋的即時性。但是，使用Ajax並不能保證使用者不會在等待非同步 JavaScript和XML響應上花費時間。在很多應用中，使用者是否需要等待響應取決於Ajax如何來使用。例如，在一個基於Web的Email用戶端 中，使用者必須等待Ajax返回符合他們條件的郵件查詢結果。記住一點，“非同步”並不異味著“即時”，這很重要。
為了提高效能，最佳化Ajax響應是很重要的。提高Ajxa效能的措施中最重要的方法就是使響應具有可緩衝性，具體的討論可以查看Add an Expires or a Cache-Control Header。其它的幾條規則也同樣適用於Ajax：
Gizp壓縮檔
減少DNS尋找次數
精簡JavaScript
避免跳轉
配置ETags
讓我們來看一個例子：一個Web2.0的Email用戶端會使用Ajax來自動完成對使用者地址薄的下載。如果使用者在上次使用過Email web應用程式後沒有對地址薄作任何的修改，而且Ajax響應通過Expire或者Cacke-Control頭來實現緩衝，那麼就可以直接從上一次的緩衝中讀取地址薄了。必須告知瀏覽器是使用緩衝中的地址薄還是發送一個新的請求。這可以通過為讀取地址薄的Ajax URL增加一個含有上次編輯時間的時間戳記來實現，例如，&t=11900241612等。如果地址薄在上次下載後沒有被編輯過，時間戳記就不變，則從瀏覽器的緩衝中載入從而減少了一次HTTP請求過程。如果使用者修改過地址薄，時間戳記就會用來確定新的URL和緩衝響應並不匹配，瀏覽器就會重要請求更新地址薄。

即使你的Ajxa響應是動態產生的，哪怕它只適用於一個使用者，那麼它也應該被緩衝起來。這樣做可以使你的Web2.0應用程式更加快捷。

5、延後載入內容

你可以仔細看一下你的網頁，問問自己“哪些內容是頁面呈現時所必需首先載入的？哪些內容和結構可以稍後再載入？
把整個過程按照onload事件分隔成兩部分，JavaScript是一個理想的選擇。例如，如果你有用於實現拖放和動畫的JavaScript，那麼它 就以等待稍後載入，因為頁面上的拖放元素是在初始化呈現之後才發生的。其它的例如隱藏部分的內容（使用者操作之後才顯現的內容）和處於摺疊部分的映像也可以 延後載入
工具可以節省你的工作量：YUI Image Loader可以幫你延後載入摺疊部分的圖片，YUI Get utility是包含JS和 CSS的便捷方法。比如你可以開啟Firebug的Net選項卡看一下Yahoo的首頁。
當效能目標和其它網站開發實踐一致時就會相得益彰。這種情況下，通過程式提高網站效能的方法告訴我們，在支援JavaScript的情況下，可以先去除用 戶體驗，不過這要保證你的網站在沒有JavaScript也可以正常運行。在確定頁面運行正常後，再載入指令碼來實現如拖放和動畫等更加花哨的效果。

6、預先載入

預先載入和後載入看起來似乎恰恰相反，但實際上預先載入是為了實現另外一種目標。預先載入是在瀏覽器空閑時請求將來可能會用到的頁面內容（像、樣式表和腳 本）。使用這種方法，當使用者要訪問下一個頁面時，頁面中的內容大部分已經載入到緩衝中了，因此可以大大改善訪問速度。
下面提供了幾種預先載入方法：
無條件載入：觸發onload事件時，直接載入額外的頁面內容。以Google.com為例，你可以看一下它的spirit image映像是怎樣在onload中載入的。這個spirit image映像在google.com首頁中是不需要的，但是卻可以在搜尋結果頁面中用到它。
有條件載入：根據使用者的操作來有根據地判斷使用者下面可能去往的頁面並相應的預先載入頁面內容。在search.yahoo.com中你可以看到如何在你輸入內容時載入額外的頁面內容。
有預期的載入：載入重新設計過的頁面時使用預先載入。這種情況經常出現在頁面經過重新設計後使用者抱怨“新的頁面看起來很酷，但是卻比以前慢”。問題可能出在 使用者對於你的舊網站建立了完整的緩衝，而對於新網站卻沒有任何緩衝內容。因此你可以在訪問新站之前就載入一部內容來避免這種結果的出現。在你的舊站中利用 瀏覽器的空餘時間載入新站中用到的映像的和指令碼來提高訪問速度。

7、減少DOM元素數量

一個複雜的頁面意味著需要下載更多資料，同時也意味著JavaScript遍曆DOM的效率越慢。比如當你增加一個事件控制代碼時在500和5000個 DOM元素中迴圈效果肯定是不一樣的。
大量的DOM元素的存在意味著頁面中有可以不用移除內容只需要替換元素標籤就可以精簡的部分。你在頁面配置中使用表格了嗎？你有沒有僅僅為了布局而引入更多的<div>元素呢？也許會存在一個適合或者在語意是更貼切的標籤可以供你使用。
YUI CSS utilities可以給你的布局帶來巨大協助：grids.css可以幫你實現整體布局，font.css和reset.css可以協助你移除瀏覽器默 認格式。它提供了一個重新審視你頁面中標籤的機會，比如只有在語意上有意義時才使用<div>，而不是因為它具有換行效果才使用它。
DOM元素數量很容易計算出來，只需要在Firebug的控制台內輸入：
document.getElementsByTagName(‘*’).length
那麼多少個DOM元素算是多呢？這可以對照有很好標記使用的類似頁面。比如Yahoo!首頁是一個內容非常多的頁面，但是它只使用了700個元素（HTML標籤）。

8、根據網域名稱劃分頁面內容

把頁面內容劃分成若干部分可以使你最大限度地實現平行下載。由於DNS尋找帶來的影響你首先要確保你使用的網域名稱數量在2個到4個之間。例如，你可以把用到的HTML內容和動態內容放在www.example.org上，而把頁面各種組件（圖片、指令碼、CSS)分別存放在 statics1.example.org和statics.example.org上。
你可在Tenni Theurer和Patty Chi合寫的文章Maximizing Parallel Downloads in the Carpool Lane找到更多相關資訊。

9、使iframe的數量最小

ifrmae元素可以在父文檔中插入一個新的HTML文檔。瞭解iframe的工作理然後才能更加有效地使用它，這一點很重要。
<iframe>優點：

• 解決載入緩慢的第三方內容標和廣告等的載入問題
• Security sandbox
• 並行載入指令碼

<iframe>的缺點：

• 即時內容為空白，載入也需要時間
• 會阻止頁面載入
• 沒有語意

10、不要出現404錯誤

HTTP請求時間消耗是很大的，因此使用HTTP請求來獲得一個沒有用處的響應（例如404沒有找到頁面）是完全沒有必要的，它只會降低使用者體驗而不會有一點好處。
有些網站把404錯誤響應頁面改為“你是不是要找***”，這雖然改進了使用者體驗但是同樣也會浪費伺服器資源（如資料庫等）。最糟糕的情況是指向外部 JavaScript的連結出現問題並返回404代碼。首先，這種載入會破壞並行載入；其次瀏覽器會把試圖在返回的404響應內容中找到可能有用的部分當 作JavaScript代碼來執行。

11、使用內容分髮網絡

使用者與你網站伺服器的接近程度會影響回應時間的長短。把你的網站內容分散到多個、處於不同地區位置的伺服器上可以加快下載速度。但是首先我們應該做些什麼呢？
按地區布置網站內容的第一步並不是要嘗試重新架構你的網站讓他們在散發者上正常運行。根據應用的需求來改變網站結構，這可能會包括一些比較複雜的任 務，如在伺服器間同步Session狀態和合并資料庫更新等。要想縮短使用者和內容伺服器的距離，這些架構步驟可能是不可避免的。
要記住，在終端使用者的回應時間中有80%到90%的回應時間用於下載映像、樣式表、指令碼、Flash等頁面內容。這就是網站效能黃金規則。和重新設計你的 應用程式架構這樣比較困難的任務相比，首先來分布靜態內容會更好一點。這不僅會縮短回應時間，而且對於內容分髮網絡來說它更容易實現。
內容分髮網絡（Content Delivery Network，CDN）是由一系列分散到各個不同地理位置上的Web伺服器組成的，它提高了網站內容的傳輸速度。用於向使用者傳輸內容的伺服器主要是根據 和使用者在網路上的靠近程度來指定的。例如，擁有最少網路跳數（network hops）和響應速度最快的伺服器會被選定。
一些大型的網路公司擁有自己的CDN，但是使用像Akamai Technologies，Mirror Image Internet， 或者Limelight Networks這樣的CDN服務成本卻非常高。對於剛剛起步的企業和個人網站來說，可能沒有使用CDN的成本預算，但是隨著目標使用者群的不斷擴大和更加 全球化，CDN就是實現快速響應所必需的了。以Yahoo來說，他們轉移到CDN上的網站程式靜態內容節省了終端使用者20%以上的回應時間。使用CDN是 一個只需要相對簡單地修改代碼實現顯著改善網站訪問速度的方法。

12、為檔案頭指定Expires或Cache-Control

這條規則包括兩方面的內容：
對於靜態內容：設定檔案頭到期時間Expires的值為“Never expire”（永不到期）
對於動態內容：使用恰當的Cache-Control檔案頭來協助瀏覽器進行有條件的請求
網頁內容設計現在越來越豐富，這就意味著頁面中要包含更多的指令碼、樣式表、圖片和Flash。第一次訪問你頁面的使用者就意味著進行多次的HTTP請求，但 是通過使用Expires檔案頭就可以使這樣內容具有緩衝性。它避免了接下來的頁面訪問中不必要的HTTP請求。Expires檔案頭經常用於影像檔， 但是應該在所有的內容都使用他，包括指令碼、樣式表和Flash等。
瀏覽器（和代理）使用緩衝來減少HTTP請求的大小和次數以加快頁面訪問速度。Web伺服器在HTTP響應中使用Expires檔案頭來告訴用戶端內容需 要緩衝多長時間。下面這個例子是一個較長時間的Expires檔案頭，它告訴瀏覽器這個響應直到2010年4月15日才到期。
Expires: Thu, 15 Apr 2010 20:00:00 GMT
如果你使用的是Apache伺服器，可以使用ExpiresDefault來設定相對當前日期的到期時間。下面這個例子是使用 ExpiresDefault來設定請求時間後10年到期的檔案頭：
ExpiresDefault “access plus 10 years”
要切記，如果使用了Expires檔案頭，當頁面內容改變時就必須改變內容的檔案名稱。依Yahoo!來說我們經常使用這樣的步驟：在內容的檔案名稱中加上版本號碼，如yahoo_2.0.6.js。
使用Expires檔案頭只有會在使用者已經訪問過你的網站後才會起作用。當使用者首次訪問你的網站時這對減少HTTP請求次數來說是無效的，因為瀏覽器的緩 存是空的。因此這種方法對於你網站效能的改進情況要依據他們“預緩衝”存在時對你頁面的點擊頻率（“預緩衝”中已經包含了頁面中的所有內容）。 Yahoo!建立了一套測量方法，我們發現所有的頁面瀏覽量中有75~85%都有“預緩衝”。通過使用Expires檔案頭，增加了緩衝在瀏覽器中內容的 數量，並且可以在使用者接下來的請求中再次使用這些內容，這甚至都不需要通過使用者發送一個位元組的請求。

13、Gzip壓縮檔內容

網路傳輸中的HTTP請求和應答時間可以通過前端機製得到顯著改善。的確，終端使用者的頻寬、互連網提供者、與對等交換點的靠近程度等都不是網站開發人員所能決定的。但是還有其他因素影響著回應時間。通過減小HTTP響應的大小可以節省HTTP回應時間。
從HTTP/1.1開始，web用戶端都預設支援HTTP請求中有Accept-Encoding檔案頭的壓縮格式：
Accept-Encoding: gzip, deflate
如果web伺服器在請求的檔案頭中檢測到上面的代碼，就會以用戶端列出的方式壓縮響應內容。Web伺服器把壓縮方式通過回應檔頭中的Content- Encoding來返回給瀏覽器。
Content-Encoding: gzip
Gzip是目前最流行也是最有效壓縮方式。這是由GNU項目開發並通過RFC 1952來標準化的。另外僅有的一個壓縮格式是deflate，但是它的使用範圍有限效果也稍稍遜色。
Gzip大概可以減少70%的響應規模。目前大約有90%通過瀏覽器傳輸的互連網交換支援gzip格式。如果你使用的是Apache，gzip模組配置和你的版本有關：Apache 1.3使用mod_zip，而Apache 2.x使用moflate。
瀏覽器和代理都會存在這樣的問題：瀏覽器期望收到的和實際接收到的內容會存在不匹配的現象。幸好，這種特殊情況隨著舊式瀏覽器使用量的減少在減少。 Apache模組會通過自動添加適當的Vary回應檔頭來避免這種狀況的出現。
伺服器根據檔案類型來選擇需要進行gzip壓縮的檔案，但是這過於限制了可壓縮的檔案。大多數web伺服器會壓縮HTML文檔。對指令碼和樣式表進行壓縮同 樣也是值得做的事情，但是很多web伺服器都沒有這個功能。實際上，壓縮任何一個文本類型的響應，包括XML和JSON，都值得的。映像和PDF檔案由於 已經壓縮過了所以不能再進行gzip壓縮。如果試圖gizp壓縮這些檔案的話不但會浪費CPU資源還會增加檔案的大小。
Gzip壓縮所有可能的檔案類型是減少檔案體積增加使用者體驗的簡單方法。

14、配置ETag

Entity tags（ETags）（實體標籤）是web伺服器和瀏覽器用於判斷瀏覽器緩衝中的內容和伺服器中的原始內容是否匹配的一種機制（“實體”就是所說的“內 容”，包括圖片、指令碼、樣式表等）。增加ETag為實體的驗證提供了一個比使用“last-modified date（上次編輯時間）”更加靈活的機制。Etag是一個識別內容版本號碼的唯一字串。唯一的格式限制就是它必須包含在雙引號內。原始伺服器通過含有 ETag檔案頭的響應指定頁面內容的ETag。
HTTP/1.1 200 OK
Last-Modified: Tue, 12 Dec 2006 03:03:59 GMT
ETag: “10c24bc-4ab-457e1c1f”
Content-Length: 12195
稍後，如果瀏覽器要驗證一個檔案，它會使用If-None-Match檔案頭來把ETag傳回給原始伺服器。在這個例子中，如果ETag匹配，就會返回一 個304狀態代碼，這就節省了12195位元組的響應。 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的問題在於，它是根據可以辨別網站所在的伺服器的具有唯一性的屬性來產生的。當瀏覽器從一台伺服器上獲得頁面內容後到另外一台伺服器上進行驗證時 ETag就會不匹配，這種情況對於使用伺服器組和處理請求的網站來說是非常常見的。預設情況下，Apache和IIS都會把資料嵌入ETag中，這會顯著 減少多伺服器間的檔案驗證衝突。
Apache 1.3和2.x中的ETag格式為inode-size-timestamp。即使某個檔案在不同的伺服器上會處於相同的目錄下，檔案大小、許可權、時間戳記等都完全相同，但是在不同伺服器上他們的內碼也是不同的。
IIS 5.0和IIS 6.0處理ETag的機制相似。IIS中的ETag格式為Filetimestamp:ChangeNumber。用ChangeNumber來跟蹤 IIS配置的改變。網站所用的不同IIS伺服器間ChangeNumber也不相同。 不同的伺服器上的Apache和IIS即使對於完全相同的內容產生的ETag在也不相同，使用者並不會接收到一個小而快的304響應；相反他們會接收一個正 常的200響應並下載全部內容。如果你的網站只放在一台伺服器上，就不會存在這個問題。但是如果你的網站是架設在多個伺服器上，並且使用Apache和 IIS產生預設的ETag配置，你的使用者獲得頁面就會相對慢一點，伺服器會傳輸更多的內容，佔用更多的頻寬，代理也不會有效地緩衝你的網站內容。即使你的 內容擁有Expires檔案頭，無論使用者什麼時候點擊“重新整理”或者“重載”按鈕都會發送相應的GET請求。
如果你沒有使用ETag提供的靈活的驗證模式，那麼乾脆把所有的ETag都去掉會更好。Last-Modified檔案頭驗證是基於內容的時間戳記的。去掉 ETag檔案頭會減少響應和下次請求中檔案的大小。微軟的這篇支援文稿講述了如何去掉ETag。在Apache中，只需要在設定檔中簡單添加下面一行代 碼就可以了：
FileETag none

15、儘早重新整理輸出緩衝

當使用者請求一個頁面時，無論如何都會花費200到500毫秒用於後台組織HTML檔案。在這期間，瀏覽器會一直空閑等待資料返回。在PHP中，你可以使用 flush()方法，它允許你把已經編譯的好的部分HTML回應檔先發送給瀏覽器，這時瀏覽器就會可以下載檔案中的內容（指令碼等）而後台同時處理剩餘的 HTML頁面。這樣做的效果會在後台煩惱或者前台較空閑時更加明顯。
輸出緩衝應用最好的一個地方就是緊跟在<head />之後，因為HTML的頭部分容易產生而且頭部往往包含CSS和JavaScript檔案，這樣瀏覽器就可以在背景編譯剩餘HTML的同時並行下載它們。 例子：
… <!– css, js –>
</head>

<body>
… <!– content –>

為了證明使用這項技術的好處，Yahoo!搜尋率先研究並完成了使用者測試。

16、使用GET來完成AJAX請求

Yahoo!Mail團隊發現，當使用XMLHttpRequest時，瀏覽器中的POST方法是一個“兩步走”的過程：首先傳送檔案頭，然後才發送數 據。因此使用GET最為恰當，因為它只需發送一個TCP包（除非你有很多cookie）。IE中URL的最大長度為2K，因此如果你要發送一個超過2K的 資料時就不能使用GET了。
一個有趣的不同就是POST並不像GET那樣實際發送資料。根據HTTP規範，GET意味著“擷取”資料，因此當你僅僅擷取資料時使用GET更加有意義（從語意上講也是如此），相反，發送並在服務端儲存資料時使用POST。

17、把樣式表置於頂部

在研究Yahoo!的效能表現時，我們發現把樣式表放到文檔的<head />內部似乎會加快頁面的下載速度。這是因為把樣式表放到<head />內會使頁面有步驟的載入顯示。
注重效能的前端伺服器往往希望頁面有秩序地載入。同時，我們也希望瀏覽器把已經接收到內容儘可能顯示出來。這對於擁有較多內容的頁面和網速較慢的使用者來說 特別重要。向使用者返回可視化的反饋，比如進程指標，已經有了較好的研究並形成了正式文檔。在我們的研究中HTML頁面就是進程指標。當瀏覽器有序地載入文 件頭、導覽列、頂部的logo等對於等待頁面載入的使用者來說都可以作為可視化的反饋。這從整體上改善了使用者體驗。
把樣式表放在文檔底部的問題是在包括Internet Explorer在內的很多瀏覽器中這會中止內容的有序呈現。瀏覽器中止呈現是為了避免樣式改變引起的頁面元素重繪。使用者不得不面對一個空白頁面。
HTML規範清楚指出樣式表要放包含在頁面的<head />地區內：“和<a />不同，<link />只能出現在文檔的<head />地區內，儘管它可以多次使用它”。無論是引起白屏還是出現沒有樣式化的內容都不值得去嘗試。最好的方案就是按照HTML規範在文 檔<head />內載入你的樣式表。

18、避免使用CSS運算式（Expression）

CSS運算式是動態設定CSS屬性的強大（但危險）方法。Internet Explorer從第5個版本開始支援CSS運算式。下面的例子中，使用CSS運算式可以實現隔一個小時切換一次背景顏色：

如上所示，expression中使用了JavaScript運算式。CSS屬性根據JavaScript運算式的計算結果來設定。 expression方法在其它瀏覽器中不起作用，因此在跨瀏覽器的設計中單獨針對Internet Explorer設定時會比較有用。
運算式的問題就在於它的計算頻率要比我們想象的多。不僅僅是在頁面顯示和縮放時，就是在頁面滾動、乃至移動滑鼠時都會要重新計算一次。給CSS運算式增加一個計數器可以跟蹤運算式的計算頻率。在頁面中隨便移動滑鼠都可以輕鬆達到10000次以上的計算量。
一個減少CSS運算式計算次數的方法就是使用一次性的運算式，它在第一次運行時將結果賦給指定的樣式屬性，並用這個屬性來代替CSS運算式。如果樣式屬性 必須在頁面周期內動態地改變，使用事件控制代碼來代替CSS運算式是一個可行辦法。如果必須使用CSS運算式，一定要記住它們要計算成千上萬次並且可能會對你 頁面的效能產生影響。

19、使用外部JavaScript和CSS

很多效能規則都是關於如何處理外部檔案的。但是，在你採取這些措施前你可能會問到一個更基本的問題：JavaScript和CSS是應該放在外部檔案中呢還是把它們放在頁面本身之內呢？
在實際應用中使用外部檔案可以提高頁面速度，因為JavaScript和CSS檔案都能在瀏覽器中產生緩衝。內建在HTML文檔中的 JavaScript和CSS則會在每次請求中隨HTML文檔重新下載。這雖然減少了HTTP請求的次數，卻增加了HTML文檔的大小。從另一方面來說， 如果外部檔案中的JavaScript和CSS被瀏覽器緩衝，在沒有增加HTTP請求次數的同時可以減少HTML文檔的大小。
關鍵問題是，外部JavaScript和CSS檔案快取的頻率和請求HTML文檔的次數有關。雖然有一定的難度，但是仍然有一些指標可以一測量它。如果一 個會話中使用者會瀏覽你網站中的多個頁面，並且這些頁面中會重複使用相同的指令碼和樣式表，緩衝外部檔案就會帶來更大的益處。
許多網站沒有功能建立這些指標。對於這些網站來說，最好的堅決方法就是把JavaScript和CSS作為外部檔案引用。比較適合使用內建代碼的例外就是 網站的首頁，如Yahoo!首頁和My Yahoo!。首頁在一次會話中擁有較少（可能只有一次）的瀏覽量，你可以發現內建JavaScript和CSS對於終端使用者來說會加快響應時 間。
對於擁有較大瀏覽量的首頁來說，有一種技術可以平衡內建代碼帶來的HTTP請求減少與通過使用外部檔案進行緩衝帶來的好處。其中一個就是在首頁中內建 JavaScript和CSS，但是在頁面下載完成後動態下載外部檔案，在子頁面中使用到這些檔案時，它們已經緩衝到瀏覽器了。

20、削減JavaScript和CSS

精簡是指從去除代碼不必要的字元減少檔案大小從而節省下載時間。消減代碼時，所有的注釋、不需要的空白字元（空格、換行、tab縮排）等都要去掉。在 JavaScript中，由於需要下載的檔案體積變小了從而節省了回應時間。精簡JavaScript中目前用到的最廣泛的兩個工具是JSMin和YUI Compressor。YUI Compressor還可用於精簡CSS。
混淆是另外一種可用於原始碼最佳化的方法。這種方法要比精簡複雜一些並且在混淆的過程更易產生問題。在對美國前10大網站的調查中發現，精簡也可以縮小原來 代碼體積的21%，而混淆可以達到25%。儘管混淆法可以更好地縮減代碼，但是對於JavaScript來說精簡的風險更小。
除消減外部的指令碼和樣式表檔案外，<script>和<style>代碼塊也可以並且應該進行消減。即使你用Gzip壓縮過指令碼 和樣式表，精簡這些檔案仍然可以節省5%以上的空間。由於JavaScript和CSS的功能和體積的增加，消減代碼將會獲得益處。

21、用<link>代替@import

前面的最佳實現中提到CSS應該放置在頂端以利於有序載入呈現。
在IE中，頁面底部@import和使用<link>作用是一樣的，因此最好不要使用它。

22、避免使用濾鏡

IE專屬屬性AlphaImageLoader用於修正7.0以下版本中顯示PNG圖片的半透明效果。這個濾鏡的問題在於瀏覽器載入圖片時它會終止內容的 呈現並且凍結瀏覽器。在每一個元素（不僅僅是圖片）它都會運算一次，增加了記憶體開支，因此它的問題是多方面的。
完全避免使用AlphaImageLoader的最好方法就是使用PNG8格式來代替，這種格式能在IE中很好地工作。如果你確實需要使用 AlphaImageLoader，請使用底線_filter又使之對IE7以上版本的使用者無效。

23、把指令碼置於頁面底部

指令碼帶來的問題就是它阻止了頁面的平行下載。HTTP/1.1 規範建議，瀏覽器每個主機名稱的並行下載內容不超過兩個。如果你的圖片放在多個主機名稱上，你可以在每個並行下載中同時下載2個以上的檔案。但是當下載指令碼 時，瀏覽器就不會同時下載其它檔案了，即便是主機名稱不相同。
在某些情況下把指令碼移到頁面底部可能不太容易。比如說，如果指令碼中使用了document.write來插入頁面內容，它就不能被往下移動了。這裡可能還會有範圍的問題。很多情況下，都會遇到這方面的問題。
一個經常用到的替代方法就是使用延遲指令碼。DEFER屬性工作表明指令碼中沒有包含document.write，它告訴瀏覽器繼續顯示。不幸的 是，Firefox並不支援DEFER屬性。在Internet Explorer中，指令碼可能會被延遲但效果也不會像我們所期望的那樣。如果指令碼可以被延遲，那麼它就可以移到頁面的底部。這會讓你的頁面載入的快一點。

24、剔除重複指令碼

在同一個頁面中重複引用JavaScript檔案會影響頁面的效能。你可能會認為這種情況並不多見。對於美國前10大網站的調查顯示其中有兩家存在重複引 用指令碼的情況。有兩種主要因素導致一個指令碼被重複引用的奇怪現象發生：團隊規模和指令碼數量。如果真的存在這種情況，重複指令碼會引起不必要的HTTP請求和 無用的JavaScript運算，這降低了網站效能。
在Internet Explorer中會產生不必要的HTTP請求，而在Firefox卻不會。在Internet Explorer中，如果一個指令碼被引用兩次而且它又不可緩衝，它就會在頁面載入過程中產生兩次HTTP請求。即時指令碼可以緩衝，當使用者重載頁面時也會產 生額外的HTTP請求。
除增加額外的HTTP請求外，多次運算指令碼也會浪費時間。在Internet Explorer和Firefox中不管指令碼是否可緩衝，它們都存在重複運算JavaScript的問題。
一個避免偶爾發生的兩次引用同一指令碼的方法是在模板中使用指令碼管理模組引用指令碼。在HTML頁面中使用<script />標籤引用指令碼的最常見方法就是：
<script type=”text/javascript” src=”menu_1.0.17.js”></script>
在PHP中可以通過建立名為insertScript的方法來替代：

為了防止多次重複引用指令碼，這個方法中還應該使用其它機制來處理指令碼，如檢查所屬目錄和為指令檔名中增加版本號碼以用於Expire檔案頭等。

25、減少DOM訪問

使用JavaScript訪問DOM元素比較慢，因此為了獲得更多的應該頁面，應該做到：

• 緩衝已經訪問過的有關元素
• 線下更新完節點之後再將它們添加到文檔樹中
• 避免使用JavaScript來修改頁面配置
  有關此方面的更多資訊請查看Julien Lecomte在YUI專題中的文章“高效能Ajax應該程式”。

26、開發智能事件處理常式

有時候我們會感覺到頁面反應遲鈍，這是因為DOM樹元素中附加了過多的事件控制代碼並且些事件句病被頻繁地觸發。這就是為什麼說使用event delegation（事件代理）是一種好方法了。如果你在一個div中有10個按鈕，你只需要在div上附加一次事件控制代碼就可以了，而不用去為每一個按 鈕增加一個控制代碼。事件冒泡時你可以捕捉到事件並判斷出是哪個事件發出的。
你同樣也不用為了操作DOM樹而等待onload事件的發生。你需要做的就是等待樹結構中你要訪問的元素出現。你也不用等待所有映像都載入完畢。
你可能會希望用DOMContentLoaded事件來代替 事件應用程式中的onAvailable方法。

27、減小Cookie體積

HTTP coockie可以用於許可權驗證和個人化身份等多種用途。coockie內的有關資訊是通過HTTP檔案頭來在web伺服器和瀏覽器之間進行交流的。因此保持coockie儘可能的小以減少使用者的回應時間十分重要。
有關更多資訊可以查看Tenni Theurer和Patty Chi的文章“When the Cookie Crumbles”。這們研究中主要包括：

• 去除不必要的coockie
• 使coockie體積盡量小以減少對使用者響應的影響
• 注意在適應層級的網域名稱上設定coockie以便使子網域名稱不受影響
• 設定合理的到期時間。較早地Expire時間和不要過早去清除coockie，都會改善使用者的回應時間。

28、對於頁面內容使用無coockie網域名稱

當瀏覽器在請求中同時請求一張靜態圖片和發送coockie時，伺服器對於這些coockie不會做任何地使用。因此他們只是因為某些負面因素而建立的 網路傳輸。所有你應該確定對於靜態內容的請求是無coockie的請求。建立一個子網域名稱並用他來存放所有靜態內容。
如果你的網域名稱是www.example.org，你可以在static.example.org上存在靜態內容。但是，如果你不是在 www.example.org 上而是在頂級網域名稱example.org設定了coockie，那麼所有對於static.example.org的請求都包含coockie。在這種情 況下，你可以再重新購買一個新的網域名稱來存在靜態內容，並且要保持這個網域名稱是無coockie的。Yahoo!使用的是 ymig.com，YouTube使用的是ytimg.com，Amazon使用的是images-anazon.com等等。
使用無coockie網域名稱存在靜態內容的另外一個好處就是一些代理（伺服器）可能會拒絕對coockie的內容請求進行緩衝。一個相關的建議就是，如果你想確定應該使用example.org還是www.example.org 作為你的一首頁，你要考慮到coockie帶來的影響。忽略掉www會使你除了把coockie設定到*.example.org（*是泛網域名稱解析，代表 了所有子網域名稱譯者dudo注）外沒有其它選擇，因此出於效能方面的考慮最好是使用帶有www的子網域名稱並且在它上面設定coockie。

29、最佳化映像

設計人員完成對頁面的設計之後，不要急於將它們上傳到web伺服器，這裡還需要做幾件事：

• 你可以檢查一下你的GIF圖片中映像顏色的數量是否和調色盤規格一致。 使用imagemagick中下面的命令列很容易檢查：
  identify -verbose image.gif
  如果你發現圖片中只用到了4種顏色，而在調色盤的中顯示的256色的顏色槽，那麼這張圖片就還有壓縮的空間。
• 嘗 試把GIF格式轉換成PNG格式，看看是否節省空間的。大多數情況下是可以壓縮的。由於瀏覽器支援有限，設計者們往往不太樂意使用PNG格式的圖片，不過這 都是過去的事情了。現在只有一個問題就是在真彩PNG格式中的alpha通道半透明問題，不過同樣的，GIF也不是真彩格式也不支援半透明。因此GIF能 做到的，PNG（PNG8）同樣也能做到（除了動畫）。下面這條簡單的命令可以安全地把GIF格式轉換為PNG格式：
  convert image.gif image.png
  “我們要說的是：給PNG一個施展身手的機會吧！”
• 在所有的PNG圖片上運行pngcrush（或者其它PNG最佳化工具）。例如：
  pngcrush image.png -rem alla -reduce -brute result.png
• 在所有的 JPEG圖片上運行jpegtran。這個工具可以對圖片中的出現的鋸齒等做無損操作，同時它還可以用於最佳化和清除圖片中的注釋以及其它無用資訊（如 EXIF資訊）：
  jpegtran -copy none -optimize -perfect src.jpg dest.jpg

30、最佳化CSS Spirite

• 在Spirite中水平排列你的圖片，垂直排列會稍稍增加檔案大小；
• Spirite 中把顏色較近的組合在一起可以降低顏色數，理想狀況是低於256色以便適用PNG8格式；
• 便於移動，不要在Spirite的映像中間留有較大空隙。這雖然不大會增加檔案大小但對於使用者代理程式來說它需要更少的記憶體來把圖片解壓為像素地圖。100×100的圖片為1萬像素，而 1000×1000就是100萬像素。

31、不要在HTML中縮放映像

不要為了在HTML中設定長寬而使用比實際需要大的圖片。如果你需要：
<img width=”100″ height=”100″ src=”mycat.jpg” alt=”My Cat” />
那麼你的圖片（mycat.jpg）就應該是100×100像素而不是把一個500×500像素的圖片縮小使用。

32、favicon.ico要小而且可緩衝

favicon.ico是位於伺服器根目錄下的一個圖片檔案。它是必定存在的，因為即使你不關心它是否有用，瀏覽器也會對它發出請求，因此最好不要返回一 個404 Not Found的響應。由於是在同一台伺服器上，它每被請求一次coockie就會被發送一次。這個圖片檔案還會影響下載順序，例如在IE中當你在 onload中請求額外的檔案時，favicon會在這些額外內容被載入前下載。
因此，為了減少favicon.ico帶來的弊端，要做到：

• 檔案盡量地小，最好小於1K
• 在適當的時候（也就是你不要打算再換 favicon.ico的時候，因為更換新檔案時不能對它進行重新命名）為它設定Expires檔案頭。你可以很安全地把Expires檔案頭設定為未來的幾個月。你可以通過核對當前favicon.ico的上次編輯時間來作出判斷。

Imagemagick可以幫你建立小巧的 favicon。

33、保持單個內容小於25K

這條限制主要是因為iPhone不能緩衝大於25K的檔案。注意這裡指的是解壓縮後的大小。由於單純gizp壓縮可能達不要求，因此精簡檔案就顯得十分重要。
查看更多資訊，請參閱Wayne Shea和Tenni Theurer的檔案“Performance Research, Part 5: iPhone Cacheability – Making it Stick”。

34、打包組件成複合文本

把頁面內容打包成複合文本就如同帶有多附件的Email，它能夠使你在一個HTTP請求中取得多個組件（切記：HTTP請求是很奢侈的）。當你使用這條規則時，首先要確定使用者代理程式是否支援（iPhone就不支援）。

Yahoo團隊經驗：網站效能最佳化的34條黃金法則