右擊 -> 檢視源檔案，和其他一些前端性能測試技巧

　　● 作者的研究表明，網頁響應時間約80%-90%是由前端設計決定的。而我的經驗中，這個數字更應該是50%-80%，但我的經驗多來自于那些被重新設計為web架構的多使用者應用，或者是那些有着嚴重後端性能問題的應用（請我來定位問題）。

　 　結合上面幾點，你将得知，沒有人關注頁面上的可能存在的性能優化，而這種優化很可能是最容易實作，效果卻又最明顯的。讀了這本書我發現，我經常對大多數 的前端性能問題進行測試，但自己卻沒有意識到。作者提到的一些内容，我可能永遠也不會想到去測試，不對這些内容進行更主動的測試是個錯誤，這些測試的成本 是非常低的，無論是在時間上，還是在所需的工具和資源上。實際上，在測試網站的時候，我經常拿出整個性能測試的前15分鐘來完成大部分的前端測試，雖然我 承認，15分鐘隻夠測試幾個頁面。

　　● 免費或者開源的負載生成工具

　　　　○ 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/)

　　有了這些，讓我們來看一些你隻需看完本文能做的測試，這些測試隻需在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%甚至更 多。我确信，一旦你有了自己的工具箱、插件和助手網站，并且實際的練過幾次之後，你隻需花費比讀這篇文章更少的時間，就能檢查一個網站是否有這些問題了。 有了這麼大性能優化的可能性，又在時間和工具上投入這麼少，我實在是找不到任何不進行這些測似的理由。

====================================分割線================================

最新内容請見作者的github頁：http://qaseven.github.io/