Web優化之YaHoo Web優化的14條法則

Yahoo Web優化建議原文：Best Practices for Speeding Up Your Web Site

Web應用性能優化黃金法則：先優化前端程序(front-end)的性能，由於這是80%或以上的最終用戶響應時間的花費所在。

法則1. 減小HTTP請求次數

80%的最終用戶響應時間花在前端程序上，而其大部分時間則花在各類頁面元素，如圖像、樣式表、腳本和Flash等，的下載上。減小頁面元素將會減小HTTP請求次數。這是快速顯示頁面的關鍵所在。

一種減小頁面元素個數的方法是簡化頁面設計。可是否存在其餘方式，能作到既有豐富內容，又能得到快速響應時間呢？如下是這樣一些技術：

Image maps組合多個圖片到一張圖片中。總文件大小變化不大，但減小了HTTP請求次數從而加快了頁面顯示速度。該方式只適合圖片連續的狀況；同時座標的定義是煩人又容易出錯的工做。

CSS Sprites是更好的方法。它能夠組合頁面中的圖片到單個文件中，並使用CSS的background-image和background-position屬性來現實所需的部分圖片。

Inline images使用data: URL scheme來在頁面中內嵌圖片。這將增大HTML文件的大小。組合inline images到你的（緩存）樣式表是既能較少HTTP請求，又能避免加大HTML文件大小的方法。

Combined files經過組合多個腳本文件到單一文件來減小HTTP請求次數。樣式表也可採用相似方法處理。這個方法雖然簡單，但沒有獲得大規模的使用。10大美國網站每頁平均有7個腳本文件和2個樣式表。當頁面之間腳本和樣式表變化很大時，該方式將遇到很大的挑戰，但若是作到的話，將能加快響應時間。

減小HTTP請求次數是性能優化的起點。這最提升首次訪問的效率起到很重要的做用。據Tenni Theurer的文章Browser Cache Usage - Exposed!描述，40-60%的平常訪問是首次訪問，所以爲首次訪問者加快頁面訪問速度是用戶體驗的關鍵。

咱們的應用:

外貿: 將首頁的幾十個小圖標合併爲一個，經過CSS控制它們的顯示，減小了HTTP請求數。

法則2. 使用CDN(Content Delivery Network, 內容分發網絡)

用戶離web server的遠近對響應時間也有很大影響。從用戶角度看，把內容部署到多個地理位置分散的服務器上將有效提升頁面裝載速度。可是該從哪裏開始呢？

做爲實現內容地理分佈的第一步，不要試圖重構web應用以適應分佈架構。改變架構將致使多個週期性任務，如同步session狀態，在多個server之間複製數據庫交易。這樣縮短用戶與內容距離的嘗試可能被應用架構改版所延遲，或阻止。

咱們還記得80-90%的最終用戶響應時間花在下載頁面中的各類元素上，如圖像文件、樣式表、腳本和Flash等。與其花在重構系統這個困難的任務上，還不如先分佈靜態內容。這不只能大大減小響應時間，並且因爲CDN的存在，分佈靜態內容很是容易實現。

CDN是地理上分佈的web server的集合，用於更高效地發佈內容。一般基於網絡遠近來選擇給具體用戶服務的web server。

一些大型網站擁有本身的CDN，可是使用如Akamai Technologies, Mirror Image Internet, 或 Limelight Networks等CDN服務提供商的服務將是划算的。在Yahoo!把靜態內容分佈到CDN減小了用戶影響時間20%或更多。切換到CDN的代碼修改工做是很容易的，但能達到提升網站的速度。

咱們的應用：

目前還沒用到，不過據客戶反映，廣東山東等地網絡狀況比較差，若是能夠將佔據主要帶寬的靜態資源經過CDN發佈，相信能夠大大緩解目前網站訪問速度的問題。

法則3. 增長Expires Header

網頁內容正變得愈來愈豐富，這意味着更多的腳本文件、樣式表、圖像文件和Flash。首次訪問者將不得不面臨屢次HTTP請求，但經過使用Expires header，您能夠在客戶端緩存這些元素。這在後續訪問中避免了沒必要要的HTTP請求。Expires header最經常使用於圖像文件，可是它也應該用於腳本文件、樣式表和Flash。

