瀏覽器加載、渲染和解析過程的黑箱分析

瀏覽器加載、渲染和解析過程的黑箱分析

Posted on August 20th, 2009 in 開發 by lifesinger

測試頁面：loadtime/test.html

用 Fiddler 監控，在 IE6 下，資源下載順序爲：

很明顯，下載順序從上到下，文檔流中先出現的資源先下載。在 IE8, Safari, Chrome 等瀏覽器下也類似。

Firefox 對下載順序做了優化：

Firefox 會將 js, css 提前下載，而將圖片等資源延遲到後面下載。

對於渲染，利用 Fiddler 將網速調慢，可以看到 css 下載後會馬上渲染到頁面，渲染和下載同步進行。js 的解析和運行，也類似。

對於 js 運行，以及頁面加載相關事件的觸發，特別做了測試。在 Firefox 下，打開測試頁面：

[22:13:32.947] HTML Start


[22:13:32.947] normal inline script run time


[22:13:34.904] normal external script run time


[22:13:35.775] [body] normal external script run time


[22:13:35.789] [body end] normal external script run time


[22:13:35.789] HTML End


[22:13:35.791] deferred inline script run time


[22:13:35.791] deferred external script run time


[22:13:35.793] DOMContentLoaded


[22:13:38.144] images[0] onload


[22:13:38.328] images[1] onload


[22:13:39.105] images[2] onload


[22:13:39.105] images[3] onload


[22:13:39.106] window.onload

很明顯，JS 的運行嚴格按照文檔流中的順序進行。其中 deferred 的腳本會在最後運行（注：Firefox 3.5 開始支持 defer，而且支持得很完美）。

再來看下 IE8，結果如下：

[22:33:56.806] HTML Start


[22:33:56.826] normal inline script run time


[22:33:57.786] normal external script run time


[22:33:57.812] deferred inline script run time


[22:33:57.816] document.readyState = interactive


[22:33:57.934] [body] normal external script run time


[22:33:58.310] [body end] normal external script run time


[22:33:58.310] HTML End


[22:33:58.346] deferred external script run time


[22:33:58.346] images[0].readyState = loading


[22:33:58.346] images[0].readyState = complete


[22:33:58.346] images[0] onload


[22:33:58.361] doScroll


[22:33:58.451] images[1].readyState = loading


[22:33:58.479] images[1].readyState = complete


[22:33:58.479] images[1] onload


[22:33:58.794] images[2].readyState = loading


[22:33:58.854] images[2].readyState = complete


[22:33:58.854] images[2] onload


[22:33:58.876] images[3].readyState = loading


[22:33:58.876] images[3].readyState = complete


[22:33:58.876] images[3] onload


[22:33:58.887] document.readyState = complete


[22:33:58.888] window.onload

可以看出，IE8 下，defer 只對 external 腳本有效，對 inline 腳本無效。另，與 DOMContentLoaded 最接近的是 doScroll. 這是 doScroll 被廣泛用來模擬 DOMContentLoaded 的原因。小心：僅僅是模擬，細節上並不等價。

還可以得到一個有點意外的結果：放在 body 結束前的腳本，執行時，依舊最好放在 domready 事件中。無論在 Firefox 還是 IE 下，解析到 HTML End 時，並不代表 DOM 可以安全操作，特別是頁面比較複雜時。

從上面數據中，也可以看出 YSlow 性能優化法則裏，建議將樣式置頂和腳本置底的根據。

有興趣的可以進一步測試動態添加樣式和腳本的情形，會稍有不同，但沒有特別 surprise.

最後總結下：

頁面資源的下載順序是從上到下的，文檔流中先出現的資源先下載（注：存在併發，具體請參考 UA Profiler ）。當某一樣式下載完成時，會立刻渲染到頁面（體現了層疊樣式表中層疊在渲染時的含義）。當某一腳本下載完成時，也會立刻解析和運行。腳本的運行嚴格按照文檔流中的順序進行，deferred 的腳本會在正常腳本運行之後運行（Firefox 和 IE 下）。

特別需要留意：腳本運行時，會暫停該腳本之下所有資源的下載（因爲腳本可能改變文檔流，甚至跳轉頁面，瀏覽器的暫停策略是合理的）。要小心內聯腳本，經常會阻塞後續下載。

好了，廢話不多說。以上結果，建議各位親自測試，反覆測試，瘋狂測試，一直到眼花繚亂稀裏糊塗恍然大悟繼續糊塗爲止……

 

 

 

熱衷於WEB開發

語義-瀏覽器加載過程

瀏覽器加載順序

1. HTML下載順序自上而下，遇到語義解釋性 會啓用單獨連接進行下載。
2. CSS下載完畢後立即渲染到頁面，下載和渲染是同步，每次渲染都會對之前的元素重新渲染。
3. 運行腳本過程中，會停止頁面元素下載。

不同瀏覽器之間的差異

1. IE、Safair、Chrome等在文檔流先出現的資源優先下載。
2. FF會將腳本、樣式提前下載，圖像資源延遲下載。

注意

1. 由於運行腳本過程中會停止元素下載，所以要特別注意一些內聯腳本，這經常會阻塞後續下載。
2. 爲了安全起見，放在某斷HTML後的腳本，執行時最好還是在domready事件中，無論哪個瀏覽器解析完HTML後，還並不能代表DOM可以安全操作，特別在網頁複雜時。