最近，YouMonitor.Us在做Web應(yīng)用性能優(yōu)化，在網(wǎng)上發(fā)現(xiàn)了文章High Performance Web Sites: The Importance of Front-End Performance，感覺其14條優(yōu)化法則很實用，操作性很強。因此翻譯出來，供大家參考。

<o:p> </o:p>

Web應(yīng)用性能優(yōu)化黃金法則：先優(yōu)化前端程序(front-end)的性能，因為這是80%或以上的最終用戶響應(yīng)時間的花費所在。<o:p></o:p>

法則1. 減少HTTP請求次數(shù)

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

一種減少頁面元素個數(shù)的方法是簡化頁面設(shè)計。但是否存在其他方式，能做到既有豐富內(nèi)容，又能獲得快速響應(yīng)時間呢？以下是這樣一些技術(shù)：

Image maps組合多個圖片到一張圖片中?？偽募笮∽兓淮?，但減少了HTTP請求次數(shù)從而加快了頁面顯示速度。該方式只適合圖片連續(xù)的情況；同時坐標的定義是煩人又容易出錯的工作。

CSS Sprites是更好的方法。它可以組合頁面中的圖片到單個文件中，并使用CSS的background-image和background-position屬性來現(xiàn)實所需的部分圖片。

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

Combined files通過組合多個腳本文件到單一文件來減少HTTP請求次數(shù)。樣式表也可采用類似方法處理。這個方法雖然簡單，但沒有得到大規(guī)模的使用。10大美國網(wǎng)站每頁平均有7個腳本文件和2個樣式表。當頁面之間腳本和樣式表變化很大時，該方式將遇到很大的挑戰(zhàn)，但如果做到的話，將能加快響應(yīng)時間。

<o:p> </o:p>

減少HTTP請求次數(shù)是性能優(yōu)化的起點。這最提高首次訪問的效率起到很重要的作用。據(jù)Tenni Theurer的文章Browser Cache Usage - Exposed!描述，40-60%的日常訪問是首次訪問，因此為首次訪問者加快頁面訪問速度是用戶體驗的關(guān)鍵。

法則2. 使用CDN(Content Delivery Network, 內(nèi)容分發(fā)網(wǎng)絡(luò))

用戶離web server的遠近對響應(yīng)時間也有很大影響。從用戶角度看，把內(nèi)容部署到多個地理位置分散的服務(wù)器上將有效提高頁面裝載速度。但是該從哪里開始呢？

作為實現(xiàn)內(nèi)容地理分布的第一步，不要試圖重構(gòu)web應(yīng)用以適應(yīng)分布架構(gòu)。改變架構(gòu)將導致多個周期性任務(wù)，如同步session狀態(tài)，在多個server之間復制數(shù)據(jù)庫交易。這樣縮短用戶與內(nèi)容距離的嘗試可能被應(yīng)用架構(gòu)改版所延遲，或阻止。

我們還記得80-90%的最終用戶響應(yīng)時間花在下載頁面中的各種元素上，如圖像文件、樣式表、腳本和Flash等。與其花在重構(gòu)系統(tǒng)這個困難的任務(wù)上，還不如先分布靜態(tài)內(nèi)容。這不僅能大大減少響應(yīng)時間，而且由于CDN的存在，分布靜態(tài)內(nèi)容非常容易實現(xiàn)。

CDN是地理上分布的web server的集合，用于更高效地發(fā)布內(nèi)容。通?；诰W(wǎng)絡(luò)遠近來選擇給具體用戶服務(wù)的web server。

一些大型網(wǎng)站擁有自己的CDN，但是使用如Akamai Technologies, Mirror Image Internet, 或 Limelight Networks等CDN服務(wù)提供商的服務(wù)將是劃算的。在Yahoo!把靜態(tài)內(nèi)容分布到CDN減少了用戶影響時間20%或更多。切換到CDN的代碼修改工作是很容易的，但能達到提高網(wǎng)站的速度。

法則3. 增加Expires Header

