摘要：規則使用內容發布網絡用戶同服務器的距離會對頁面響應時間產生影響。這不僅能達到響應時間大幅減少的目的，還很容易實現。提供動態頁面會引入特殊的存儲要求數據庫連接狀態管理驗證硬件和優化等，這些復雜性超過了的范圍。

鏈接參考： https://developer.yahoo.com/performance/rules.html

  只有10%～20%的最終用戶響應時間花在了下載HTML文檔上，其余的80%～90%時間花在了下載頁面中的所有組件上。
                                                        ——Steve Souders

  
規則1——減少HTTP請求（Minimize HTTP Requests）

    只有10%～20%的最終用戶響應時間花在接收請求的HTML文檔上，剩下的80%～90%時間都花在HTML文檔所引用的所有組件（圖片、腳本、樣式表、Flash等）進行的HTTP請求上。因此，改善響應時間最簡單的辦法就是減少組件數量并由此減少HTTP請求數。減少組件數量通常會和產品設計的初衷相矛盾，因此，此處給出了一些技術：

   圖片地圖（Image Maps）聯合多個圖片到一個多帶帶的圖片中。下載圖片大小的總和保持不變，但是，通過減少HTTP請求數的方式加速了頁面。圖片地圖適用于導航欄或其他超鏈接中使用多個圖片的情形。但是，在定義圖片地圖上的區域坐標時，如果采用手工方式很難完成且容易出錯，而且除了矩形外幾乎無法定義其他形狀。

   CSS Sprites使用CSS background-image和background-position屬性將多個圖片聯合成一個獨立的圖片來顯示。它通過合并圖片減少了HTTP請求，并且比圖片地圖更加靈活，同時也降低了圖片的下載量。如果在頁面中需要為背景、按鈕、導航欄、鏈接等提供大量圖片，CSS Sprites是一種優秀的解決方案。

   內聯圖片（Inline images）使用data: URL scheme模式將圖片嵌入到HTML文檔中。通過此模式嵌入圖片，不需要任何額外的HTTP請求開銷。但是，目前的主流瀏覽器（主要是IE）不支持此種方式。

   合并文件（Combined files）通過將所有JavaScript腳本合并到一個文件，所有CSS樣式表合并到另一個文件的方式來減少HTTP請求的數量。但是簡單的合并通常會遇到模塊化、頁面變化等問題，需要根據頁面引用腳本和樣式表來具體分析以確定具體的組合方式。

  
規則2——使用內容發布網絡（Use a Content Delivery Network）

    用戶同Web服務器的距離會對頁面響應時間產生影響。網站最初通常將其所有服務器放在同一個地方，當用戶群增加時，公司必須面對服務器放置地點不再合適的事實。因此，有必要在多個地理位置不同的服務器上部署內容。

   作為實現地理位置分離的第一步，不應當首先嘗試使用分布式架構重新設計Web應用程序。這樣的應用程序決定了重新設計將帶來如同步會話狀態、在服務器放置地點間復制數據庫事務等復雜問題。重新設計會推遲甚至根本無法實現縮短用戶和網站內容距離的愿望。

   如果應用程序Web服務器里用戶更近，則一個HTTP請求的響應時間將被縮短；如果組件Web服務器離用戶更近，則多個HTTP請求的響應時間將縮短。因此，與其重新開始設計應用程序，以便將應用程序Web服務器分散開，不如首先將組件Web服務器分散開。這不僅能達到響應時間大幅減少的目的，還很容易實現。

   內容發布網絡（CDN）是一組分布在多個不同地理位置的Web服務器，用于更加有效的向用戶發布內容。向特定用戶發布內容的服務器基于對網絡可用度的測量，例如，CDN可能選擇網絡階躍數最小的服務器，或者具有最短響應時間的服務器。

   除了縮短響應時間外，CDN還可以帶來其他優勢，包括備份、擴展存儲能力和進行緩存；同時，CDN還有助于緩和Web流量峰值的壓力，如在獲取天氣或股市新聞、瀏覽體育或娛樂事件時。依賴CDN的一個缺點是網站的響應時間會受到其他網站——甚至可能是競爭對手流量的影響；另一個缺點是無法直接控制組件服務器所帶來的問題。

  CDN用于發布靜態內容（如圖片、腳本、樣式表、Flash）。提供動態HTML頁面會引入特殊的存儲要求——數據庫連接、狀態管理、驗證、硬件和OS優化等，這些復雜性超過了CDN的范圍。另一方面，靜態文件更容易存儲并具有較少的依賴。

  
