這個(gè)總結(jié)來源于一次優(yōu)化的請(qǐng)求，最初某個(gè)頁面的加載十分緩慢，load事件遲遲無法觸發(fā)，因此希望可以通過對(duì)靜態(tài)文件分域名等方式對(duì)頁面的外部資源進(jìn)行優(yōu)化，拿得load事件盡可能早地觸發(fā)。

于是我查看了頁面的源碼，并對(duì)外部資源進(jìn)行了整理，基于下面2個(gè)理念畫出了一個(gè)推測(cè)的瀑布圖：

• 瀏覽器對(duì)同一個(gè)域只能并發(fā)2個(gè)HTTP請(qǐng)求 – 網(wǎng)上盛傳已久。
• javascript文件的加載會(huì)阻塞瀏覽器其他資源的加載 – 同樣網(wǎng)上盛傳已久。

然而，當(dāng)我看到各瀏覽器中實(shí)際的瀑布圖時(shí)，我知道自己又犯了一個(gè)簡單的錯(cuò)誤：太過相信所謂的權(quán)威和大眾的聲音，而沒有更早地進(jìn)行實(shí)踐來檢驗(yàn)理論的正確性……

本篇文章就使用幾種流行的瀏覽器，針對(duì)同一個(gè)頁面的外部資源加載過程進(jìn)行分析，推測(cè)各瀏覽器加載外部資源的策略、特征，并最后給予一定的比較和總結(jié)。

測(cè)試樣例

測(cè)試的頁面結(jié)構(gòu)如下：

• 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個(gè)外部資源，加上頁面本身，一次完整的加載一共有13次HTTP GET請(qǐng)求。

針對(duì)每一個(gè)外部資源，服務(wù)器首先會(huì)休眠5秒的時(shí)間，隨后再返回相應(yīng)的內(nèi)容，以方便查看整個(gè)外部資源的加載過程。

測(cè)試的瀏覽器如下：

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

IE6

IE6的瀑布圖非常傳統(tǒng)，其特征有：

• 各資源按照在HTML中出現(xiàn)的順序進(jìn)行加載。
• javascript文件會(huì)阻塞其后所有資源的加載。
• 最大并發(fā)HTTP連接數(shù)為2個(gè)。

可見網(wǎng)上盛傳的2個(gè)“誤區(qū)”都來自IE6統(tǒng)治瀏覽器市場(chǎng)的時(shí)代，針對(duì)IE6的優(yōu)化太多太多，大家也就習(xí)慣性地將這些結(jié)論作為公理來使用了。

IE8

和IE6完全不同的瀑布圖，其特點(diǎn)有：

• 最大并發(fā)HTTP連接數(shù)為6個(gè)。
• javascript文件已經(jīng)不會(huì)阻塞其他資源的加載，甚至多個(gè)javascript文件可以一起加載，并且會(huì)保證執(zhí)行的順序。
• 會(huì)分析HTML結(jié)構(gòu)，優(yōu)先下載script和link標(biāo)簽定義的外部資源。

Firefox3.6

和IE8的幾乎完全一樣：

• 最大并發(fā)HTTP連接數(shù)為6個(gè)（可在about:config中修改）。
• javascript文件不會(huì)阻塞其他資源的加載，多個(gè)javascript文件可以一起加載。
• 會(huì)分析HTML結(jié)構(gòu)，優(yōu)先下載script和link標(biāo)簽定義的外部資源。

Firefox4 beta12

不知是因?yàn)樵O(shè)計(jì)理念上的不同，還是因?yàn)閎eta版未照顧到這一塊，F(xiàn)irefox4反而退化了，和Firefox3.6的區(qū)別主要體現(xiàn)在對(duì)資源類型的處理上，F(xiàn)irefox4不再嚴(yán)格地優(yōu)先下載script和link標(biāo)簽定義的外部資源，而是按照HTML結(jié)構(gòu)中出現(xiàn)的順序來進(jìn)行加載。

Chrome8

Chrome自帶的工具不能很清楚地表示各請(qǐng)求的開始時(shí)間，所以使用了Fiddler的瀑布圖，從圖上可以看出，Chrome也是比較特立獨(dú)行的一位，其特點(diǎn)有：

• 最大并發(fā)HTTP連接數(shù)為6。
• head部分的資源會(huì)單獨(dú)下載，且阻塞body中的其他資源的加載。
• 會(huì)優(yōu)先加載script和link標(biāo)簽定義的資源。

Opera11

先報(bào)怨一下，Dragonfly不怎么好用來著……Opera的資源加載也比較有特色，而且很難看出規(guī)律，只能大致總結(jié)一下：

• 最大并發(fā)HTTP連接數(shù)為5（網(wǎng)上有說原先版本是4）。 經(jīng)過網(wǎng)友的指正，Opera的最大并發(fā)HTTP連接數(shù)默認(rèn)為16，可在 opera:config - Performance - Max Connections Server 查看和修改。
• javascript文件的加載會(huì)阻塞其他script和link標(biāo)簽定義的外部資源的加載，如圖中的2.js。但不會(huì)阻塞圖片等其他資源的加載，如圖中的3.js。
• 會(huì)一定程度上對(duì)資源的優(yōu)先級(jí)進(jìn)行優(yōu)化，但由于javascript文件要阻止后續(xù)部分資源的加載，又為了充分利用最大HTTP連接數(shù)，因此不能嚴(yán)格先加載所有的script和link標(biāo)簽定義的資源，導(dǎo)致瀑布圖上各類型資源有相互穿插，難尋規(guī)律。

總結(jié)

• 拋開IE6不論的話，除非是在線相冊(cè)之類外部資源非常多的頁面，不然沒必要去追求靜態(tài)資源的分域名優(yōu)化。
• 針對(duì)IE6進(jìn)行靜態(tài)資源分域名優(yōu)化時(shí)，要嚴(yán)格注意javascript文件對(duì)后續(xù)資源的阻塞，進(jìn)行精確計(jì)算和設(shè)計(jì)后保證資源最完美地分域名存儲(chǔ)，以提供最大并行度。
• 鑒于Chrome對(duì)head部分的資源會(huì)獨(dú)立加載，當(dāng)head部分用不滿6個(gè)HTTP并發(fā)數(shù)時(shí)，是否可以將資源移到body中呢？在body中的資源又會(huì)引起其他的問題，需要謹(jǐn)慎考慮。
• Opera的行為比較怪異，似乎主動(dòng)設(shè)計(jì)了一個(gè)很麻煩的算法，不過考慮到其占有率，就先放在一邊吧……而且號(hào)稱最快的瀏覽器的Opera，在加載javascript文件時(shí)竟然如此笨拙……
• Firefox4 beta12的行為讓人無法理解，看來要追蹤RC版是否還存在這個(gè)問題，如果存在的話可以考慮找Mozilla報(bào)個(gè)問題了。

對(duì)各瀏覽器加載外部資源的策略的掌握，是 WPO 的基本元素，雖然一直想當(dāng)一個(gè)WPO的專家，卻在這方面遲遲不愿實(shí)踐，實(shí)在有愧于自己的理想……

最后，如果有哪位朋友了解Opera對(duì)資源加載的具體策略的，還請(qǐng)?zhí)峁┮幌拢员阌懈逦卣J(rèn)知，謝謝~！

做一名合格的前端開發(fā)工程師---各瀏覽器對(duì)頁面外部資源加載的策略