網(wǎng)頁內(nèi)容正變得越來越豐富，這意味著更多的腳本文件、樣式表、圖像文件和Flash。首次訪問者將不得不面臨多次HTTP請求，但通過使用Expires header，您可以在客戶端緩存這些元素。這在后續(xù)訪問中避免了不必要的HTTP請求。Expires header最常用于圖像文件，但是它也應(yīng)該用于腳本文件、樣式表和Flash。

瀏覽器（和代理）使用緩存來減少HTTP請求的次數(shù)和大小，使得網(wǎng)頁加速裝載。Web server通過Expires header告訴客戶端一個元素可以緩存的時間長度。

如果服務(wù)器是Apache的話，您可以使用ExpiresDefault基于當期日期來設(shè)置過期日期，如：

ExpiresDefault “access plus 10 years” 設(shè)置過期時間為從請求時間開始計算的10年。

請記住，如果使用超長的過期時間，則當內(nèi)容改變時，您必須修改文件名稱。在Yahoo!我們經(jīng)常把改名作為release的一個步驟：版本號內(nèi)嵌在文件名中，如yahoo_<st1:chsdate month="12" islunardate="False" day="30" year="1899" w:st="on" isrocdate="False">2.0.6</st1:chsdate>.js。

法則4. 壓縮頁面元素

通過壓縮HTTP響應(yīng)內(nèi)容可減少頁面響應(yīng)時間。從HTTP/1.1開始，web客戶端在HTTP請求中通過Accept-Encoding頭來表明支持的壓縮類型，如：

Accept-Encoding: gzip, deflate.

如果Web server檢查到Accept-Encoding頭，它會使用客戶端支持的方法來壓縮HTTP響應(yīng)，會設(shè)置Content-Encoding頭，如：Content-Encoding: gzip。

Gzip是目前最流行及有效的壓縮方法。其他的方式如deflate，但它效果較差，也不夠流行。通過Gzip，內(nèi)容一般可減少70%。如果是Apache，在1.3版本下需使用mod_gzip模塊，而在2.x版本下，則需使用mod_deflate。

Web server根據(jù)文件類型來決定是否壓縮。大部分網(wǎng)站對HTML文件進行壓縮。但對腳本文件和樣式表進行壓縮也是值得的。實際上，對包括XML和JSON在內(nèi)的任務(wù)文本信息進行壓縮都是值得的。圖像文件和PDF文件不應(yīng)該被壓縮，因為它們本來就是壓縮格式保存的。對它們進行壓縮，不但浪費CPU，而且還可能增加文件的大小。

因此，對盡量多的文件類型進行壓縮是一種減少頁面大小和提高用戶體驗的簡便方法。

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

我們發(fā)現(xiàn)把樣式表移到HEAD部分可以提高界面加載速度，因此這使得頁面元素可以順序顯示。

在很多瀏覽器下，如IE，把樣式表放在document的底部的問題在于它禁止了網(wǎng)頁內(nèi)容的順序顯示。瀏覽器阻止顯示以免重畫頁面元素，那用戶只能看到空白頁了。Firefox不會阻止顯示，但這意味著當樣式表下載后，有些頁面元素可能需要重畫，這導致閃爍問題。

HTML規(guī)范明確要求樣式表被定義在HEAD中，因此，為避免空白屏幕或閃爍問題，最好的辦法是遵循HTML規(guī)范，把樣式表放在HEAD中。

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

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

瀏覽器會阻塞顯示直到樣式表下載完畢，因此我們需要把樣式表放在HEAD部分。而對于腳本來說，腳本后面內(nèi)容的順序顯示將被阻塞，因此把腳本盡量放在底部意味著更多內(nèi)容能被快速顯示。

腳本引起的第二個問題是它阻塞并行下載數(shù)量。HTTP/1.1規(guī)范建議瀏覽器每個主機的并行下載數(shù)不超過2個。因此如果您把圖像文件分布到多臺機器的話，您可以達到超過2個的并行下載。但是當腳本文件下載時，瀏覽器不會啟動其他的并行下載，甚至其他主機的下載也不啟動。

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