規則3——添加Expires頭（Add an Expires or a Cache-Control Header）

   Web頁面包含大量組件，并且數量在不斷增長。頁面的初訪者會進行很多的HTTP請求，但通過一個長久的Expires頭，可以使這些組件被緩存下來，可以在后續的頁面瀏覽中避免不必要的HTTP請求。長久的Expires頭最長用于圖片，但應該將其用于所有組件上，包括腳本、樣式表和Flash。

Web服務器使用Expires頭告訴Web客戶端它可以使用一個組件的當前副本，知道指定時間為止。HTTP規范中簡要的稱該頭為“在這一日期/時間之后，響應將被認為是無效的”。例如：

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

告訴瀏覽器該響應的有效性持續到2010年4月15日。

因為Expires頭使用一個特定的時間，它要求服務端和客戶端的時鐘嚴格同步；另外，過期日期需要經常檢查，一旦過期日期到了，需要在服務器中配置提供一個新的日期。所以，HTTP1.1引入了Cache-Control頭來克服Exipres頭的限制。Cache-Control使用max-age指令指定組件被緩存多久，它以秒為單位定義了一個更新窗。使用帶有max-age的Cache-Control可以消除Expires的限制，但對于不支持HTTP1.1的應用，仍希望使用Expires頭。可以同時制定這兩個響應頭，如果兩者同時出現時，HTTP規范規定max-age指令將重寫Expires頭。

當出現了Expires頭時，直到過期時間為止一直會使用緩存的版本，瀏覽器不會檢查任何更新，直到過了過期時間。為了確保用戶能夠獲取組件的最新版本，需要在所有的HTML頁面中修改組件的文件名。Yahoo在此使用了將版本號嵌入在組件的文件名中的方法。

  
規則4——壓縮組件（Gzip Components)

壓縮組件通過減少HTTP請求產生的響應包的大小，從而降低傳輸時間的方式來提高性能。從HTTP1.1開始，Web客戶端可以通過HTTP請求中的Accept-Encoding頭來標識對壓縮的支持：


Accept-Encoding: gzip, deflate

如果Web服務器看到請求中的這個頭，就會使用客戶端列出的方法中的一種來壓縮響應。Web服務器通過響應中的Content-Encoding頭來通知Web客戶端：


Content-Encoding: gzip

目前許多網站通常會壓縮HTML文檔，腳本和樣式表的壓縮也是值得的（包括XML和JSON在內的任何文本響應理論上都值得被壓縮）。但是，圖片和PDF文件不應該被壓縮，因為它們本來已經被壓縮了。

壓縮通常能將響應的數據量減少近70%，但是壓縮通常情況下會帶來服務端和客戶端的CPU開銷，要檢測受益是否大于開銷，需要綜合考慮響應大小、連接的帶寬和客戶端也服務端直接的距離等因素。通常需要對大于1KB或2KB的文件進行壓縮。

當瀏覽器通過代理來發送請求時，有可能出現瀏覽器期望接受的壓縮后內容和實際接收到的不一致的情況。解決這一問題的方法是在Web服務器的響應中添加Vary頭。Web服務器可以告訴代理根據一個或多個請求頭來改變緩存的響應。由于壓縮的決定是基于Accept-Encoding請求頭的，因此需要在服務器的Vary響應頭中包含Accept-Encoding:


Vary: Accept-Encoding

目前大約90%的通過瀏覽器進行的Internet通信都需要使用gzip，使得服務端和客戶端的對等性變得額外重要。無論是客戶端還是服務端發送錯誤，都會造成頁面被破壞。避免錯誤的一種方式是采用“瀏覽器白名單”方式，即只為經過證實支持壓縮的瀏覽器提供壓縮內容，但是當代理緩存加進來以后，處理邊緣情形瀏覽器將變得更加復雜。另一種方式是使用Vary: *或Cache-Control: private頭來禁用代理緩存。此種方式會為所有瀏覽器禁用代理緩存，從而增加帶寬開銷。如何平衡壓縮和代理支持需要在加快響應時間、減小帶寬開銷和邊緣情形瀏覽器缺陷之間進行權衡：

如果網站的用戶很少，并且他們處于一個小圈子中，邊緣情形瀏覽器不需要太多關注，可以壓縮內容并使用Vary: Accept-Encoding。

如果更注重帶寬開銷，可以和前一種情形一樣，壓縮內容并使用Vary: Accept-Encoding。

