Yahoo!的 Exceptional Performance團隊為改善 Web性能帶來最佳實踐。他們為此進行了一系列的實驗、開發了各種工具、寫了大量的文章和部落格并在各種會議上參與探讨。最佳實踐的核心就是旨在提高網站性能。原版猛戳：Best Practices for Speeding Up Your Web Site，
Excetional Performance 團隊總結出了一系列可以提高網站速度的方法。可以分為 7大類 35條。
包括内容 、伺服器 、 CSS 、 JavaScript 、Cookie 、圖檔 、移動應用 ，七部分。
一、内容部分
- 盡量減少 HTTP請求
- 減少 DNS查找
- 避免跳轉
- 緩存 Ajxa
- 推遲加載
- 提前加載
- 減少 DOM元素數量
- 用域名劃分頁面内容
- 使 frame數量最少
- 避免 404錯誤
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.yahoo.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/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内容和動态内容放在 http://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代碼來執行。
二、伺服器部分
- 使用内容分發網絡
- 為檔案頭指定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包（除非你有很多cookie）。IE中URL的最大長度為2K，是以如果你要發送一個超過2K的 資料時就不能使用GET了。
一個有趣的不同就是POST并不像GET那樣實際發送資料。根據HTTP規範，GET意味着“擷取”資料，是以當你僅僅擷取資料時使用GET更加有意義 （從語意上講也是如此），相反，發送并在服務端儲存資料時使用POST。
除此之外，JavaScript和CSS也是我們頁面中經常用到的内容，對它們的優化也提高網站性能的重要方面：
35、避免空的圖像來源
一個src屬性為空串的圖像有兩種情況：
1．直接的HTML
<img src="">
2．JavaScript
var img = new Image();
img.src = "";
這兩種情況都會引起同樣的效果：浏覽器會再次向你的伺服器送出請求。
- Internet Explorer 将向這個頁面所在的目錄發出一個請求
- Safari and Chrome 将發出對這個頁面的一個請求。
- Firefox 3 和更早的版本所采取的動作和Safari and Chrome一樣，但是 3.5版本 addressed this issue[bug 444931] and no longer sends a request.
- Opera 不進行任何操作。
這個行為為何是不好的？
1、發送大量突然的請求将使你的伺服器當機（Cripple your servers），尤其是每天有數百萬通路量的頁面。
2、産生一個從未浏覽過的頁面将浪費伺服器的計算周期（computing cycles）
3、損壞使用者資料。如果你在請求中追蹤狀态（以cookie或是其他的方式），你可能會損壞資料。即使這個圖像請求并沒有傳回一個圖像，所有的頭被浏覽器讀取并接受，包括所有cookie。While the rest of the response is thrown away, the damage may already be done.
引起這種行為的根源在于浏覽器中URI的解析方式。這種行為定義在RFC 3986 - Uniform Resource Identifiers.當一個空串作為一個URI時，它被認為一個相對URI（relative URI）并通過定義在section 5.2中的算法被解析。這個特例，一個空串，列在section 5.4當中。Firefox, Safari, and Chrome都是依據這一規格來解析空串，而Internet Explorer則不正确的解析這個串，符合更早的一個規範，RFC 2396 - Uniform Resource Identifiers (this was obsoleted by RFC 3986).是以技術上，浏覽器都在做它們被期望所做的事情來解析relative URIs，問題是在這個範圍，空串不是故意造成的。
HTML5 adds to the description of the tag's src attribute to instruct browsers not to make an additional request in section 4.8.2:
The src attribute must be present, and must contain a valid URL referencing a non-interactive, optionally animated, image resource that is neither paged nor scripted. If the base URI of the element is the same as the document's address, then the src attribute's value must not be the empty string.
非常希望浏覽器在将來不會有這樣的問題。不幸的是，沒有為<script src=""> and <link href="" target="_blank" rel="external nofollow" >的條款。或許仍需要時間來做出調整以保證浏覽器不會意外的實作這一行為。
這一規則是受雅虎JavaScript導師Nicolas C. Zakas啟發。更新資訊請參見Empty image src can destroy your site..
三、CSS部分
- 把樣式表置于頂部
- 避免使用CSS表達式（）
- 用<link>代替@import
- 避免使用濾鏡
17、把樣式表置于頂部
在研究Yahoo!的性能表現時，我們發現把樣式表放到文檔的<head />内部似乎會加快頁面的下載下傳速度。這是因為把樣式表放到<head />内會使頁面有步驟的加載顯示。
注重性能的前端伺服器往往希望頁面有秩序地加載。同時，我們也希望浏覽器把已經接收到内容盡可能顯示出來。這對于擁有較多内容的頁面和網速較慢的使用者來說 特别重要。向使用者傳回可視化的回報，比如程序指針，已經有了較好的研究并形成了正式文檔。在我們的研究中HTML頁面就是程序指針。當浏覽器有序地加載文 件頭、導航欄、頂部的logo等對于等待頁面加載的使用者來說都可以作為可視化的回報。這從整體上改善了使用者體驗。
把樣式表放在文檔底部的問題是在包括Internet Explorer在内的很多浏覽器中這會中止内容的有序呈現。浏覽器中止呈現是為了避免樣式改變引起的頁面元素重繪。使用者不得不面對一個空白頁面。
HTML規範清楚指出樣式表要放包含在頁面的<head />區域内：“和<a />不同，<link />隻能出現在文檔的<head />區域内，盡管它可以多次使用它”。無論是引起白屏還是出現沒有樣式化的内容都不值得去嘗試。最好的方案就是按照HTML規範在文 檔<head />内加載你的樣式表。
18、避免使用CSS表達式（）
CSS表達式是動态設定CSS屬性的強大（但危險）方法。Internet Explorer從第5個版本開始支援CSS表達式。下面的例子中，使用CSS表達式可以實作隔一個小時切換一次背景顔色：
background-color: ( (new Date()).getHours()%2 ? "#B8D4FF" : "#F08A00" );
如上所示，中使用了JavaScript表達式。CSS屬性根據JavaScript表達式的計算結果來設定。 方法在其它浏覽器中不起作用，是以在跨浏覽器的設計中單獨針對Internet Explorer設定時會比較有用。
表達式的問題就在于它的計算頻率要比我們想象的多。不僅僅是在頁面顯示和縮放時，就是在頁面滾動、乃至移動滑鼠時都會要重新計算一次。給CSS表達式增加 一個計數器可以跟蹤表達式的計算頻率。在頁面中随便移動滑鼠都可以輕松達到10000次以上的計算量。
一個減少CSS表達式計算次數的方法就是使用一次性的表達式，它在第一次運作時将結果賦給指定的樣式屬性，并用這個屬性來代替CSS表達式。如果樣式屬性 必須在頁面周期内動态地改變，使用事件句柄來代替CSS表達式是一個可行辦法。如果必須使用CSS表達式，一定要記住它們要計算成千上萬次并且可能會對你 頁面的性能産生影響。
19、用<link>代替@import
前面的最佳實作中提到CSS應該放置在頂端以利于有序加載呈現。
在IE中，頁面底部@import和使用<link>作用是一樣的，是以最好不要使用它。
20、避免使用濾鏡
IE獨有屬性AlphaImageLoader用于修正7.0以下版本中顯示PNG圖檔的半透明效果。這個濾鏡的問題在于浏覽器加載圖檔時它會終止内容的 呈現并且當機浏覽器。在每一個元素（不僅僅是圖檔）它都會運算一次，增加了記憶體開支，是以它的問題是多方面的。
完全避免使用AlphaImageLoader的最好方法就是使用PNG8格式來代替，這種格式能在IE中很好地工作。如果你确實需要使用 AlphaImageLoader，請使用下劃線_filter又使之對IE7以上版本的使用者無效。
四、 JavaScript部分
- 把腳本置于頁面底部
- 使用外部JavaScript和CSS
- 削減JavaScript和CSS
- 剔除重複腳本
- 減少DOM通路
- 開發智能事件處理程式
21、把腳本置于頁面底部
腳本帶來的問題就是它阻止了頁面的平行下載下傳。HTTP/1.1 規範建議，浏覽器每個主機名的并行下載下傳内容不超過兩個。如果你的圖檔放在多個主機名上，你可以在每個并行下載下傳中同時下載下傳2個以上的檔案。但是當下載下傳腳本 時，浏覽器就不會同時下載下傳其它檔案了，即便是主機名不相同。
在某些情況下把腳本移到頁面底部可能不太容易。比如說，如果腳本中使用了document.write來插入頁面内容，它就不能被往下移動了。這裡可能還 會有作用域的問題。很多情況下，都會遇到這方面的問題。
一個經常用到的替代方法就是使用延遲腳本。DEFER屬性表明腳本中沒有包含document.write，它告訴浏覽器繼續顯示。不幸的 是，Firefox并不支援DEFER屬性。在Internet Explorer中，腳本可能會被延遲但效果也不會像我們所期望的那樣。如果腳本可以被延遲，那麼它就可以移到頁面的底部。這會讓你的頁面加載的快一點。
22、使用外部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，但是在頁面下載下傳完成後動态下載下傳外部檔案，在子頁面中使用到這些檔案時，它們已經緩存到浏覽器了。
23、削減JavaScript和CSS
精簡是指從去除代碼不必要的字元減少檔案大小進而節省下載下傳時間。消減代碼時，所有的注釋、不需要的空白字元（空格、換行、tab縮進）等都要去掉。在 JavaScript中，由于需要下載下傳的檔案體積變小了進而節省了響應時間。精簡JavaScript中目前用到的最廣泛的兩個工具是JSMin和YUI Compressor。YUI Compressor還可用于精簡CSS。
混淆是另外一種可用于源代碼優化的方法。這種方法要比精簡複雜一些并且在混淆的過程更易産生問題。在對美國前10大網站的調查中發現，精簡也可以縮小原來 代碼體積的21%，而混淆可以達到25%。盡管混淆法可以更好地縮減代碼，但是對于JavaScript來說精簡的風險更小。
除消減外部的腳本和樣式表檔案外，<script>和<style>代碼塊也可以并且應該進行消減。即使你用Gzip壓縮過腳本 和樣式表，精簡這些檔案仍然可以節省5%以上的空間。由于JavaScript和CSS的功能和體積的增加，消減代碼将會獲得益處。
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事件來代替 事件應用程式中的onAvailable方法。
有關此方面的更多資訊請檢視Julien Lecomte在YUI專題中的文章“高性能Ajax應該程式”。
圖檔和Coockie也是我們網站中幾乎不可缺少組成部分，此外随着移動裝置的流行，對于移動應用的優化也十分重要。這主要包括：
五、Coockie部分
- 減小Cookie體積
- 對于頁面内容使用無coockie域名
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的請求。建立一個子域名并用他來存放所有靜态内容。
如果你的域名是http://www.example.org/ ，你可以在static.example.org上存在靜态内容。但是，如果你不是在http://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還是http://www.example.org/ 作為你的一首頁，你要考慮到coockie帶來的影響。忽略掉www會使你除了把coockie設定到*.example.org（*是泛域名解析，代表 了所有子域名譯者dudo注）外沒有其它選擇，是以出于性能方面的考慮最好是使用帶有www的子域名并且在它上面設定coockie。
六、Image 部分
- 優化圖像
- 優化CSS Spirite
- 不要在HTML中縮放圖像
- favicon.ico要小而且可緩存
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的圖像中間留有較大空隙。這雖然不大會增加檔案大小但對于使用者代理來說它需要更少的記憶體來把圖檔解壓為像素地圖。 100x100的圖檔為1萬像素，而1000x1000就是100萬像素。
31、不要在HTML中縮放圖像
不要為了在HTML中設定長寬而使用比實際需要大的圖檔。如果你需要：
<img width="100" height="100" src="mycat.jpg" alt="My Cat" />
那麼你的圖檔（mycat.jpg）就應該是100x100像素而不是把一個500x500像素的圖檔縮小使用。
32、favicon.ico要小而且可緩存
favicon.ico是位于伺服器根目錄下的一個圖檔檔案。它是必定存在的，因為即使你不關心它是否有用，浏覽器也會對它送出請求，是以最好不要傳回一 個404 Not Found的響應。由于是在同一台伺服器上，它每被請求一次coockie就會被發送一次。這個圖檔檔案還會影響下載下傳順序，例如在IE中當你在 onload中請求額外的檔案時，favicon會在這些額外内容被加載前下載下傳。
是以，為了減少favicon.ico帶來的弊端，要做到：
檔案盡量地小，最好小于1K
在适當的時候（也就是你不要打算再換favicon.ico的時候，因為更換新檔案時不能對它進行重命名）為它設定Expires檔案頭。你可以很安全地 把Expires檔案頭設定為未來的幾個月。你可以通過核對目前favicon.ico的上次編輯時間來作出判斷。
Imagemagick可以幫你建立小巧的favicon。
七、 Mobile部分
- 保持單個内容小于25K
- 打包元件成複合文本
33、保持單個内容小于25K
這條限制主要是因為iPhone不能緩存大于25K的檔案。注意這裡指的是解壓縮後的大小。由于單純gizp壓縮可能達不要求，是以精簡檔案就顯得十分重 要。
檢視更多資訊，請參閱Wayne Shea和Tenni Theurer的檔案“Performance Research, Part 5: iPhone Cacheability - Making it Stick”。
34、打包元件成複合文本
把頁面内容打包成複合文本就如同帶有多附件的Email，它能夠使你在一個HTTP請求中取得多個元件（切記：HTTP請求是很奢侈的）。當你使用這條規 則時，首先要确定使用者代理是否支援（iPhone就不支援）。
35、避免空的圖像來源
轉載于:https://www.cnblogs.com/guojikun/p/8600933.html
![Apache配置SSLApache配置SSL[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)