[轉]各瀏覽器對頁面外部資源加載的策略

文章引用地址：http://www.iefans.net/liulanqi-waibu-ziyuan-jiazai/ 做者：iefans

這個總結來源於一次優化的請求，最初某個頁面的加載十分緩慢，load事件遲遲沒法觸發，所以但願能夠經過對靜態文件分域名等方式對頁面的外部資源進行優化，拿得load事件儘量早地觸發。

因而我查看了頁面的源碼，並對外部資源進行了整理，基於下面2個理念畫出了一個推測的瀑布圖：

一、瀏覽器對同一個域只能併發2個HTTP請求 – 網上盛傳已久。
二、javascript文件的加載會阻塞瀏覽器其餘資源的加載 – 一樣網上盛傳已久。

然而，當我看到各瀏覽器中實際的瀑布圖時，我知道本身又犯了一個簡單的錯誤：太過相信所謂的權威和大衆的聲音，而沒有更早地進行實踐來檢驗理論的正確性……

本篇文章就使用幾種流行的瀏覽器，針對同一個頁面的外部資源加載過程進行分析，推測各瀏覽器加載外部資源的策略、特徵，並最後給予必定的比較和總結。

測試樣例

測試的頁面結構以下：

• head
  • 1.css + 1.js
• body
  • 1.jpg + 2.jpg + 2.js + 2.css + 3.jpg + 4.jpg + 3.css + 3.js + 5.jpg + 6.jpg

共12個外部資源，加上頁面自己，一次完整的加載一共有13次HTTP GET請求。

針對每個外部資源，服務器首先會休眠5秒的時間，隨後再返回相應的內容，以方便查看整個外部資源的加載過程。

測試的瀏覽器以下：

• IE6
• IE8
• Firefox3.6
• Firefox4.0 beta12
• Chrome 8
• Opera 11

IE6

IE6的瀑布圖很是傳統，其特徵有：

• 各資源按照在HTML中出現的順序進行加載。
• javascript文件會阻塞其後全部資源的加載。
• 最大併發HTTP鏈接數爲2個。

可見網上盛傳的2個「誤區」都來自IE6統治瀏覽器市場的時代，針對IE6的優化太多太多，你們也就習慣性地將這些結論做爲公理來使用了。

IE8

和IE6徹底不一樣的瀑布圖，其特色有：

• 最大併發HTTP鏈接數爲6個。
• javascript文件已經不會阻塞其餘資源的加載，甚至多個javascript文件能夠一塊兒加載，而且會保證執行的順序。
• 會分析HTML結構，優先下載script和link標籤訂義的外部資源。

Firefox3.6

和IE8的幾乎徹底同樣：

• 最大併發HTTP鏈接數爲6個（可在about:config中修改）。
• javascript文件不會阻塞其餘資源的加載，多個javascript文件能夠一塊兒加載。
• 會分析HTML結構，優先下載script和link標籤訂義的外部資源。

Firefox4 beta12

不知是由於設計理念上的不一樣，仍是由於beta版未照顧到這一塊，Firefox4反而退化了，和Firefox3.6的區別主要體如今對資源類型的處理上，Firefox4再也不嚴格地優先下載script和link標籤訂義的外部資源，而是按照HTML結構中出現的順序來進行加載。

Chrome8

Chrome自帶的工具不能很清楚地表示各請求的開始時間，因此使用了Fiddler的瀑布圖，從圖上能夠看出，Chrome也是比較特立獨行的一位，其特色有：

• 最大併發HTTP鏈接數爲6。
• head部分的資源會單獨下載，且阻塞body中的其餘資源的加載。
• 會優先加載script和link標籤訂義的資源。

Opera11

先報怨一下，Dragonfly不怎麼好用來着……Opera的資源加載也比較有特點，並且很難看出規律，只能大體總結一下：

• 最大併發HTTP鏈接數爲5（網上有說原先版本是4）。通過網友的指正，Opera的最大併發HTTP鏈接數默認爲16，可在opera:config - Performance - Max Connections Server查看和修改。
• javascript文件的加載會阻塞其餘script和link標籤訂義的外部資源的加載，如圖中的2.js。但不會阻塞圖片等其餘資源的加載，如圖中的3.js。
• 會必定程度上對資源的優先級進行優化，但因爲javascript文件要阻止後續部分資源的加載，又爲了充分利用最大HTTP鏈接數，所以不能嚴格先加載全部的script和link標籤訂義的資源，致使瀑布圖上各種型資源有相互穿插，難尋規律。

總結

• 拋開IE6不論的話，除非是在線相冊之類外部資源很是多的頁面，否則不必去追求靜態資源的分域名優化。
• 針對IE6進行靜態資源分域名優化時，要嚴格注意javascript文件對後續資源的阻塞，進行精確計算和設計後保證資源最完美地分域名存儲，以提供最大並行度。
• 鑑於Chrome對head部分的資源會獨立加載，當head部分用不滿6個HTTP併發數時，是否能夠將資源移到body中呢？在body中的資源又會引發其餘的問題，須要謹慎考慮。
• Opera的行爲比較怪異，彷佛主動設計了一個很麻煩的算法，不過考慮到其佔有率，就先放在一邊吧……並且號稱最快的瀏覽器的Opera，在加載javascript文件時居然如此笨拙……
• Firefox4 beta12的行爲讓人沒法理解，看來要追蹤RC版是否還存在這個問題，若是存在的話能夠考慮找Mozilla報個問題了。

對各瀏覽器加載外部資源的策略的掌握，是WPO的基本元素，雖然一直想當一個WPO的專家，卻在這方面遲遲不肯實踐，實在有愧於本身的理想……

最後，若是有哪位朋友瞭解Opera對資源加載的具體策略的，還請提供一下，以便有更清晰地認知，謝謝~！