本文來自于周裕波的博客，關于更多前臺優化的內容可以上他的博客上學習 http://www.webchina110.cn/
Yahoo! 的 Exceptional Performance 團隊為 Web 頁面性能優化帶來最佳實踐，旨在提高網站性能。Excetional Performance 團隊總結出了一系列可以提高網站速度的方法，可以分為 7 大類 34 條。包括內容、服務器、Cookie、CSS、JavaScript、圖片、移動應用等七部分。
Web 頁面性能優化之內容
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.fufuok.com 時，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/demo
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 性能的措施中最重要的方法就是使響應具有可緩存性，具體的討論可以查看規則：添加 Expires 頭(或者 Cache-control ) 。其它的幾條規則也同樣適用于 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 上。
9、使 iframe 的數量最小
ifrmae 元素可以在父文檔中插入一個新的 HTML 文檔。了解 iframe 的工作理然后才能更加有效地使用它，這一點很重要。
<iframe> 的優點：
解決加載緩慢的第三方內容如圖標和廣告等的加載問題 Security sandbox 并行加載腳本。
<iframe> 的缺點：
即時內容為空，加載也需要時間，會阻止頁面加載，沒有語意。
10、不要出現 404 錯誤
HTTP 請求時間消耗是很大的，因此使用 HTTP 請求來獲得一個沒有用處的響應（例如 404 沒有找到頁面）是完全沒有必要的，它只會降低用戶體驗而不會有一點好處。
有些站點把404錯誤響應頁面改為“你是不是要找***”，這雖然改進了用戶體驗但是同樣也會浪費服務器資源（如數據庫等）。最糟糕的情況是指向外部 JavaScript 的鏈接出現問題并返回 404 代碼。首先，這種加載會破壞并行加載；其次瀏覽器會把試圖在返回的 404 響應內容中找到可能有用的部分當作 JavaScript 代碼來執行。
在本系列的第一節中，講了提高網站性能中網站“內容”有關的10條原則。除了在網站在內容上的改進外，在網站服務器端上也有需要注意和改進的地方，它們包括：
使用內容分發網絡
為文件頭指定 Expires 或 Cache-Control
Gzip 壓縮文件內容
配置 ETag
盡早刷新輸出緩沖
使用 GET 來完成 AJAX 請求
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>
<?php flush(); ?>
<body>
… <!– content –>
為了證明使用這項技術的好處，Yahoo! 搜索率先研究并完成了用戶測試。
16、使用 GET 來完成 AJAX 請求
Yahoo!Mail 團隊發現，當使用 XMLHttpRequest 時，瀏覽器中的 POST 方法是一個“兩步走”的過程：首先發送文件頭，然后才發送數據。因此使用 GET 最為恰當，因為它只需發送一個 TCP 包（除非你有很多 Cookies）。IE 中 URL 的最大長度為 2K ，因此如果你要發送一個超過 2K 的數據時就不能使用 GET 了。
一個有趣的不同就是 POST 并不像 GET 那樣實際發送數據。根據 HTTP 規范，GET 意味著“獲取”數據，因此當你僅僅獲取數據時使用 GET 更加有意義（從語意上講也是如此），相反，發送并在服務端保存數據時使用 POST 。
在第一部分和第二部分中我們分別介紹了改善網站性能中頁面內容和服務器的幾條守則，除此之外，JavaScript 和 CSS 也是我們頁面中經常用到的內容，對它們的優化也提高網站性能的重要方面：
把樣式表置于頂部
把腳本置于頁面底部
避免使用 CSS 表達式（Expression）
使用外部 JavaScript 和 CSS
削減 JavaScript 和 CSS
用 <link> 代替 @import
避免使用濾鏡
剔除重復腳本
減少DOM訪問
開發智能事件處理程序
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 表達式可以實現隔一個小時切換一次背景顏色：
background-color: expression( (new Date()).getHours()%2 ? “#B8D4FF” : “#F08A00″ );
如上所示，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 的方法來替代：
<?php insertScript(”menu.js”) ?>
為了防止多次重復引用腳本，這個方法中還應該使用其它機制來處理腳本，如檢查所屬目錄和為腳本文件名中增加版本號以用于 Expire 文件頭等。
25、減少 DOM 訪問
使用 JavaScript 訪問 DOM 元素比較慢，因此為了獲得更多的應該頁面，應該做到：
緩存已經訪問過的有關元素
線下更新完節點之后再將它們添加到文檔樹中
避免使用JavaScript來修改頁面布局
有關此方面的更多信息請查看Julien Lecomte在YUI專題中的文章“高性能Ajax應該程序”。
26、開發智能事件處理程序
有時候我們會感覺到頁面反應遲鈍，這是因為DOM樹元素中附加了過多的事件句柄并且些事件句病被頻繁地觸發。這就是為什么說使用event delegation（事件代理）是一種好方法了。如果你在一個div中有10個按鈕，你只需要在div上附加一次事件句柄就可以了，而不用去為每一個按 鈕增加一個句柄。事件冒泡時你可以捕捉到事件并判斷出是哪個事件發出的。
你同樣也不用為了操作DOM樹而等待onload事件的發生。你需要做的就是等待樹結構中你要訪問的元素出現。你也不用等待所有圖像都加載完畢。
你可能會希望用DOMContentLoaded事件來代替onload，但是在所有瀏覽器都支持它之前你可使用YUI 事件應用程序中的onAvailable方法。
我們在前面的幾節中分別講了提高網站性能中內容、服務器、JavaScript和CSS等方面的內容。除此之外，圖片和Coockie也是我們網站中幾乎不可缺少組成部分，此外隨著移動設備的流行，對于移動應用的優化也十分重要。這主要包括：
Coockie:
減小Cookie體積
對于頁面內容使用無coockie域名
圖片：
優化圖像
優化CSS Spirite
不要在HTML中縮放圖像
favicon.ico要小而且可緩存
移動應用：
保持單個內容小于25K
打包組件成復合文本
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（*是泛域名解析，代表了所有子域名）外沒有其它選擇，因此出于性能方面的考慮最好是使用帶有 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壓縮可能達不要求，因此精簡文件就顯得十分重要。
34、打包組件成復合文本
把頁面內容打包成復合文本就如同帶有多附件的Email，它能夠使你在一個HTTP請求中取得多個組件（切記：HTTP請求是很奢侈的）。當你使用這條規則時，首先要確定用戶代理是否支持（iPhone就不支持）。
Best Practices for Speeding Up Your Web Site：
Make Fewer HTTP Requests
Use a Content Delivery Network
Add an Expires or a Cache-Control Header
Gzip Components
Put Stylesheets at the Top
Put Scripts at the Bottom
Avoid CSS Expressions
Make JavaScript and CSS External
Reduce DNS Lookups
Minify JavaScript and CSS
Avoid Redirects
Remove Duplicate Scripts
Configure ETags
Make Ajax Cacheable
Flush the Buffer Early
Use GET for AJAX Requests
Post-load Components
Preload Components
Reduce the Number of DOM Elements
Split Components Across Domains
Minimize the Number of iframes
No 404s
Reduce Cookie Size
Use Cookie-free Domains for Components
Minimize DOM Access
Develop Smart Event Handlers
Choose <link> over @import
Avoid Filters
Optimize Images
Optimize CSS Sprites
Don’t Scale Images in HTML
Make favicon.ico Small and Cacheable
Keep Components under 25K
Pack Components into a Multipart Document