轉自：http://www.cnblogs.com/fnng/archive/2012/07/11/2587196.html       作者：蟲師

我的上一篇博文中講到了響應時間，我們在做效能測試時，能過工具可以遮蔽客戶端呈現時間，通過區域網的高寬頻可以忽略資料傳輸速度的障礙。這並不是說他們不會對系統造成效能影響。相反，從使用者的感受來看，雖然傳輸速度受使用者頻寬的限制。但我們可以通過很多技術來使使用者想要看到的頁面更快的顯示。這就web是前端效能。

　　如果考慮到web應用本身的特性，響應時間的構成應該會更加複雜。 

　　Web應用的基礎是超文字傳輸協議（HTTP）和超文字標記語言（HTML），HTTP

　　對於一個頁面而言，“請求”和“返回資料”都可能是多次發生的。這個我在《在做效能測試之前需要知道什麼》一文中舉了一個簡單的例子來講解。由於HTTP對瀏覽器下載資源併發請求數量、Cache等方面都進行定義和限制，以及瀏覽器對於HTML的處理過程。完全可以說，使用者所以感受的響應時間中的相當大的一部分並不完全取決於應用的後臺處理所需要的時間，而取決於web應用的前端。在yahoo中，到少50個團隊通過純粹的前端效能相關的技巧，將終端使用者的響應時間減少了25%以上。

　　HTTP是一個屬於應用層的面向物件的協議，用於傳送WWW方式的資料，採用請求

　　 HTML是一種用於製作超文字文件資料的簡單標記語言，用HTML編寫的超文字文件能夠獨立於各種作業系統平臺。從誕生開始，HTML語言就一直被用於描述web頁面格式設計，使用HTML語言描述的檔案需要通過WWW瀏覽器顯示效果。

用於檢視前端效能工具太多的。

　　嵌入瀏覽器的有 yslow 、page speed、httpwatch

　　獨立介面的有 fiddler2、charles 、

下面用兩種方式來對比較兩種測試響應時間的差別

　　Apache  benchmark 簡稱ab ，是非常有名又小巧的壓力測試工具。

　　下載安裝apache web server 安裝或解壓之後，在bin\目錄下有個ab執行檔案。

　　開啟執行--cmd 開啟命令提示符，定位到bin\目錄下。

基本用法：

ab  -c  [併發使用者數]  -n  [傳送請求數]   [被測試頁面的URL]

設定一個使用者一個請求，對百度首頁加壓：

http://www.baidu.com/

從上表中我們可以看到請求的總位元組數為8024位元組；響應時間為0.173 秒，也就是下面顯示的173.010毫秒。 

 ---------------------哥倫布哥----------------------------------------------------------------

Firebug非常有名的debug工具，firefox瀏覽器最得意的整合工具。

在firefox瀏覽選單欄“工具”---新增元件---搜尋firebug下載安裝重啟瀏覽器。

同樣對百度首頁的訪問：

http://www.baidu.com/

從上面圖中看到請求的大小為10KB；響應時間1.4秒。清楚的發現這資料可以遠遠大於ab工具所得到的資料。仔細觀察發現，firebug給出的資料，訪問 http://www.baidu.com/ 網址時，客戶端（瀏覽器）和應用之間的資料互動並非1次，而是5次。

　　我們再分析其中的一個請求，firefox給出的的圖形中，有紅色和藍色兩種顏色的線條。藍色表示到此刻發生了DOMContentLoaded事件。紅色線條表示onload事件被觸發。DOMContentLoaded事件W3C推薦的標準事件，它發生在頁面的DOM樹建成時，而onload則發生在頁面所有的資源（圖片檔案、CSS檔案、js檔案等）都被下載完成後。

　　從上圖的右下角，我們會得到兩個響應時間，1.41秒是onload事件被觸發的時間，前面的1.4秒則是頁面的所有請求都返回所需要的總時間。那麼哪個時間才是使用者感受到的響應時間呢？準確的說，兩個都不是。使用者的感受是個不確定的狀態，取決於頁面本身的型別以及呈現手段。如果某頁面僅為使用者提供閱讀資訊，一旦頁面上開始出現可供閱讀的內容，使用者就開始閱讀了。那麼，使用者認為響應時間就是發出請求到頁面上出現可閱讀資訊。如果頁面存在大量的互動內容，需要使用者填寫或在頁面上進行拖拽等操作，在這種情況下，只有當頁面的所有元素都被下正確的呈現出來，所有的js檔案都已經執行完成後，使用者才會感受到這個頁面已經就緒。

　　Web前端效能的研究並不是為了準確地得到一個響應時間資料，實際上，根據friebug圖表的結果，web效能一部分取決於web伺服器和應用伺服器（建立連線，下載連線），別一部分取決於瀏覽器的實現機制、web頁面上的js的執行等。取決於web伺服器和應用伺服器的響應時間與伺服器的負載、壓力等相關；而取決於瀏覽器實現機制與js檔案執行所需要的時間則幾乎與伺服器端的負載和壓力無關。那麼web端的響應時間也是總響應時間的一部分，那麼有必要web端的效能進行了解。

　　那麼前端效能這麼見效，為什麼還要去做後端效能測試呢？因為他們關注點不同，前端效能關注單個使用者的感受。後端效能關注是更多使用者訪問系統時，伺服器能更穩定、更快的處理使用者發來的請求。一個強大的後臺是前臺的基礎。

本文大部分內容抄自 段念《軟體效能測試過程詳解與案例剖析（第二版）》