如果網站擁有大量的、多變的用戶群，能夠應付較高的帶寬開銷，并且享有高質量的名聲，需要壓縮內容并使用Cache-Control: Private。（Google和Yahoo都使用這種方式）

  
規則5——將樣式表放在頂部（Put Stylesheets at the Top）

我們都希望頁面能夠逐步加載，也就是說，我們希望瀏覽器能夠盡快顯示內容。當瀏覽器逐步加載頁面時，頁頭、導航欄、頂端logo等所有這些都會等待頁面的用戶提供視覺反饋，這改善了用戶體驗。將樣式表放在底部，為避免當樣式變化時重繪頁面中的元素，瀏覽器會阻塞內容逐步呈現。

樣式表在頁面中的位置并不影響下載時間，但是會影響頁面的呈現。根據HTML規范“和A不一樣，[LINK]只能出現在文檔的HEAD節中，但其出現次數是任意的”。因此，問題的解決方式應該是遵循HTML規范，使用LINK標簽將樣式表放在文檔的HEAD中。

  
規則6——將腳本放在底部（Put Scripts at the Bottom）

對響應時間影響最大的是頁面中的組件數量，而腳本會阻塞組件的并行下載，帶來性能上的問題。HTTP1.1規范建議瀏覽器從每個主機名并行下載兩個組件。如果一個Web頁面平均將其組件分別放在兩個主機名下，整體響應時間可以減少大約一半。我們可以通過對瀏覽器默認設置的修改來增加每個主機名并行下載組件的數量，也可以使用CNAME（DNS別名）將組件分別放到多個主機名下。但是，增加并行下載數量通常會帶來性能上的開銷，過多的并行下載有時反而會降低性能。Yahoo!研究表明，使用兩個主機名比使用1、4或10個主機名能帶來更好的性能。

需要我們注意的是，下載腳本時并行下載實際上是被禁用的，即使此時使用了不同的主機名，瀏覽器也不會啟動其他下載。因此，如果將腳本放在頂部，腳本會阻塞后面內容的呈現，也會阻塞后面組件的下載。因此，放置腳本最好的地方是頁面底部，這不會阻止頁面內容呈現，而且頁面中的可視組件可以盡早下載。

  
規則7——避免CSS表達式(Avoid CSS Expressions)

CSS表達式是動態設置CSS屬性的一種強大（并且危險）的方式。它從IE5以后的版本被支持，在IE8中已經被廢棄。
表達式的問題在于對其進行的求值頻率比人們期望的要高。它們不只在呈現頁面和大小改變時求值，當頁面滾動，甚至用戶鼠標在頁面上移過時都要進行求值。

減少CSS表達式求值次數的一種方式是使用一次性表達式，如果CSS表達式必須被求值一次，可以在這一次中執行重寫它本身。除此之外，還可以使用事件處理器來為特定的事件提供所期望的動態行為。

  
規則8——使用外部JavaScript和CSS（Make JavaScript and CSS External）

在現實環境中使用外部文件通常會產生較快的頁面，因為JavaScript和CSS有機會被瀏覽器緩存起來。對于內聯的情況，由于HTML文檔通常不會被配置為可以進行緩存的，所以每次請求HTML文檔都要下載JavaScript和CSS。所以，如果JavaScript和CSS在外部文件中，瀏覽器可以緩存它們，HTML文檔的大小會被減少而不必增加HTTP請求數量。

決定是否使用外部文件的關鍵在于被緩存的外部文件占請求的HTML文檔數的比重。如果網站用戶在每次會話中進行多次頁面訪問，同時頁面重用了多個腳本和樣式表，使用外部文件時很好的選擇。

對于大多數網站而言，難以精確度量以判斷是否使用內聯或外部文件，此時建議是使用外部文件的方式。對于這個問題的一個例外是網站主頁，由于主頁對于響應時間要求更高，因此更加傾向于內聯而不是外部文件。

對于內聯文件而言，由于無法利用瀏覽器緩存，因此給人感覺依然比較低效。我們可以通過加載后下載和動態內聯的方式來使得網站主頁既可以獲得內聯的優勢，同時也能緩存外部文件。

  
規則9——減少DNS查找（Reduce DNS Lookups）

DNS對于網站來說會帶來開銷。通常瀏覽器查找一個給定主機名的IP要花費20～120毫秒的時間。在DNS查找完成之前，瀏覽器不能從此主機下載任何東西。

DNS查找可以被緩存起來以提高性能，這種緩存可以發生在ISP或局域網中的一臺特殊的緩存服務器上，同時，緩存也會發生在獨立的用戶機器上。在用戶請求一個主機名后，DNS信息會留在操作系統的DNS緩存中，大多數瀏覽器也擁有自己的緩存，和操作系統緩存相分離。只要瀏覽器在其緩存中保留了DNS記錄，就不會通過操作系統來請求這個記錄。

