探真無阻塞加載javascript腳本技術，咱們會發現不少意想不到的祕密

　　下面的圖片是我使用firefox和chrome瀏覽百度首頁時候記錄的http請求

 

下面是firefox：

 

下面是chrome：

 

　　在瀏覽百度首頁前我都將瀏覽器的緩存所有清理掉，讓這個場景最接近第一次訪問百度首頁的情景。

　　在firefox的請求瀑布圖裏有個表現很是之明顯：就是javascript文件下載完畢後，有一段時間是沒有網絡請求被處理的，這段時間事後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完成http操做後並不意味操做完畢，UI線程接着會執行它，若是你開發的頁面裏js代碼執行時間過長，那麼用戶就會明顯感受到頁面的延遲。爲何瀏覽器不能把javascript代碼的加載過程拆分爲下載和執行兩個並行的過程，這樣就能夠充分利用時間完成http請求，這樣不是就能提高頁面的加載效率了嗎？這個問題的答案固然是否認的，javascript是一個編程語言，js代碼是有智力的，它除了能夠完成邏輯性的工做，還能夠經過操做頁面元素來改變頁面UI效果，若是咱們忽略javascript對UI的影響，讓它延遲執行，結果會形成頁面展現的混亂。那麼他會產生什麼樣的混亂呢？這個混亂的描述以下：

　　最簡單最好理解和最好掌握的思路是線性思路，對於瀏覽器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個是最佳的，這個數據怎麼得來的我就不太清楚了，不過結果很簡單很好用，記住就好了。

　　下面我就要聊聊如何解決js阻塞頁面加載的問題了，js之因此會阻塞UI線程的執行，是由於js能控制UI的展現，而頁面加載的規則是要順序執行，因此在碰到js代碼時候UI線程會首先執行它，而這點不少程序員不知道或者知道但被忽視，所以致使編寫代碼時候將用於展現的代碼和用於處理邏輯的代碼混淆在一塊兒，這樣作的後果是使js代碼形成的阻塞更加嚴重，因此雅虎公司的前端團隊提出了一個前端優化的規則：將js腳本放置到html文檔的末尾，這樣就能有效的避免UI的阻塞。可是這個方法太簡單了，不利於咱們對網站進行更加深刻的優化。爲了作的深刻，咱們要須要更進一步分析，首先咱們知道js腳本按出現的位置分爲兩類一類是行內腳本即寫在頁面裏的腳本，一類是js的外部文件，行內腳本的優化比較簡單，就是儘可能在頁面寫更少的代碼，就算要寫代碼也主要是控制頁面加載的UI顯示的代碼，不必的代碼就放在外部的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線程的執行和以阻塞方式加載的腳本。

　　下面是無阻塞加載腳本的技術方案：

　　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自己不能跨域，因此該方法不能跨域。

　　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("");

　　

 

　　Script in Iframe

　　因爲Iframe是開銷最高的DOM元素，這種方法仍是儘可能避免使用，並且這種方法也沒法實現跨域。

　　Script DOM Element

　　可跨域方案，利用動態插入script元素來讓腳本讀取、生效。

　　代碼以下：

var scriptElem = document.createElement("script");
scriptElem.src = "http://anydomain.com/A.js";
document.getElementByTagName("head")[0].appendChild(scriptElem);

　　

　　Script Defer

　　原生方案。利用defer屬性來防止腳本阻塞。

　　代碼以下：

<script defer src="A.js"></script>

　　

　　不過許多瀏覽器不支持該屬性。

　　document.write Script Tag

　　動態寫腳本的另外一種方案，不過只在IE中是並行下載的。

　　代碼以下：

document.write("<script type='text/javascript' src='A.js'></script>");

　　

 

　　script defer和document.write Srcipt Tag不是跨瀏覽器的方案這裏不推薦。
　　頁面嵌套iframe方案我沒有詳述，緣由是我如今很討厭iframe，iframe是dom元素裏開銷最大的元素，有它就意味着慢，並且我最近碰到一個生產問題就是iframe引發，緣由就是對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屬性，它的取值以下：
　　1.uninitialized（未初始化）：對象存在還沒有初始化；
　　2.loading（正在加載）：對象正在加載數據；
　　3.loaded（加載完畢）：對象數據加載完成
　　4.interactive（交互）：能夠操做對象，可是尚未徹底加載；
　　5.complete（完成）：對象已經加載完畢。
　　具體用法以下所示：

scriptNode.onreadystatechange = function(){
	if (scriptNode.readystate == 'complete'){// todo......}
}

　　

 

　　這個作法就是爲dom加載定義了一個回調函數，當dom加載完畢後回調函數纔會執行，這樣就解決了代碼執行順序的問題了。

　　另外還有一個方式就是使用setTimeout，具體使用就是定義一個輪詢，判斷須要使用的變量是否存在，若是不存在，就繼續輪詢，若是變量存在則中止輪詢，代碼模式以下所示：

　　代碼以下：

function lunxun(){
	if ("undefined" == typeof(XXXX)){
		setTimeout(lunxun,300);
	}else{
		ftn();
	}
}
lunxun();

　　

　　無阻塞腳本的好處就是不會阻塞UI的執行，也不會影響其餘同步js代碼的執行，不過無阻塞腳本改變了腳本的加載順序，因此在使用無阻塞腳本時候必定要更加註意腳本之間的依賴關係，保證整個頁面的腳本都能正常執行。

　　在之前的文章裏我屢次提到了js的模塊加載技術，時下流行的模塊加載技術有進口貨requirejs和國產貨seajs，使用這些技術，咱們會發現js文件加載都是按模塊加載的，也就是說你頁面定義了多少個js模塊，那麼這個頁面就有多少個js文件，剛開始使用它們時候我很詫異，按照前端優化原則http請求越少越好，爲何先進的模塊技術卻會讓js文件變得更多了，接着我分析了下它們加載js的請求，終於明白了，它們都使用的無阻塞腳本加載技術，即便用script節點方式加載腳本，這樣就很容易屏蔽js帶來的阻塞問題了。

　　上面的實例中我使用script節點將腳本都是嵌入到head節點裏，這個彷佛和將腳本置於html文檔末尾的原則不一樣，這個是否是須要改進了，答案是不須要改進，將腳本置於文檔末尾目的是爲了不js的阻塞，而咱們使用無阻塞腳本了，這個問題不是解決了嗎？因此代碼置於head標籤仍是html文檔底部也就可有可無了。

　　最後我要糾正一個錯誤的觀點，頁面加載的總時間是衡量頁面加載快捷的標準嗎？答案是，的確是個標準，可是不是最精確的標準，頁面同步阻塞加載的時間纔是衡量頁面加載效率的準確標準，非阻塞腳本加載可能會增長整個頁面加載的時間，可是它能夠減小頁面阻塞加載的時間，而頁面阻塞纔是影響用戶體驗的元兇，頁面優化最重要的關注點就是你所看到的的東西要加載的更加快。

 　　無阻塞腳本能夠分割外部腳本的下載和執行操做，這是程序員使用的hack技術，它很酷，可是會致使程序的複雜度增長，可讀性降低，因此它應該是web前端架構師的技術，平常開發咱們要慎用它。