瀏覽器（和代理）使用緩存來減小HTTP請求的次數和大小，使得網頁加速裝載。Web server經過Expires header告訴客戶端一個元素能夠緩存的時間長度。

若是服務器是Apache的話，您可使用ExpiresDefault基於當期日期來設置過時日期，如：

ExpiresDefault 「access plus 10 years」 設置過時時間爲從請求時間開始計算的10年。

請記住，若是使用超長的過時時間，則當內容改變時，您必須修改文件名稱。在Yahoo!咱們常常把更名做爲release的一個步驟：版本號內嵌在文件名中，如yahoo_2.0.6.js。

咱們的應用：

外貿：在Apache配置了JS,CSS,image的緩存，若是靜態資源須要更新，則採用修改文件版本號的方案確保客戶端取得最新版本；

E網打盡：E網打盡的探頭規則（JS）是根據客戶的設置生成的，可是在至關長的一段時間內基本上不會有變化，所以，在生成規則的同時附加一個expires響應頭，儘可能減小客戶端的請求和探頭規則生成的次數。

法則4. 壓縮頁面元素

經過壓縮HTTP響應內容可減小頁面響應時間。從HTTP/1.1開始，web客戶端在HTTP請求中經過Accept-Encoding頭來代表支持的壓縮類型，如：

Accept-Encoding: gzip, deflate.

若是Web server檢查到Accept-Encoding頭，它會使用客戶端支持的方法來壓縮HTTP響應，會設置Content-Encoding頭，如：Content-Encoding: gzip。

Gzip是目前最流行及有效的壓縮方法。其餘的方式如deflate，但它效果較差，也不夠流行。經過Gzip，內容通常可減小70%。若是是Apache，在1.3版本下需使用mod_gzip模塊，而在2.x版本下，則需使用mod_deflate。

Web server根據文件類型來決定是否壓縮。大部分網站對HTML文件進行壓縮。但對腳本文件和樣式表進行壓縮也是值得的。實際上，對包括XML和JSON在內的任務文本信息進行壓縮都是值得的。圖像文件和PDF文件不該該被壓縮，由於它們原本就是壓縮格式保存的。對它們進行壓縮，不但浪費CPU，並且還可能增長文件的大小。

所以，對儘可能多的文件類型進行壓縮是一種減小頁面大小和提升用戶體驗的簡便方法。

咱們的應用：

外貿、E網打盡、K計劃：600多K的ext2包，是人都會想到要去壓縮它，壓縮後的效果還不錯，只有150多K。另外，JS、CSS、HTML也儘可能壓縮，要知道咱們的不少客戶還在使用1M的ADSL。

法則5. 把樣式表放在頭上

咱們發現把樣式表移到HEAD部分能夠提升界面加載速度，所以這使得頁面元素能夠順序顯示。

在不少瀏覽器下，如IE，把樣式表放在document的底部的問題在於它禁止了網頁內容的順序顯示。瀏覽器阻止顯示以避免重畫頁面元素，那用戶只能看到空白頁了。Firefox不會阻止顯示，但這意味着當樣式表下載後，有些頁面元素可能須要重畫，這致使閃爍問題。

HTML規範明確要求樣式表被定義在HEAD中，所以，爲避免空白屏幕或閃爍問題，最好的辦法是遵循HTML規範，把樣式表放在HEAD中。

咱們的應用：

目前尚未碰到把樣式表放在文檔後面的狀況吧？

法則6. 把腳本文件放在底部

與樣式文件同樣，咱們須要注意腳本文件的位置。咱們需儘可能把它們放在頁面的底部，這樣一方面能順序顯示，另方面可達到最大的並行下載。

瀏覽器會阻塞顯示直到樣式表下載完畢，所以咱們須要把樣式表放在HEAD部分。而對於腳原本說，腳本後面內容的順序顯示將被阻塞，所以把腳本儘可能放在底部意味着更多內容能被快速顯示。

腳本引發的第二個問題是它阻塞並行下載數量。HTTP/1.1規範建議瀏覽器每一個主機的並行下載數不超過2個。所以若是您把圖像文件分佈到多臺機器的話，您能夠達到超過2個的並行下載。可是當腳本文件下載時，瀏覽器不會啓動其餘的並行下載，甚至其餘主機的下載也不啓動。