當客戶端瀏覽器和操作系統中DNS緩存同時為空時，DNS查詢的數量等于頁面中唯一主機名的數量，這些主機名包括了頁面的URL、圖片、腳本、樣式表、Flash等。所以，減少唯一主機名數量，可以減少DNS查詢數。

減少唯一主機名數量會潛在的減少頁面中并行下載的數量。避免DNS查找降低了響應時間，但減少并行下載可能會增加響應時間。對于這種情形，建議將這些組件放在至少2個，但不要超過4個主機名下。

規則10——精簡JavaScript和CSS（Minify JavaScript and CSS）
精簡是從代碼中移除不必要的字符以減小其大小，進而改善加載時間。在代碼被精簡后，所有注釋以及不必要的空白字符（空格、換行和制表符）都將被移除。對于JavaScript而言，因為需要下載的文件大小減小了，可以改善響應時間。

混淆是可以應用在源代碼上的另一種優化方式。相比較于精簡，混淆更加復雜，因此更容易產生bug。混淆可以更大程度上壓縮源代碼，但是也存在著一定的風險。

除了外部JavaScript外，內聯在

另一種選擇是在PHP中創建一個函數：




為了防止統一個腳本被重復添加多次，insertScript函數需要添加處理腳本的依賴性和版本的功能。

  
規則13——配置Etag（Configure ETags）

實體標簽（Entity Tag，ETag）是Web服務器和瀏覽器用于確認緩存組件的有效性的一種機制。ETag在HTTP1.1中引入，用于檢測瀏覽器緩存中的組件與原始服務器上的組件是否匹配。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


f-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中嵌入的數據都會大大降低有效性驗證的成功率。

Apache1.3和2.x的ETag格式是inode-size-timestamp。文件系統使用inode來存儲諸如文件類型、所有者、組和訪問模式等信息。盡管在多臺服務器上一個給定的文件可能位于相同的目錄、具有相同的文件大小、權限、時間戳等，從一臺服務器到另一臺服務器，器inode仍然是不同的。
IIS5.0和6.0在ETag上有著類似的問題。IIS上ETag的格式是Filetimestamp:ChangeNumber。ChangeNumber適用于跟蹤IIS配置變化的計數器。對于一個網站背后的所有IIS服務器來說，ChangeNumber不大可能相同。
最

終的結果是，對于完全相同的組件，從一臺服務器到另一臺，Apache和IIS產生的ETag是不會匹配的。如果ETag不匹配，用戶就不會按照ETag的設計計劃那樣接收到更小更快的304響應；相反，它們會收到普通的200響應以及組件的所有數據。如果只在一臺服務器上部署網站，這通常不會產生問題；但如果使用了服務器集群，同時使用Apache或者IIS進行默認的ETag配置，用戶響應將變慢，服務器負載將變高，將消耗更多的帶寬，同時代理緩存的效率也會下降。即使組件具有長久的Expires頭，一旦用戶單擊了Reload或Refresh按鈕，依然會產生條件GET請求。
如果組件必須通過最新修改日期之外的一些東西來進行驗證，則ETag是一種強大的方法；如果無須自定義ETag，則最好將其移除。Last-Modified頭基于組件的時間戳進行驗證，可以提供完全等價的信息，而且移除ETag可以減少響應和后續請求的HTTP頭的大小。在Apache中，只要向Apache配置文件中簡單地添加下面一行配置就能移除ETag：
FileETag none

  
規則14——使Ajax可緩存（Make Ajax Cacheable）

Ajax的一個最重要的優點就是向用戶提供即時反饋，因為它異步的從后臺Web服務器請求信息。但是，使用Ajax并不保證用戶不會等到異步的JavaScript和XML返回響應。在很多應用程序中，用戶是否需要等待取決于如何使用Ajax。用戶是否需要等待的關鍵因素在于Ajax請求是主動的還是被動的。主動請求是基于用戶的當前操作而發起的，被動請求則是為了將來使用而預先發起的。我們需要注意的是，“異步”并沒有暗示“實時”。

為了提升性能，最重要的是優化Ajax響應。而改善這些主動Ajax請求的最重要的方式就是使響應可緩存。如同在“添加Expires頭”中討論的，一些其他規則也適用于Ajax，包括：壓縮組件、減少DNS查找、精簡JavaScript、避免重定向、配置Etag。