<a href="http://www.cnblogs.com/softlover/articles/2789083.html#cdn">使用内容分發網絡</a>
<a href="http://www.cnblogs.com/softlover/articles/2789083.html#exipires">為檔案頭指定Expires或Cache-Control</a>
<a href="http://www.cnblogs.com/softlover/articles/2789083.html#zip">Gzip壓縮檔案内容</a>
<a href="http://www.cnblogs.com/softlover/articles/2789083.html#tag">配置ETag</a>
<a href="http://www.cnblogs.com/softlover/articles/2789083.html#flush">盡早重新整理輸出緩沖</a>
<a href="http://www.cnblogs.com/softlover/articles/2789083.html#get_ajax">使用GET來完成AJAX請求</a>
使用者與你網站伺服器的接近程度會影響響應時間的長短。把你的網站内容分散到多個、處于不同地域位置的伺服器上可以加快下載下傳速度。但是首先我們應該做些什麼呢?
按地域布置網站内容的第一步并不是要嘗試重新架構你的網站讓他們在分發伺服器上正常運作。根據應用的需求來改變網站結構,這可能會包括一些比較複雜的任務,如在伺服器間同步Session狀态和合并資料庫更新等。要想縮短使用者和内容伺服器的距離,這些架構步驟可能是不可避免的。
要記住,在終端使用者的響應時間中有80%到90%的響應時間用于下載下傳圖像、樣式表、腳本、Flash等頁面内容。這就是網站性能黃金守則。和重新設計你的應用程式架構這樣比較困難的任務相比,首先來分布靜态内容會更好一點。這不僅會縮短響應時間,而且對于内容分發網絡來說它更容易實作。
内容分發網絡(Content Delivery Network,CDN)是由一系列分散到各個不同地理位置上的Web伺服器組成的,它提高了網站内容的傳輸速度。用于向使用者傳輸内容的伺服器主要是根據和使用者在網絡上的靠近程度來指定的。例如,擁有最少網絡跳數(network hops)和響應速度最快的伺服器會被標明。
這條守則包括兩方面的内容:
對于靜态内容:設定檔案頭過期時間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。
網絡傳輸中的HTTP請求和應答時間可以通過前端機制得到顯著改善。的确,終端使用者的帶寬、網際網路提供者、與對等交換點的靠近程度等都不是網站開發者所能決定的。但是還有其他因素影響着響應時間。通過減小HTTP響應的大小可以節省HTTP響應時間。
從HTTP/1.1開始,web用戶端都預設支援HTTP請求中有Accept-Encoding檔案頭的壓縮格式:
Accept-Encoding: gzip, deflate
如果web伺服器在請求的檔案頭中檢測到上面的代碼,就會以用戶端列出的方式壓縮響應内容。Web伺服器把壓縮方式通過響應檔案頭中的Content-Encoding來傳回給浏覽器。
Content-Encoding: gzip
浏覽器和代理都會存在這樣的問題:浏覽器期望收到的和實際接收到的内容會存在不比對的現象。幸好,這種特殊情況随着舊式浏覽器使用量的減少在減少。Apache子產品會通過自動添加适當的Vary響應檔案頭來避免這種狀況的出現。
伺服器根據檔案類型來選擇需要進行gzip壓縮的檔案,但是這過于限制了可壓縮的檔案。大多數web伺服器會壓縮HTML文檔。對腳本和樣式表進行壓縮同樣也是值得做的事情,但是很多web伺服器都沒有這個功能。實際上,壓縮任何一個文本類型的響應,包括XML和JSON,都值得的。圖像和PDF檔案由于已經壓縮過了是以不能再進行gzip壓縮。如果試圖gizp壓縮這些檔案的話不但會浪費CPU資源還會增加檔案的大小。
Gzip壓縮所有可能的檔案類型是減少檔案體積增加使用者體驗的簡單方法。
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請求。
FileETag none
當使用者請求一個頁面時,無論如何都會花費200到500毫秒用于背景組織HTML檔案。在這期間,浏覽器會一直空閑等待資料傳回。在PHP中,你可以使用flush()方法,它允許你把已經編譯的好的部分HTML響應檔案先發送給浏覽器,這時浏覽器就會可以下載下傳檔案中的内容(腳本等)而背景同時處理剩餘的HTML頁面。這樣做的效果會在背景煩惱或者前台較空閑時更加明顯。
輸出緩沖應用最好的一個地方就是緊跟在<head />之後,因為HTML的頭部分容易生成而且頭部往往包含CSS和JavaScript檔案,這樣浏覽器就可以在背景編譯剩餘HTML的同時并行下載下傳它們。 例子:
… <!– css, js –>
</head>
<?php flush(); ?>
<body>
… <!– content –>
<a href="http://www.vancl.com/?source=kbh1983&sourcesuninfo=ad-3090-1-52-0-1" target="_blank"></a>