通過具體實施後就可以獲得第一手的web前端效能的資料了，然後每次新版本都跑，這就會獲得大量的資料，為效能分析提供了基礎的輸入，同時應該還要綜合使用多種工具去從不同的方向收集資料；比如showslow同時還支援yslow，pagespeed，webpagetest等測試工具傳上去的資料，因此在具體的分析之前要從縱向、橫向來收集資料，這樣統計分析出來的結果才能有實際的參考價值。當然如果你還發現其它工具也可以提供一些效能資料，也可以收集起來，比如：httpanalyzer，httpwatcher都支援程式呼叫介面，很方便就可以收集http訪問過程中的資料。還有像firebug，ie開發者工具都是可以提供效能呼叫功能的。
「工欲善其事，必先利其器」，工具有了，生產資料也有了--資料，那麼後面的工作是靠我們自己的勞動力來產生價值了。效能調優的前提是分析出問題，分析問題是需要一定的準則的，不能盲人摸象人家說效能不好就不好，人家說已經調到最優了就是最優的狀態了，只能這些標準還是需要結合實際情況來考慮不能一味的應用。比如：所有的最佳實踐都會建議少加的展示，搜尋**是可以這樣，但是如果是電子商務**不可能是這樣，否則**就沒有必要做了；而效能調優正是在這些現有的狀況下、保證現有業務功能的前提下去找出具體可以優化的細節，幫助提高整體效能，而不是以犧牲業務功能為代價。比如：電子商務的**雖然不能減少，但是可以把轉換成優化格式的檔案，png比bmp肯定好，png8比gif要好等等。
那麼接下來就是之前n多效能評測工具的最佳實踐，學習並了解這些最佳實踐是入門的第一步，至少你可以有乙個容易的入口來開始進行你的工作了。具體的鏈結見下：
yslow
page speed
到這裡2個重要的標準出來了，乙個是使用者有第一感覺時的時間，乙個是完全載入所用的時間；調優的目的就是降低這2個時間，想要具體調優之前我們必須了解這些時間分別都由哪些時間判斷組成的，這樣就可以為達到最佳效能而提供最優秀的頁面展現方案了。
即瀏覽器開始渲染時的時間，而瀏覽器開始渲染之前是要解析html，解析css檔案，然後生成dom樹，再轉換成渲染樹，再給渲染樹中的節點進行布局計算【具體座標】，然後才開始一層層樹開始渲染，所以每乙個步驟都可能影響到第一使用者感覺時間。比如：
單個html檔案過大則解析時間就會比較長
css格式單獨放在外部就比內嵌式的效率高，因為一次性全部載入和應用，而且引用css時應該在頁面的頭部，因為現在的瀏覽器一般不會等到全部解析完dom才去解析css或做其它事情，所以提前載入css檔案可以加速提前達到可以渲染的時間點。
dom樹生成是從html開始的，正常的html應該解析一遍就可以完成了，但是如果html中有js呼叫，那麼在解析時就會反覆重新調整dom樹的結構，這樣就會影響dom生成的時間。
渲染樹 = dom + css渲染說明；所以這塊的轉換速度取決於具體內容，渲染的層次越多自然越長
渲染樹的布局計算時間，取決去渲染樹的節點數目，也就是dom樹的節點數目
最後開始渲染並展現我們看到的頁面內容
第一使用者感覺時間---到---最終完成載入：當然，除了這些還會有其它因素會影響web前端效能，比如：網速，dns伺服器配置等；如何抓住效能的瓶頸點是最重要的，一般最簡單的就是看用時最長的段，然後再根據實際的情況和環境確定是不是正常的數值，進而確定是否有可調優的可能性及對應的手段等。
**：
web效能測試分析 工具篇
是乙個可以用於分析.net程式行為的工具。可用其分析垃圾 器堆正在發生的事情，例如什麼方法分配了什麼型別的物件？另外，還提供了呼叫圖 call graph 功能用於顯示哪個方法呼叫了哪個方法 是個很不錯的分析工具 profiling tool 可以分析windows form和asp.net 它能夠...
web效能測試分析 工具篇
是乙個可以用於分析.net程式行為的工具。可用其分析垃圾 器堆正在發生的事情，例如什麼方法分配了什麼型別的物件？另外，還提供了呼叫圖 call graph 功能用於顯示哪個方法呼叫了哪個方法 是個很不錯的分析工具 profiling tool 可以分析windows form和asp.net 它能夠...
前端效能測試分析
web瀏覽器與web伺服器之間通過http協議進行通訊的過程。所以，web c s之間握手的協議就是http協議。遞迴尋找dns server 連線目標ip並建立tcp連線 向目標伺服器傳送http請求 web伺服器接收請求後處理 web伺服器返回相應的結果 無效 重定向 正確頁面等 瀏覽器接收返回...