最近讀了Steve Souders的High Performance
Web Sites： Essential Knowledge for Frontend Engineers（O’Reilly， 2007），這本書的副標題是 “14 Steps to Faster-Loading Web Sites”。在你發現此書面向對象為開發人員，從而停止閱讀之前，考慮以下幾點：
● 作者的研究表明，網頁響應時間約80%-90%是由前端設計決定的。而我的經驗中，這個數字更應該是50%-80%，但我的經驗多來自于那些被重新設計為WEB架構的多用戶應用，或者是那些有著嚴重后端性能問題的應用（請我來定位問題）。
● 和性能測試人員有關的幾乎所有的工具、培訓、文章和會議，都集中在系統的后端。以至于大部分人認為，系統的前端性能無需擔心，因為我們無法控制客戶端的系統。
● 根據我的經驗，網站的前端設計和開發，幾乎不會考慮到性能問題，除了盡量減小圖片的大小。我也從未讓團隊做過客戶端頁面的HTML代碼審查，從未在這些代碼上做過單元測試，也從未見過測試人員有意的對HTML進行一些性能測試。
結合上面幾點，你將得知，沒有人關注頁面上的可能存在的性能優化，而這種優化很可能是最容易實現，效果卻又最明顯的。讀了這本書我發現，我經常對大多數 的前端性能問題進行測試，但自己卻沒有意識到。作者提到的一些內容，我可能永遠也不會想到去測試，不對這些內容進行更主動的測試是個錯誤，這些測試的成本 是非常低的，無論是在時間上，還是在所需的工具和資源上。實際上，在測試網站的時候，我經常拿出整個性能測試的前15分鐘來完成大部分的前端測試，雖然我 承認，15分鐘只夠測試幾個頁面。
通過這篇文章，我講解了如何通過手工、負載生成工具、網絡協議分析工具、助手網站以及瀏覽器插件，來進行測試。我已經通過以下免費工具（不是免費試用版，是無任何限制的免費版）完成了這些工作。 如果你的公司不允許使用免費軟件，我相信只要簡單的搜索一下，就可以找到一堆可以替代的工具，這些工具將花費你公司足夠多的錢，從而讓他們重視。（如果你 認為這只是個笑話，很可惜它不是。在咨詢過我的團隊和接受我培訓的個人中，有超過50%的人說過不允許在公司的機器和網絡上使用免費、開源、共享、甚至是 有時間限制的免費試用版軟件。）
● 免費或者開源的負載生成工具
○ JMeter (http://jakarta.apache.org/jmeter/)
○ WebLoad (http://www.webload.org/)
○ OpenSTA (http://www.opensta.org/)
● 免費或者開源的網絡協議分析工具
○ Ethereal (http://www.ethereal.com/)
○ Fiddler (http://www.fiddlertool.com/)
● 免費的瀏覽器插件
○ Firebug (http://www.getfirebug.com/) with YSlow (http://developer.yahoo.com/yslow/) for Firefox
○ HttpWatch (http://www.httpwatch.com) for IE
● 免費的助手網站
○ Web Page Analyzer - from Website Optimization: Free Website Performance Tool and Web Page Speed Analysis (http://www.websiteoptimization.com/services/analyze/)
○ Gomez Instant Site Test (http://www.gomez.com/info_center/instant_test.php)
有了這些，讓我們來看一些你只需看完本文能做的測試，這些測試只需在web層面上即可進行，卻可能會顯著的改善終端用戶的響應時間。
HTTP請求數
頁面的獲取不是在一個事務中完成的。通常HTML文件需要一個請求，樣式表需要一個或多個請求，外部腳本需要一個或多個請求，圖片、多媒體內容、以及第 三方那個內容如廣告等需要多個請求。即使很多對象已經存在于瀏覽器緩存中了，還是需要頻繁的向服務器發送請求，以確認緩存中的對象是否“fresh”。這 意味著頁面上的每一個對象都十分可能會增加負擔，進而在用戶視角上降低了了性能，即使客戶端的瀏覽器已經緩存了所需的對象。如下幾種途徑，可以確定頁面發 送了多少個請求，以及請求的內容。
無論你用哪種方法，你將首先清除掉瀏覽器的緩存，或者訪問頁面兩次（一次通過ctrl + F5來強制刷新緩存）以確保能夠看到所有的請求。因為這些方法只能收集到真實的請求，如果不清除或刷新緩存可能會導致一些遺漏，讓你以為沒有去請求一些樣 式表、腳本、圖片和多媒體內容，很多配置或條件會對此產生影響，而你可能不知道要去設置這些。
1、如果你使用了負載生成工具或者網絡協 議分析工具，你可以直接開始錄制了，然后瀏覽感興趣的頁面。在你錄制的內容中尋找“GET”語句，看一下請求了什么。記住，有些工具，錄制下來的腳本默認 只顯示基礎的HTML請求，不包括子請求（對樣式表、圖片、腳本等的請求），如果要看到所有的請求需要進一步的設置。
2、如果你的測試環境允許裝瀏覽器插件，那么有好幾種方法可以使這個工作變得簡單。根據你所用的瀏覽器，或者希望測的瀏覽器，我推薦：
a）FireFox：FireBug+YSlow
b）IE： HttpWatch
3、如果你無法使用任何工具，你仍將有幾種選擇：
a）訪問上面列出的一個助手網站，輸入你想測試的頁面的URL，點提交。
b）FireFox中，右擊頁面，選Page Info，導航至Media Tab。注意，這個方法不會顯示腳本和樣式表，但會顯示出請求的圖片和其他多媒體內容。
c）IE中，右擊頁面然后選擇View Source。這里，你需要搜尋“link”和“img”字段。如果你找到了樣式表的連接（到.css文件的連接），你還需要手動的下載每個樣式表，然后 在其中搜索“url”字樣，因為這些可能會用來請求腳本、圖片和多媒體內容。（這是目前為止最笨的方法，但仍能為你提供信息）
有了你的請求列表以后，第一件事要做的就是看看數量——過多的請求會讓頁面變慢。有如下幾個指標來判斷是否是過多的請求。
1、外部樣式表請求多于一個。確實有一些時候是應該將頁面樣式拆分成幾個樣式表，但這情況并不常見，而且對性能顯然沒有好處。一般來說，只有當有一個主樣式表應用到很多頁面，第二個大的樣式表只應用到幾個頁面時，保留多于一個樣式表才是個好方法。
2、同一域中腳本的請求多于一個。雖然連接多個外部腳本比連接多個樣式表有更好的理由，多個外部腳本連接比 一個連接性能更好，仍然是不常見的。如果你測試的頁面是一個復雜的數據輸入表單，那么將表單的驗證腳本同其他頁面的通用腳本分離可能會有些意義。這樣做會 減少其他頁面（除了表單）的大小，從而改善那些頁面的性能，但多出的請求還是會輕微的降低表單頁面的性能。不管如何，多于一個外部腳本，至少是值得注意一 下的。
3、大量的圖片。我沒法說“大量的”是多少，但我可以告訴你，IE7和FireFox 2.x默認每主機名可以有2個并行下載（HTTP/1.1，大部分新網站都是）。這意味著，不管你的圖片大小是多少，瀏覽器一次只能下載兩個，只有當之前 的兩個都處理完，才會開始接下來的兩個。在HTTP/1.0中是不同的，FireFox默認每主機名可以有8并行下載，IE各版本不同，但肯定不會低于 2。這種變化產生的效果就是，使用類似大小但是數量最少的圖片易于產生最佳的性能。這和小圖片總是好的那種觀點是相反的。將幾個小圖片合成一個或兩個大些 的圖片，通常會改善性能。當然，這就又會出現一個臨界點。圖片大小和圖片的數量是值得前端工程師仔細研究的，測試多種選擇以達到最佳性能。有一個廣受好評 的“rull-of-thumb”（提供類似問題的指導），奉勸當一個頁面超過12個請求時，一定要謹慎。Souders的這本書和Andrew B. King的in Speed Up Your Site： Web Site Optimization（New Riders， 2003）中都采用了這個數字，而Aaron Hopkins在網站上發表的文章“Optimizing Page Load Time”讓這個數字更有說服力。
HTTP請求的順序
很多類似的方法都可以用來確定頁面上請求的順序（前面提到的助手網站和FireFox的“Page Info”除外，為了突出數量和大小等問題，將請求按類型或者大小進行了分組和排序）。我們所關注的順序是：
1、首先請求樣式表。在樣式表下載完之前，頁面是不會顯示的。或者是下載完樣式表要重新刷新頁面。基于這一點，讓樣式表在HTML頁面之后第一批請求是非常重要的。
2、最后請求腳本（至少是要靠后）。當開始請求一個腳本的時候，在腳本完全下載完之前不會再發出對其他對象 的請求。此外，腳本下載過程中，瀏覽器將暫停顯示頁面內容。這意味著在腳本下載過程中完成的任何對象的下載，都不會被顯示出來，從而給人感覺頁面的展現停 止了。所以一定要把腳本的請求放到用戶最感興趣的對象之后。記住，大多數用戶眼中的響應速度是由他們感興趣的內容決定的，而不是整個頁面的載入時間。
不管你是看HTML源文件還是錄制請求，你需要關注的就是樣式表最先被請求，腳本在最后或者至少是非常靠后時請求。有一個常見的爭論，說負責與 用戶交互的腳本（如圖像映射、對象反轉）應該早些被請求，這樣用戶會有更好的體驗，即便整個頁面還正在下載過程中。但我的經驗里，由于下載而產生的頁面停 止比無法獲得圖像映射、對象反轉功能更容易使用戶變得焦躁甚至是離開頁面。
重定向和隱藏錯誤
你仍然可以使用相同的方法來檢查重定向問題（3xx狀態碼），客戶錯誤（4xx），和服務器錯誤（5xx）。這里，你關注的信息是：
1、過多的3xx。3xx狀態表示，請求被處理了，但是瀏覽器需要到另一個地址去獲取所需對象，這就產生了 附加的請求和響應。雖然有很多的原因可以使用重定向，檢查一下是否有意使用和存在好理由還是值得做的。比如，將一個刪除掉的頁面重定向到新地址，或者將明 顯拼錯的頁面重定向到正確的地址，這就是個好的使用理由。圖片的父級目錄被移動了，沒有人去維護更新鏈接，這就不是一個需要使用重定向、從而接受一些性能 下降的好理由。
2、任何4xx。用戶的請求有問題時就會返回4xx狀態碼。最常見的是404，表示服務器上找不到被請求的對象。一般說來，如果頁面的顯示和功能都正常，但請求卻返回了4xx，那就說明頁面請求了不需要的對象，也耗費了多余的時間。
3、任何5xx。5xx表示處理請求時，服務器上發生了錯誤。任何5xx的狀態都需要開發團隊注意。
我將這些都稱作隱藏錯誤，是因為當它們發生在非主HTML上時，用戶通常是察覺不到的。有時，這些狀態碼預示著有更深層的錯誤，但是無論如何，它們都導致了與頁面內容無關的請求，這些請求通常也都是完全沒有必要的。
HTTP響應頭 要檢查HTTP響應頭，需要使用負載生成工具、網絡分析工具或者是瀏覽器插件。如果你沒有這些工具，一個助手網站可以幫到你。我推薦Peter Forret的網站“View and analyze HTTP headers” （http：//web.forret.com/tools/analyze.aspx），你只需輸入頁面的URL，網站就會獲取到web服務器返回的一 系列HTTP頭，這樣就可以檢查頁面過期和緩存等配置了。至于具體哪些是合適的、哪些是不不要的性能損失，這是和很多內容息息相關的，如網頁和對象變化的 頻率、用戶訪問網站的頻率、還有用戶看到過時內容的相對風險。但是不管怎樣，下面的這些是永遠值得檢查的：
1、過期時間是否恰當。如果一個對象的HTTP響應中沒有過期時間這行，每次用戶請求包含這個對象的頁面 時，都會向服務器發送一個請求，來判斷緩存的這個版本是否“新鮮”。如果你有一些不易過期的對象（如公司的Logo），你可以通過設置一個未來很遠的日期 來避免這種有效性檢查。過期時間最多應用在圖片上，但在腳本、樣式表、AJAX和FLASH等內容上也經常是適用的。檢查一下沒有過期時間的對象吧，看看 是不是有不合適的。
2、ETags是否恰當。ETags是一種web服務器和瀏覽器使用的認證手段，用來判斷客戶機器上緩存的 對象是否和服務器上的匹配。使用ETags的問題在于，它們對于一個特定的服務器通常是唯一的，這意味著如果網站有多個web服務器，ETags是會出現 問題的。如果你確定只有一個web服務器，那么使用ETags是個不錯的主意。如果是多個服務器，你就必須查明是否考慮到了這點，或者干脆建議不使用 ETags。
3、其他緩存控制。你可能會看到類似的內容，Cache-Control、Last-Modified、Pragma、Set-Cookie、Age。如果你看到了，那么確保這些配置是有意義的。如果沒有找到，而你又覺得應該有這些東西，那么找人看一下吧。
說到底，其實本質內容就是你要檢查HTTP響應頭，來判斷網站是否已被合理配置來利用瀏覽器的緩存。通常，判斷這些配置是否恰當的唯一方法，是同管理員和架構師探討網站是如何使用的、以及是如何設計的，尤其是和瀏覽器緩存有關的地方。
源文件和其他對象
最后，如果你沒以前沒做過這些，你需要手工檢查HTML源文件、css、腳本、圖片以及其他對象。到現在，我還沒發現任何一款能夠節省我們的時 間、對各種情況做出充分檢查、并對前端性能提出建議的工具，雖然一些網站使用的HTML、腳本、圖片的編輯器還是有一些幫助的。最后，關于前端性能測試， 我的建議是：
1、確保腳本和CSS沒有寫在HTML源文件中。將腳本和CSS直接寫在HTML中來提高性能，幾乎是不可 能的。原因很簡單：網頁的主HTML是更新最為頻繁的部分之一，因此從緩存中受益最少。既然HTML很可能每次都要下載，只有盡量減小大小才是上策。將腳 本和CSS與HTML分離，以便利用緩存，是肯定會提高性能的。
2、確保樣式和腳本不重復。樣式和腳本包含重復內容是非常惡心的。有時，不同的文件中有重復內容，有時在同一個文件中就會重復。你可能不想花費時間去做一個全面檢查，那么只需快速的掃描一遍源文件，經常就能發現是否存在明顯的重復。
3、檢查代碼最小化。最小化，指壓縮和優化代碼，讓相關功能使用最少的代碼行數。當檢查HTML源文件、外部腳本和樣式表時，需要注意過多的注釋、空格、換行、變量名長度、以及其他能夠增加文件大小的內容。
4、檢查圖片的大小和壓縮。雖然大家都明白，仍然還有很多網頁設計者使用這樣一些圖片格式，要么有不必要的 文件大小、要么是同顯示尺寸不同的尺寸、要么就是超過了所需要的品質。通常，GIF格式的圖片是被壓縮成64位甚至更少顏色的，它們完全滿足大部分的圖片 和縮略圖；JPG格式的圖片被壓縮成256位或者更少，對于照片來說也完全夠用；通過HTML的height/width屬性來縮放圖片，不如創建再一個 新的大小的圖片。
這些內容，靠常識判斷即可。例如，一些網站將所有的文件、目錄以及變量的名字減少到兩個甚至更少的字符，將這作為一種減小文件大小的策略。從純 粹的性能角度來看，這是好的；但是，對大多數網站來說，維持這些東西所產生的工作量完全抹殺了它的價值。你需要同團隊一起，在去重、最小化、壓縮和實用性 之間找到一個平衡點。
總結
本文介紹了幾種測試，可以用來判斷網站是否可能會出現前端性能問題。檢查這些可能的性能優化，可能會讓用戶感受到的響應時間提升50%甚至更 多。我確信，一旦你有了自己的工具箱、插件和助手網站，并且實際的練過幾次之后，你只需花費比讀這篇文章更少的時間，就能檢查一個網站是否有這些問題了。 有了這么大性能優化的可能性，又在時間和工具上投入這么少，我實在是找不到任何不進行這些測似的理由。