偶然間看到這樣一篇部落格，内容很詳細，概念解釋的也很通俗，轉過來與大家分享一下，學習學習。
原文轉自：http://ghdcblog.cn/article/%E4%BA%86%E8%A7%A3%E6%97%A0%E9%98%BB%E5%A1%9E%E5%8A%A0%E8%BD%BDjavascript%E8%84%9A%E6%9C%AC%E6%8A%80%E6%9C%AF#
浏覽器裡 的http請求被阻塞一般都是由javascript所引起，具體原因是javascript下載下傳完畢之後會立即執行，而javascript執行時候會 阻塞浏覽器的其他行為，例如阻塞其他javascript的執行以及其他的http請求的執行。這樣會導緻頁面加載變慢，如果這個變慢很明顯，此時使用者操 作網頁會發現頁面沒有反應會反應很慢，慢是網站使用者體驗的夢魇。
一、什麼是HTTP請求阻塞
下面的兩張圖檔是使用firefox和chrome浏覽百度首頁時候記錄的http請求(在浏覽百度前已清除浏覽器緩存，使場景最接近第一次通路百度首頁的情景)。
圖二：Chrome
在firefox的請求瀑布圖裡有個表現非常之明顯：就是javascript檔案下載下傳完畢後，有一段時間是沒有網絡請求被處理的，這段時間過後http請求才會接着執行，這段空閑時間就是所謂的http請求被阻塞。
二、為什麼會發生HTTP請求阻塞
浏覽器裡 的http請求被阻塞一般都是由javascript所引起，具體原因是javascript下載下傳完畢之後會立即執行，而javascript執行時候會 阻塞浏覽器的其他行為，例如阻塞其他javascript的執行以及其他的http請求的執行。這樣會導緻頁面加載變慢，如果這個變慢很明顯，此時使用者操 作網頁會發現頁面沒有反應會反應很慢，慢是網站使用者體驗的夢魇。
在系統開發過程中經常碰到javascript阻塞頁面加載的問題，主要原因是網站很多靜态資源和腳本是獨立部署在靜态資源伺服器上，而本地的開發環境無法模拟靜态資源伺服器或者模拟靜态資源伺服器不穩定。
另外，有時更新代碼不及時一些建立的腳本沒有及時更新到開發環境上，是以某些js腳本檔案無法正确擷取，這些問題導緻頁面加載時候這些js腳本就會阻塞頁面的加載，此時浏覽器會反複嘗試請求這些js檔案，直到請求逾時才會認定該腳本的url無效，如果中途你無法忍受這種等待，強制關閉浏覽器的請求，會發現在浏覽器控制台裡很多腳本都無法找到，這樣你就無法在控制台裡設定js代碼斷點調試js。如果等待js加載完畢，時間又會被浪費，無奈之下隻要找到那些無效的url将其注釋掉，哎結果好幾次都将有注釋的錯誤代碼送出到了svn伺服器上，這些事情真是很惱人。
三、浏覽器如何加載資源
不管那種浏覽器，也不管是新版本還是老版本的浏覽器，它們都秉持浏覽器的單線程特性，這個特性似乎是一個很難撼動的準則，當我們在浏覽器的位址欄裡輸入一個url 位址，通路一個新頁面時候，頁面展示的快慢就是由一個單線程所控制，這個線程叫做UI線程，UI線程會根據頁面裡資源（資源是指css檔案，圖檔等等）代碼的先後順序來加載資源，加載資源也就是使用http請求擷取資源，比如：css檔案、html檔案以及圖檔等資源。http請求處理完畢也就意味着資源加載結束。
但是像外部的javascript檔案則不同，它的加載過程被分為兩步：
- 第一步，和加載css檔案和圖檔一樣，就是執行一個http請求下載下傳外部的 js檔案。
- 第二步，javascript讀取完畢後并不意javascript加載完畢，UI線程會立即執行它，
如果你開發的頁面裡js代碼執行時間過長，那麼使用者就會明顯感覺到頁面的延遲。
四、為什麼不可以并行javascript的加載和執行過程
為什麼浏覽器不能把javascript代碼的加載過程拆分為下載下傳和執行兩個并行的過程，這樣就可以充分利用時間完成http請求，這樣不是就能提升頁面的加載效率了嗎？這個問題的答案當然是否定的，javascript是一個程式設計語言，它除了可以完成一般性程式邏輯，還可以通過操作頁面元素來改變頁面UI效果，如果我們忽略javascript對UI的影響，讓它延遲執行，結果會造成頁面展示的混亂：
最簡單最好了解和最好掌握的思路是：線性思路。要按線性思路了解浏覽器渲染過程：即放在頁面前部的資源會優先加載和執行，浏覽器還會認為前一步的内容都可能會是後一步頁面展示前提，如果浏覽器擅自停止中間某個代碼的執行，很有可能頁面最終呈現的效果和設計者設計的不同，這樣我們就無法開發出正确的頁面。
而且按線性思路當你碰到頁面UI效果出問題時候，你很容易定位問題所在，如果我們将js代碼的加載和執行分隔開來，這就好比把線性思路變成了樹狀結構，那麼你掌握頁面加載的思路和解決UI加載問題時候就會變得更加困難，到時很多人都會抓狂和思路混亂。
綜上所述，js腳本下載下傳和執行是一個完整的操作，是絕對不能被割裂的。
五、如何加快速度呢？
為了提升使用者體驗，加快浏覽器UI線程的渲染速度是一個無法回避的問題。由于拆分js的下載下傳和執行是不可行的，如是乎浏覽器換了種方式，這個方式也就是在同一個時間能下載下傳多個資源，我們再看上圖，在同一個域名下，firefox可以同時下載下傳兩種圖檔，chrome可以同時下載下傳4個靜态資源，不過這是針對圖檔和css檔案，對于js檔案似乎還是一個接着一個的下載下傳，下載下傳一個執行一個。不過在ie8以上版本，js可以和圖檔一樣并行加載，ie這樣做就提升了js檔案下載下傳的 效率，不過到了js執行時候還是要嚴格按照順序執行。
多個http連接配接并行下載下傳資源就好比多個線程共同完成某個任務，如果并行http連接配接更多，那麼就能同時下載下傳更多的http資源，但是浏覽器提供并行執行的 http連接配接實在太少了，例如上面firefox才兩個，chrome也隻有4個，那如何突破浏覽器的連接配接個數的限制了？方法很簡單就是将常用的、穩定的靜态資源統一放在一個靜态資源伺服器上，由統一的域名對外提供，這個域名要和主體請求的域名不一樣，原理是因為浏覽器隻通過域名來限制連接配接的個數，如果一個頁面裡有兩個不同的域的，那麼并行的http請求個數也會變成兩倍。
六、有什麼問題
這個做法有點讨浏覽器的巧，是程式員發現浏覽器的特點而總結出的技術，它類似一個 hack技術，而hack技術不會是标準技術，是以它肯定有它的瓶。所有這樣的技術都會有個度的，浏覽器限制請求個數絕對不是無緣無故的，我們看百度頁面并行下載下傳圖檔的http協定的版本都是1.1，http1.1特點就是長連接配接，長連接配接的好處是在頁面和服務端頻繁互動時候效率很好，但是浏覽器的頁 面操作并不是總是頻繁的請求伺服器，而為了加載靜态資源而建立很多長連接配接，伺服器會不得不維護大量無用的長連接配接，給伺服器的壓力是可想而知的。
對比http1.0協定，它使用短連接配接。是以早期版本的浏覽器會給http1.0協定開啟的連接配接數要高于http1.1連接配接數，是以有些網站将靜态資源伺服器提供http協定版本降低到1.0，這樣可以有效的提升浏覽器的并發連接配接數。
這個做法會給網頁性能帶來意想不到的提升，不過現代的浏覽器似乎更願意平等對待兩個不同版本的協定了，有些新版的浏覽器會将兩類協定的并發數變成一樣。而對于處于用戶端地位的浏覽器來說，維護多個連結對于資源消耗也是龐大的，而且域名過多也會增加dns解析的開銷，是以并發連接配接開啟越多，并不一定真的會達到提升性能的目的，那麼多少個域最合适了？
雅虎的前端工程師給了一個答案： 2個 ，2個是最佳的。
這個資料怎麼得來的我就不太清楚了，不過結果很簡單很好用，記住就行了。
七、如何解決JS阻塞
下面我就 要聊聊如何解決js阻塞頁面加載的問題了。js之是以會阻塞UI線程的執行，是因為js能控制UI的展示，而頁面加載的規則是要順序執行，是以在碰到js 代碼時候UI線程會首先執行它。而這點很多程式員不知道或者知道但忽視了，是以使得編寫代碼時候将用于展示的代碼和用于處理邏輯的代碼混淆在一起。這樣做的後果是使js代碼造成的阻塞更加嚴重。
是以，雅虎公司的前端團隊提出了一個前端優化的規則： 将js腳本放置到html文檔的末尾，這樣就能有效的避免UI的阻塞。
但是這個方法太簡單了，不利于我們對網站進行更加深入的優化。為了做的深入，我們要需要更進一步分析，首先我們知道js腳本按出現的位置分為兩類：
1、一類是行内腳本即寫在頁面裡的腳本
行内腳本的優化比較簡單，就是盡量在頁面寫更少的代碼，就算要寫代碼也主要是控制頁面加載的UI顯示的代碼，沒必要的代碼就放在外部的js檔案裡。
2、一類是js的外部檔案。
js外部檔案優化就比較複雜，為了精簡行内腳本，我們就不得不将大量的js代碼放到外部檔案裡，早先時候我都會盡量将所有外部js檔案合并成一個js檔案。但是現在我發現一個複雜的外部腳本很有可能會讓頁面的阻塞情況變得更加的嚴重。
是以外部腳本要根據其功能拆分為展示腳本和邏輯腳本，但是事實上展示代碼和邏輯代碼很難分離，其實有個更加簡單的标準讓我們拆分代碼：将所有外部代碼分為UI初始化代碼和其他代碼。UI初始化代碼是在頁面加載時候執行的代碼，我們現在隻要判斷哪些代碼在頁面加載時候執行就行了，這個标準就容易多了。
另外，上面提到過頁面被js阻塞的情況，有時為了調試js代碼會一直等待浏覽器判斷js加載失敗，那麼怎麼知道浏覽器已經判斷外部js加載無效了？很簡單就是檢視浏覽器忙訓示結束，浏覽器的忙訓示如下圖所示：
忙訓示 (忙訓示現象包括：浏覽器頁籤的旋轉圓圈，滑鼠變成漏鬥滑鼠，浏覽器左下的狀态欄顯示正在加載某某url以及老版的ie顯示頁面加載進度的現象)标記結束了，就表明頁面的加載操作結束了。
為了防止js腳本阻塞頁面加載，那麼我們要做到的就是讓那些不會用于頁面初始化展示的js代碼的加載和執行操作在浏覽器忙訓示結束後觸發。為了做到這一點我們就得知道忙訓示結束後會觸發什麼指令，這個指令就是浏覽器的onload事件，是以我們讓那些和頁面加載無關的js腳本在onload方法裡執行。
在onload事件裡可以使用dom技術，建構script節點，設定它的src指向需要加載的腳本路徑，然後将這個srcipt節點加入到html文檔的head裡。為了完全確定這個js在忙訓示結束後執行，需要使用setTimeout方法調用動态加載腳本的方法，進一步確定代碼在忙訓示結束後執行，實踐下來感覺效果的确不錯。
到這裡應該算是有了一個較好的解決方案，但是等等，好像有什麼地方有點不對頭，我們經常使用jQuery定義的ready方法，ready方法會在dom加載完畢後執行，而我們的方案卻是在onload後執行，代碼執行遠遠落後jQuery的ready方法執行時機，這個感覺很不舒服。
其次，在頁面開發裡我們會使用很多第三方庫，雖然現在開發中大部分情況隻用jQuery這一個第三方庫，但也不盡然。 很多業務需求會需要使用第三方庫，很多庫有大量UI操作的通用方法，這些方法非常好用。經常使用這些庫會是的我們自己寫的控制UI的js代碼常常會依賴它們，那麼拆分UI控制腳本和其他腳本就無從談起了。
總之，現在web前端開發太依賴第三方庫，就算一個牛逼的前端團隊，拒絕使用第三方庫，什麼都自己開發，當 web應用變複雜後，通用庫和業務代碼的耦合度都是很難解決的問題，這也會導緻我們沒法真正将UI展示代碼和邏輯代碼真正的分離。
八、有沒有通用方法
目前的方案并不一定符合所有實際生産的需求，還不夠完美。是以本文到這裡沒有推導出通用規則，真令人失望，面對上面的新問題那我們該怎麼辦了？
這個問題不是無解的，現行技就有很好的解決方案，那就是無阻塞腳本的加載。無阻塞加載腳本技術的核心就是：加載js腳本時候，被加載的js腳本不會阻塞UI線程的執行和以阻塞方式加載的腳本。
下面是無阻塞加載腳本的技術方案：
1. XHR Eval
顧名思義，通過XHR讀取腳本，通過Eval令腳本生效，代碼如下：
var xhrObj = new XMLHttpRequest();
xhrObj.onreadystatechange = function(){
if (xhrObj.readyState == 4 && 200 == xhrObj.status) {
eval(xhrObj.responseText);
}
};
xhrObj.open("GET", "A.js", true);
xhrObj.send("");
由于XMLHttpRequest本身不能跨域，是以該方法不能跨域。
2. XHR Injection
使用動态建立script元素，來寫入腳本，在某些情況下可能比上一種方法要快些。代碼如下：
var xhrObj = new XMLHttpRequest();
xhrObj.onreadystatechange = function (){
if (xhrObj.readyState == 4){
var scriptElem = document.createElement("script");
document.getElementsByTagName("head")[0].appendChild(scriptElem);
scriptElem.text = xhrObj.responseText;
}
};
xhrObj.open("GET", "A.js" , true);
xhrObj.send("");
3. Script in Iframe
由于Iframe是開銷最高的DOM元素，這種方法還是盡量避免使用，而且這種方法也無法實作跨域。
4. Script DOM Element
可跨域方案，利用動态插入script元素來讓腳本讀取、生效。代碼如下：
var scriptElem = document.createElement( "script" );
scriptElem.src = "http://anydomain.com/A.js" ;
document.getElementByTagName("head")[0].appendChild(scriptElem);
5. Script Defer
原生方案。利用defer屬性來防止腳本阻塞。代碼如下：
<script defer src="A.js"></script>
不過許多浏覽器不支援該屬性。
6. document.write Script Tag
動态寫腳本的另一種方案，不過隻在IE中是并行下載下傳的。
代碼如下：
document.write("<script type='text/javascript' src='A.js'></script>");
script defer和document.write Srcipt Tag不是跨浏覽器的方案這裡不推薦。
頁面嵌套iframe方案沒有詳述，因為iframe是dom元素裡開銷最大的元素，有它就意味着慢。另外iframe跨域也是問題之一，iframe跨域時父窗體和子窗體代碼就不能互訪了，而且iframe寫法的不正确（寫的很類似跨站腳本挾持）還會導緻浏覽器啟動預設的安全機制，最終出現使用者無法正常使用頁面的情況，是以不推薦使用iframe。
xhr eval也不推薦，因為它使用eval指令，而eval的使用常常會為黑客留下破壞你網站的漏洞。
是以最好的方案就是xhr注入和script dom element了，這兩個方案不存在浏覽器相容問題，而且後者還能跨域，不過跨域的選擇也是要謹慎的，跨域腳本也會帶來隐形的安全風險，不管怎麼說這兩個方案使用場景基本上可以包括所有阻塞腳本加載的場景。
注意：無阻塞加載腳本的核心技術就是動态的建立script的dom節點。
無阻塞腳本加載技術還有個好處就是，那些和頁面展示無關的腳本無須非要放在onload事件裡執行，它随時随地可以運作。
九、無阻塞腳本的問題和解決方式
不過無阻塞腳本有個很大的隐患，這個隐患是很多會使用無阻塞腳本技術的程式員都會忽視的問題，這個問題就是無阻塞腳本很容易産生“變量未定義”的問題。
這個問題的本質就是無阻塞腳本會破壞js腳本加載順序的問題，當某個腳本依賴于另一個腳本時候，而另一個腳本又沒有加載執行完畢，最後就會産生“變量未定義”的問題，例如jQuery沒有提前加載，是以使用$時候提示$變量未定義。
那麼該如何解決這個問題？思路就是讓那些依賴于無阻塞加載的腳本的js代碼在腳本加載完畢後再執行，我們需要一個辦法将無序的腳本加載變得有序，上面推薦的兩種方法都是使用dom技術建立script節點，然後将該節點加入到文檔的head頭部。
對于script節點，在非ie浏覽器下有一個onload事件，該事件會在script加載完畢後才會執行，ie浏覽器下有onreadystatechange事件，而ie下script的 dom節點有一個readystate屬性，它的取值如下：
- uninitialized（未初始化）：對象存在尚未初始化；
- loading（正在加載）：對象正在加載資料；
- loaded（加載完畢）：對象資料加載完成
- interactive（互動）：可以操作對象，但是還沒有完全加載；
- complete（完成）：對象已經加載完畢。
具體用法如下：
scriptNode.onreadystatechange = function(){
if (scriptNode.readystate == 'complete'){
// todo......
}
}
這個做法就是為dom加載定義了一個回調函數，當dom加載完畢後回調函數才會執行，這樣就解決了代碼執行順序的問題了。
另外還有一個方式就是使用setTimeout，具體使用就是定義一個輪詢，判斷需要使用的變量是否存在，如果不存在，就繼續輪詢直到變量存在。代碼如下所示：
function lunxun(){
if ("undefined" == typeof(undefined)){
setTimeout(lunxun,300);
}
else {
ftn();
}
}
lunxun();
無阻塞腳本的好處就是不會阻塞UI的執行，也不會影響其他同步js代碼的執行。不過無阻塞腳本改變了腳本的加載順序，是以在使用無阻塞腳本時候一定要更加注意腳本之間的依賴關系，保證整個頁面的腳本都能正常執行。
目前較流行的子產品加載技術有：requirejs和seajs。使用這些技術，我們會發現js檔案都是按子產品加載的，它們都使用的無阻塞腳本加載技術，即使用script節點方式加載腳本，這樣就很容易屏蔽js帶來的阻塞問題了。
上面的執行個體中使用script節點将腳本都是嵌入到head節點裡，這個似乎和将腳本置于html文檔末尾的原則不同，這個問題是否需要改進？答案是不需要改 進，将腳本置于文檔末尾目的是為了避免js的阻塞，而我們使用無阻塞腳本了，這個問題也就解決了。是以代碼置于head标簽還是html文檔底部也就無關緊要了。
最後需要糾正一個錯誤的觀點，頁面加載的總時間是衡量頁面加載快捷的标準嗎？答案是，的确是個标準，但是不是最精确的标準。頁面同步阻塞加載的時間才是衡量頁面加 載效率的準确标準，非阻塞腳本加載可能會增加整個頁面加載的時間，但是它可以減少頁面阻塞加載的時間，而頁面阻塞才是影響使用者體驗的元兇，頁面優化最重要的關注點就是你所看到的的東西要加載的更加快。
無阻塞腳本可以分割外部腳本的下載下傳和執行操作，這是程式員使用的hack技術，它很酷，但是會導緻程式的複雜度增加，可讀性下降。是以它應該是web前端架構師的技術，日常開發我們要慎用它。