轉自：http://www.nowamagic.net/librarys/veda/detail/1077
這個總結來源於一次優化的請求，最初某個頁面的加載十分緩慢，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的資源加載也比較有特色，而且很難看出規律，只能大致總結一下：
- 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的專家，卻在這方面遲遲不願實踐，實在有愧於自己的理想……