在某些狀況下，不是很容易就能把腳本移到底部的。如，腳本使用document.write方法來插入頁面內容。同時可能還存在域的問題。不過在不少狀況下，仍是有一些方法的。

一個備選方法是使用延遲腳本（deferred script）。DEFER屬性代表腳本未包含document.write，指示瀏覽器刻繼續顯示。不幸的是，Firefox不支持DEFER屬性。在IE中，腳本可能被延遲執行，但不必定獲得須要的長時間延遲。不過從另外角度來講，若是腳本能被延遲執行，那它就能夠被放在底部了。

咱們的應用：

這點以前你們可能都沒有意識到，不過在咱們的XCube XUI中咱們已經實施了這條法則，相信能夠進一步提高頁面的訪問性能。

法則7. 避免CSS表達式

CSS表達式是功能強大的(同時也是危險的)用於動態設置CSS屬性的方式。IE，從版本5開始支持CSS表達式，如backgourd-color: expression((new Date()).getHours()%2?」#B8D4FF」:」#F08A00」)，即背景色每一個小時切換一次。

CSS表達式的問題是其執行次數超過大部分人的指望。不只頁面顯示和resize時計算表達式，並且當頁面滾屏，甚至當鼠標在頁面上移動時都會從新計算表達式。

一種減小CSS表達式執行次數的方法是一次性表達式，即當第一次執行時就以明確的數值代替表達式。若是必須動態設置的話，可以使用事件處理函數代替。若是您必須使用CSS表達式的話，請記住它們可能被執行上千次，從而影響頁面性能。

咱們的應用：

目前CSS的維護工做主要由UI人員負責，他們已經儘可能在避免這種狀況了。

法則8. 把JavaScript和CSS放到外部文件中

上述不少性能優化法則都基於外部文件進行優化。如今，咱們必須問一個問題：JavaScript和CSS應該包括在外部文件，仍是在頁面文件中？

在現實世界中，使用外部文件會加快頁面顯示速度，由於外部文件會被瀏覽器緩存。若是內置JavaScript和CSS在頁面中雖然會減小HTTP請求次數，但增大了頁面的大小。另一方面，使用外部文件，會被瀏覽器緩存，則頁面大小會減少，同時又不增長HTTP請求次數。

所以，通常來講，外部文件是更可行的方式。惟一的例外是內嵌方式對主頁更有效，如Yahoo!和My Yahoo!都使用內嵌方式。通常來講，在一個session中，主頁訪問此時較少，所以內嵌方式能夠取得更快的用戶響應時間。

咱們的應用：

外貿、E網打盡、K計劃：ext2的代碼做了很好的引導，目前前端開發人員都很是注意客戶端模塊的封裝、重用，儘可能之外部JS的方式提升代碼的重用度，固然也要注意不要引入過多的外部資源，由於這違反了法則1。
目前CSS的封裝也不錯，可是主要是針對IE系列的解決方案，能夠考慮引入YAML、blueprint等CSS框架，輕鬆解決瀏覽器兼容性問題。

法則9. 減小DNS查詢次數

DNS用於映射主機名和IP地址，通常一次解析須要20～120毫秒。爲達到更高的性能，DNS解析一般被多級別地緩存，如由ISP或局域網維護的caching server，本地機器操做系統的緩存（如windows上的DNS Client Service），瀏覽器。IE的缺省DNS緩存時間爲30分鐘，Firefox的缺省緩衝時間是1分鐘。

減小主機名可減小DNS查詢的次數，但可能形成並行下載數的減小。避免DNS查詢可減小響應時間，而減小並行下載數可能增長響應時間。一個可行的折中是把內容分佈到至少2個，最多4個不一樣的主機名上。

咱們的應用：

外貿：爲了繞開瀏覽器對下載線程數的限制，咱們對靜態資源啓用了多域名，可是這麼作違反了該法則。不過，對windows IE來講，DNS的緩存能夠緩解該問題。

法則10. 最小化JavaScript代碼

最小化JavaScript代碼指在JS代碼中刪除沒必要要的字符，從而下降下載時間。兩個流行的工具是#JSMin 和YUI Compressor。

混淆是最小化於源碼的備選方式。象最小化同樣，它經過刪除註釋和空格來減小源碼大小，同時它還能夠對代碼進行混淆處理。做爲混淆的一部分，函數名和變量名被替換成短的字符串，這使得代碼更緊湊，同時也更難讀，使得難於被反向工程。Dojo Compressor (ShrinkSafe)是最多見的混淆工具。

最小化是安全的、直白的過程，而混淆則更復雜，並且容易產生問題。從對美國10大網站的調查來看，經過最小化，文件可減小21%，而混淆則可減小25%。

除了最小化外部腳本文件外，內嵌的腳本代碼也應該被最小化。即便腳本根據法則4被壓縮後傳輸，最小化腳本刻減小文件大小5%或更高。

咱們的應用：

咱們沒有直接使用JS壓縮，可是咱們用的許多組件例如ext二、jquery等，已經在爲咱們實踐該法則。

法則11. 避免重定向

重定向功能是經過301和302這兩個HTTP狀態碼完成的，如：

      HTTP/1.1 301 Moved Permanently

      Location: http://example.com/newuri

      Content-Type: text/html

瀏覽器自動重定向請求到Location指定的URL上，重定向的主要問題是下降了用戶體驗。

一種最耗費資源、常常發生而很容易被忽視的重定向是URL的最後缺乏/，如訪問http://astrology.yahoo.com/astrology將被重定向到http://astrology.yahoo.com/astrology/。在Apache下，能夠經過Alias，mod_rewrite或DirectorySlash等方式來解決該問題。

咱們的應用：

經驗豐富的SA已經爲咱們考慮了這個問題，有興趣的同窗能夠看看線上環境的Apache配置文件：httpd.conf。

法則12. 刪除重複的腳本文件

在一個頁面中包含重複的JS腳本文件會影響性能，即它會創建沒必要要的HTTP請求和額外的JS執行。

沒必要要的HTTP請求發生在IE下，而Firefox不會產生多餘的HTTP請求。額外的JS執行，無論在IE下，仍是在Firefox下，都會發生。

一個避免重複的腳本文件的方式是使用模板系統來創建腳本管理模塊。除了防止重複的腳本文件外，該模塊還能夠實現依賴性檢查和增長版本號到腳本文件名中，從而實現超長的過時時間。

咱們的應用：

舊版本的Xplatform中這個問題比較嚴重，不過相信新版的XCube不會重蹈覆轍。

法則13. 配置ETags

ETags是用於肯定瀏覽器緩存中元素是否與Web server中的元素相匹配的機制，它是比last-modified date更靈活的元素驗證機制。ETag是用於惟一表示元素版本的字符串，它需被包括在引號中。Web server首先在response中指定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給Web server，若是ETag匹配，則服務器返回304代碼，從而節省了下載時間：

      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

ETags的問題在於它們是基於服務器惟一性的某些屬性構造的，如Apache1.3和2.x，其格式是inode-size-timestamp，而在IIS5.0和6.0下，其格式是Filetimestamp:ChangeNumber。這樣同一個元素在不一樣的web server上，其ETag是不同的。這樣在多Web server的環境下，瀏覽器先從server1請求某元素，後來向server2驗證該元素，因爲ETag不一樣，因此緩存失效，必須從新下載。

所以，若是您未用到ETags系統提供的靈活的驗證機制，最好刪除ETag。刪除ETag會減小http response及後續請求的HTTP頭的大小。微軟支持文章描述瞭如何刪除ETags，而在Apache下，只要在配置文件中設置FileETag none便可。

咱們的應用：

E網打盡：自定義ETag的生成策略，以儘可能減小探頭規則的生成次數。因爲不是採用服務器默認的ETag，不存在該問題。

其餘產品線：要注意了，這點你們都沒有關注過吧，趕快檢查一下Apache中的配置。

法則14. 緩存Ajax

性能優化法則一樣適用於web 2.0應用。提升Ajax的性能最重要的方式是使得其response可緩存，就象「法則3增長Expires Header」討論的那樣。如下其餘法則一樣適用於Ajax，固然法則3是最有效的方式:

法則4. 壓縮頁面元素

法則9. 減小DNS查詢次數

法則10. 最小化腳本文件

法則11. 避免重定向

法則13. 配置ETags.

咱們的應用：

更多狀況下，咱們倒不但願Ajax請求被緩存，此時爲每一個Ajax請求的url附加一個時間戳就能夠了。