YUI前端優化之Server篇

2、網站Server 篇：使用內容分發網絡爲文件頭指定Expires或Cache-ControlGzip壓縮文件內容配置ETag儘早刷新輸出緩衝使用GET來完成AJAX請求

十一、使用內容分發網絡

      用戶與你網站服務器的接近程度會影響響應時間的長短。把你的網站內容分散到多個、處於不一樣地域位置的服務器上能夠加快下載速度。可是首先咱們應該作些什麼呢？

      按地域佈置網站內容的第一步並非要嘗試從新架構你的網站讓他們在分發服務器上正常運行。根據應用的需求來改變網站結構，這可能會包括一些比較複雜的任 務，如在服務器間同步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是一個只須要相對簡單 地修改代碼實現顯著改善網站訪問速度的方法。 

十二、爲文件頭指定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文件頭，增長了緩存在瀏覽器中內容的數量，而且能夠在用戶接下來的請求中再次使用這些內容，這甚至都不須要經過用戶發送一個字節的請求。 

1三、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壓縮全部可能的文件類型是減小文件體積增長用戶體驗的簡單方法。 

1四、配置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 

1五、儘早刷新輸出緩衝

      當用戶請求一個頁面時，不管如何都會花費200到500毫秒用於後臺組織HTML文件。在這期間，瀏覽器會一直空閒等待數據返回。在PHP中，你可使用 flush()方法，它容許你把已經編譯的好的部分HTML響應文件先發送給瀏覽器，這時瀏覽器就會能夠下載文件中的內容（腳本等）然後臺同時處理剩餘的 HTML頁面。這樣作的效果會在後臺煩惱或者前臺較空閒時更加明顯。

      輸出緩衝應用最好的一個地方就是緊跟在<head />以後，由於HTML的頭部分容易生成並且頭部每每包含CSS和JavaScript文件，這樣瀏覽器就能夠在後臺編譯剩餘HTML的同時並行下載它們。 例子： 

      ... <!-- css, js -->

    </head>

    <?php flush(); ?>

    <body>

      ... <!-- content -->

爲了證實使用這項技術的好處，，Yahoo!搜索率先研究並完成了用戶測試。 

1六、使用GET來完成AJAX請求

        Yahoo!Mail團 隊發現，當使用XMLHttpRequest時，瀏覽器中的POST方法是一個「兩步走」的過程：首先發送文件頭，而後才發送數據。所以使用GET最爲恰 當，由於它只需發送一個TCP包（除非你有不少cookie）。IE中URL的最大長度爲2K，所以若是你要發送一個超過2K的數據時就不能使用GET 了。

      一個有趣的不一樣就是POST並不像GET那樣實際發送數據。根據HTTP規範，GET意味着「獲取」數據，所以當你僅僅獲取數據時使用GET更加有意義（從語意上講也是如此），相反，發送並在服務端保存數據時使用POST。