一個備選方法是使用延遲腳本（deferred script）。DEFER屬性表明腳本未包含document.write，指示瀏覽器刻繼續(xù)顯示。不幸的是，Firefox不支持DEFER屬性。在IE中，腳本可能被延遲執(zhí)行，但不一定得到需要的長時間延遲。不過從另外角度來說，如果腳本能被延遲執(zhí)行，那它就可以被放在底部了。

法則7. 避免CSS表達式

CSS表達式是功能強大的(同時也是危險的)用于動態(tài)設(shè)置CSS屬性的方式。IE，從版本5開始支持CSS表達式，如backgourd-color: expression((new Date()).getHours()%2?”#B8D4FF”:”#F<st1:chmetcnv w:st="on" hasspace="False" negative="False" numbertype="1" sourcevalue="8" unitname="a" tcsc="0">08A</st1:chmetcnv><st1:chmetcnv w:st="on" hasspace="False" negative="False" numbertype="1" sourcevalue="0" unitname="”" tcsc="0">00”</st1:chmetcnv>)，即背景色每個小時切換一次。

CSS表達式的問題是其執(zhí)行次數(shù)超過大部分人的期望。不僅頁面顯示和resize時計算表達式，而且當頁面滾屏，甚至當鼠標在頁面上移動時都會重新計算表達式。

一種減少CSS表達式執(zhí)行次數(shù)的方法是一次性表達式，即當?shù)谝淮螆?zhí)行時就以明確的數(shù)值代替表達式。如果必須動態(tài)設(shè)置的話，可使用事件處理函數(shù)代替。如果您必須使用CSS表達式的話，請記住它們可能被執(zhí)行上千次，從而影響頁面性能。

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

上述很多性能優(yōu)化法則都基于外部文件進行優(yōu)化?，F(xiàn)在，我們必須問一個問題：JavaScript和CSS應(yīng)該包括在外部文件，還是在頁面文件中？

在現(xiàn)實世界中，使用外部文件會加快頁面顯示速度，因為外部文件會被瀏覽器緩存。如果內(nèi)置JavaScript和CSS在頁面中雖然會減少HTTP請求次數(shù)，但增大了頁面的大小。另外一方面，使用外部文件，會被瀏覽器緩存，則頁面大小會減小，同時又不增加HTTP請求次數(shù)。

因此，一般來說，外部文件是更可行的方式。唯一的例外是內(nèi)嵌方式對主頁更有效，如Yahoo!和My Yahoo!都使用內(nèi)嵌方式。一般來說，在一個session中，主頁訪問此時較少，因此內(nèi)嵌方式可以取得更快的用戶響應(yīng)時間。

法則9. 減少DNS查詢次數(shù)

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

減少主機名可減少DNS查詢的次數(shù)，但可能造成并行下載數(shù)的減少。避免DNS查詢可減少響應(yīng)時間，而減少并行下載數(shù)可能增加響應(yīng)時間。一個可行的折中是把內(nèi)容分布到至少2個，最多4個不同的主機名上。

法則10. 最小化JavaScript代碼

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

混淆是最小化于源碼的備選方式。象最小化一樣，它通過刪除注釋和空格來減少源碼大小，同時它還可以對代碼進行混淆處理。作為混淆的一部分，函數(shù)名和變量名被替換成短的字符串，這使得代碼更緊湊，同時也更難讀，使得難于被反向工程。Dojo Compressor (ShrinkSafe)是最常見的混淆工具。

最小化是安全的、直白的過程，而混淆則更復雜，而且容易產(chǎn)生問題。從對美國10大網(wǎng)站的調(diào)查來看，通過最小化，文件可減少21%，而混淆則可減少25%。

除了最小化外部腳本文件外，內(nèi)嵌的腳本代碼也應(yīng)該被最小化。即使腳本根據(jù)法則4被壓縮后傳輸，最小化腳本刻減少文件大小5%或更高。

法則11. 避免重定向

重定向功能是通過301和302這兩個HTTP狀態(tài)碼完成的，如：

      HTTP/1.1 301 Moved Permanently

      Location: http://example.com/newuri

      Content-Type: text/html

<o:p> </o:p>

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

一種最耗費資源、經(jīng)常發(fā)生而很容易被忽視的重定向是URL的最后缺少/，如訪問http://astrology.yahoo.com/astrology將被重定向到http://astrology.yahoo.com/astrology/。在Apache下，可以通過Alias，mod_rewrite或DirectorySlash等方式來解決該問題。

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

在一個頁面中包含重復的JS腳本文件會影響性能，即它會建立不必要的HTTP請求和額外的JS執(zhí)行。

不必要的HTTP請求發(fā)生在IE下，而Firefox不會產(chǎn)生多余的HTTP請求。額外的JS執(zhí)行，不管在IE下，還是在Firefox下，都會發(fā)生。

一個避免重復的腳本文件的方式是使用模板系統(tǒng)來建立腳本管理模塊。除了防止重復的腳本文件外，該模塊還可以實現(xiàn)依賴性檢查和增加版本號到腳本文件名中，從而實現(xiàn)超長的過期時間。

法則13. 配置ETags

ETags是用于確定瀏覽器緩存中元素是否與Web server中的元素相匹配的機制，它是比last-modified date更靈活的元素驗證機制。ETag是用于唯一表示元素版本的字符串，它需被包括在引號中。Web server首先在response中指定ETag：

      HTTP/1.1 200 OK

10c24bc-4ab-457e<st1:chmetcnv w:st="on" hasspace="False" negative="False" numbertype="1" sourcevalue="1" unitname="C" tcsc="0">1c</st1:chmetcnv><st1:chmetcnv w:st="on" hasspace="False" negative="False" numbertype="1" sourcevalue="1" unitname="F" tcsc="0">1f</st1:chmetcnv>"

      Content-Length: 12195

后來，如果瀏覽器需要驗證某元素，它使用If-None-Match頭回傳ETag給Web server，如果ETag匹配，則服務(wù)器返回304代碼，從而節(jié)省了下載時間：

      GET /i/yahoo.gif HTTP/1.1

      Host: us.yimg.com

10c24bc-4ab-457e<st1:chmetcnv w:st="on" hasspace="False" negative="False" numbertype="1" sourcevalue="1" unitname="C" tcsc="0">1c</st1:chmetcnv><st1:chmetcnv w:st="on" hasspace="False" negative="False" numbertype="1" sourcevalue="1" unitname="F" tcsc="0">1f</st1:chmetcnv>"

      HTTP/1.1 304 Not Modified

<o:p> </o:p>

ETags的問題在于它們是基于服務(wù)器唯一性的某些屬性構(gòu)造的，如Apache1.3和2.x，其格式是inode-size-timestamp，而在IIS5.0和6.0下，其格式是Filetimestamp:ChangeNumber。這樣同一個元素在不同的web server上，其ETag是不一樣的。這樣在多Web server的環(huán)境下，瀏覽器先從server1請求某元素，后來向server2驗證該元素，由于ETag不同，所以緩存失效，必須重新下載。

因此，如果您未用到ETags系統(tǒng)提供的靈活的驗證機制，最好刪除ETag。刪除ETag會減少http response及后續(xù)請求的HTTP頭的大小。微軟支持文章描述了如何刪除ETags，而在Apache下，只要在配置文件中設(shè)置FileETag none即可。

法則14. 緩存Ajax

性能優(yōu)化法則同樣適用于web 2.0應(yīng)用。提高Ajax的性能最重要的方式是使得其response可緩存，就象“法則3增加Expires Header”討論的那樣。以下其他法則同樣適用于Ajax，當然法則3是最有效的方式:

法則4. 壓縮頁面元素

法則9. 減少DNS查詢次數(shù)

法則10. 最小化腳本文件

法則11. 避免重定向

法則13. 配置ETags.