下面的圖片是我使用firefox和chrome瀏覽百度首頁(yè)時(shí)候記錄的http請(qǐng)求

下面是firefox：

下面是chrome：

在瀏覽百度首頁(yè)前我都將瀏覽器的緩存全部清理掉，讓這個(gè)場(chǎng)景最接近***次訪問百度首頁(yè)的情景。

在firefox的請(qǐng)求瀑布圖里有個(gè)表現(xiàn)非常之明顯：就是javascript文件下載完畢后，有一段時(shí)間是沒有網(wǎng)絡(luò)請(qǐng)求被處理的，這段時(shí)間過后http請(qǐng)求才會(huì)接著執(zhí)行，這段空閑時(shí)間就是所謂的http請(qǐng)求被阻塞。

瀏覽器里的http請(qǐng)求被阻塞一般都是由javascript所引起，具體原因是javascript下載完畢之后會(huì)立即執(zhí)行，而javascript執(zhí)行時(shí)候會(huì)阻塞瀏覽器的其他行為，例如阻塞其他javascript的執(zhí)行以及其他的http請(qǐng)求的執(zhí)行。這樣會(huì)導(dǎo)致頁(yè)面加載變慢，如果這個(gè)變慢很明顯，此時(shí)用戶操作網(wǎng)頁(yè)會(huì)發(fā)現(xiàn)頁(yè)面沒有反應(yīng)會(huì)反應(yīng)很慢，慢是網(wǎng)站用戶體驗(yàn)的夢(mèng)魘。

我目前開發(fā)的一些系統(tǒng)，在開發(fā)環(huán)境里經(jīng)常碰到j(luò)avascript阻塞頁(yè)面加載的問題，主要原因是我們網(wǎng)站很多靜態(tài)資源和腳本都被獨(dú)立抽取在了一臺(tái)單獨(dú)的靜態(tài)資源服務(wù)器上，而本地的開發(fā)環(huán)境模擬的靜態(tài)資源服務(wù)環(huán)境常常很不穩(wěn)定（經(jīng)常宕機(jī)），有時(shí)一些新建的腳本沒有及時(shí)更新到開發(fā)環(huán)境上，因此某些js腳本文件無法正確獲取，這些問題導(dǎo)致頁(yè)面加載時(shí)候這些js腳本就會(huì)阻塞頁(yè)面的加載，此時(shí)瀏覽器會(huì)反復(fù)嘗試請(qǐng)求這些js文件，直到請(qǐng)求超時(shí)才會(huì)認(rèn)定該腳本的url無效，如果中途你無法忍受這種等待，強(qiáng)制關(guān)閉瀏覽器的請(qǐng)求，會(huì)發(fā)現(xiàn)在瀏覽器控制臺(tái)里很多腳本都無法找到，這樣你就無法在控制臺(tái)里設(shè)置js代碼斷點(diǎn)調(diào)試js，如果等待js加載完畢，時(shí)間又會(huì)被浪費(fèi)，無奈之下只要找到那些無效的url將其注釋掉，哎，結(jié)果好幾次都將有注釋的錯(cuò)誤代碼提交到了svn服務(wù)器上，這些事情真是很惱人。

不管那種瀏覽器，也不管是新版本還是老版本的瀏覽器，它們都秉持瀏覽器的單線程特性，這個(gè)特性似乎是一個(gè)很難撼動(dòng)的準(zhǔn)則，當(dāng)我們?cè)跒g覽器的地址欄里輸入一個(gè)url地址，訪問一個(gè)新頁(yè)面時(shí)候，頁(yè)面展示的快慢就是由一個(gè)單線程所控制，這個(gè)線程叫做UI線程，UI線程會(huì)根據(jù)頁(yè)面里資源（資源是指css文件，圖片等等）書寫的先后順序來加載資源，加載資源也就是使用http請(qǐng)求獲取資源，像css外部文件，html文件以及圖片等資源http請(qǐng)求處理完畢也就意味著資源加載結(jié)束，但是像外部的javascript文件則不同，它的加載過程被分為兩步，***步和加載css文件和圖片一樣，就是執(zhí)行一個(gè)http請(qǐng)求下載外部的js文件，但是javascript完成http操作后并不意味操作完畢，UI線程接著會(huì)執(zhí)行它，如果你開發(fā)的頁(yè)面里js代碼執(zhí)行時(shí)間過長(zhǎng)，那么用戶就會(huì)明顯感覺到頁(yè)面的延遲。為什么瀏覽器不能把javascript代碼的加載過程拆分為下載和執(zhí)行兩個(gè)并行的過程，這樣就可以充分利用時(shí)間完成http請(qǐng)求，這樣不是就能提升頁(yè)面的加載效率了嗎？這個(gè)問題的答案當(dāng)然是否定的，javascript是一個(gè)編程語言，js代碼是有智力的，它除了可以完成邏輯性的工作，還可以通過操作頁(yè)面元素來改變頁(yè)面UI效果，如果我們忽略javascript對(duì)UI的影響，讓它延遲執(zhí)行，結(jié)果會(huì)造成頁(yè)面展示的混亂。那么他會(huì)產(chǎn)生什么樣的混亂呢？這個(gè)混亂的描述如下：

最簡(jiǎn)單***理解和***掌握的思路是線性思路，對(duì)于瀏覽器UI顯示要按線性思路理解即放在頁(yè)面前部的資源會(huì)優(yōu)先加載和執(zhí)行，瀏覽器還會(huì)認(rèn)為前一步的內(nèi)容都可能會(huì)是后一步頁(yè)面展示前提，如果瀏覽器擅自停止中間某個(gè)代碼的執(zhí)行，很有可能頁(yè)面最終呈現(xiàn)的效果和設(shè)計(jì)者設(shè)計(jì)的不同，這樣我們就無法開發(fā)出正確的頁(yè)面。而且按線性思路當(dāng)你碰到頁(yè)面UI效果出問題時(shí)候，你很容易定位問題所在，如果我們將js代碼的加載和執(zhí)行分隔開來，這就好比把線性思路變成了樹狀結(jié)構(gòu)，那么你掌握頁(yè)面加載的思路和解決UI加載問題時(shí)候就會(huì)變得更加困難，到時(shí)很多人都會(huì)抓狂和思路混亂，所以我在這里說混亂。

綜上所述，js腳本下載和執(zhí)行是一個(gè)完整的操作，是絕對(duì)不能被割裂的。

瀏覽器為了提升用戶體驗(yàn)，加快UI線程的執(zhí)行是一個(gè)無法回避的問題，看來拆分js的下載和執(zhí)行是不可行的，如是乎瀏覽器換了種方式，這個(gè)方式也就是在同一個(gè)時(shí)間能下載多個(gè)資源，我們?cè)倏瓷蠄D，在同一個(gè)域名下，firefox可以同時(shí)下載兩種圖片，chrome可以同時(shí)下載4個(gè)靜態(tài)資源，不過這是針對(duì)圖片和css文件，對(duì)于js文件似乎還是一個(gè)接著一個(gè)的下載，下載一個(gè)執(zhí)行一個(gè)，不過在ie8以上版本，js可以和圖片一樣并行加載，ie這樣做就提升了js文件下載的效率，不過到了js執(zhí)行時(shí)候還是要嚴(yán)格按照順序執(zhí)行。

多個(gè)http連接并行下載資源就好比多個(gè)線程共同完成某個(gè)任務(wù)，如果并行http連接更多，那么能有更多http資源同時(shí)被下載，但是瀏覽器提供并行執(zhí)行的http連接實(shí)在太少了，例如上面firefox才兩個(gè)，chrome也只有4個(gè)，那如何突破瀏覽器的連接個(gè)數(shù)的限制了？方法很簡(jiǎn)單就是將常用的，穩(wěn)定的靜態(tài)資源統(tǒng)一放在一個(gè)靜態(tài)資源服務(wù)器上，由統(tǒng)一的域名對(duì)外提供，這個(gè)域名要和主體請(qǐng)求的域名不一樣，原理是因?yàn)闉g覽器只通過域名來限制連接的個(gè)數(shù)，如果一個(gè)頁(yè)面里有兩個(gè)不同的域的，那么并行的http請(qǐng)求個(gè)數(shù)也會(huì)變成兩倍。這個(gè)做法有點(diǎn)討瀏覽器的巧，是程序員發(fā)現(xiàn)瀏覽器的特點(diǎn)而總結(jié)出的技術(shù)，它類似一個(gè)hack技術(shù)，而hack技術(shù)不會(huì)是標(biāo)準(zhǔn)技術(shù)，所以它肯定有它的瓶頸區(qū)，所以這樣的技術(shù)都是會(huì)有個(gè)度的，瀏覽器限制請(qǐng)求個(gè)數(shù)絕對(duì)不是無緣無故的，我們看百度頁(yè)面并行下載圖片的http協(xié)議的版本都是1.1，http1.1特點(diǎn)就是長(zhǎng)連接，長(zhǎng)連接的好處是在頁(yè)面和服務(wù)端頻繁交互時(shí)候效率很好，但是瀏覽器的頁(yè)面操作并不是總是頻繁的請(qǐng)求服務(wù)器，而為了加載靜態(tài)資源而創(chuàng)建很多長(zhǎng)連接，服務(wù)器會(huì)不得不維護(hù)大量無用的長(zhǎng)連接，給服務(wù)器的壓力是可想而知的。相比之下http1.0協(xié)議，它不使用長(zhǎng)連接，而是短連接，因此早期版本的瀏覽器會(huì)給http1.0協(xié)議開啟的連接數(shù)要高于http1.1連接數(shù)，因此有些網(wǎng)站將靜態(tài)資源服務(wù)器提供的http協(xié)議版本降低到1.0，這樣可以有效的提升瀏覽器的并發(fā)連接數(shù)，這個(gè)做法會(huì)給網(wǎng)頁(yè)性能帶來意想不到的提升，不過現(xiàn)代的瀏覽器似乎更愿意平等對(duì)待兩個(gè)不同版本的協(xié)議了，新版的瀏覽器有些將兩類協(xié)議的并發(fā)數(shù)變成一樣了。而對(duì)于處于客戶端地位的瀏覽器維護(hù)多個(gè)鏈接對(duì)于資源消耗是龐大的，而且域名過多也會(huì)增加dns解析的開銷，所以并發(fā)連接開啟越多，并不一定真的會(huì)達(dá)到提升性能的目的，那么多少個(gè)域最合適了？雅虎的前端工程師給了一個(gè)答案：2個(gè)是***的，這個(gè)數(shù)據(jù)怎么得來的我就不太清楚了，不過結(jié)果很簡(jiǎn)單很好用，記住就行了。

下面我就要聊聊如何解決js阻塞頁(yè)面加載的問題了，js之所以會(huì)阻塞UI線程的執(zhí)行，是因?yàn)閖s能控制UI的展示，而頁(yè)面加載的規(guī)則是要順序執(zhí)行，所以在碰到j(luò)s代碼時(shí)候UI線程會(huì)首先執(zhí)行它，而這點(diǎn)很多程序員不知道或者知道但被忽視，因此導(dǎo)致編寫代碼時(shí)候?qū)⒂糜谡故镜拇a和用于處理邏輯的代碼混淆在一起，這樣做的后果是使js代碼造成的阻塞更加嚴(yán)重，所以雅虎公司的前端團(tuán)隊(duì)提出了一個(gè)前端優(yōu)化的規(guī)則：將js腳本放置到html文檔的末尾，這樣就能有效的避免UI的阻塞。但是這個(gè)方法太簡(jiǎn)單了，不利于我們對(duì)網(wǎng)站進(jìn)行更加深入的優(yōu)化。為了做的深入，我們要需要更進(jìn)一步分析，首先我們知道js腳本按出現(xiàn)的位置分為兩類一類是行內(nèi)腳本即寫在頁(yè)面里的腳本，一類是js的外部文件，行內(nèi)腳本的優(yōu)化比較簡(jiǎn)單，就是盡量在頁(yè)面寫更少的代碼，就算要寫代碼也主要是控制頁(yè)面加載的UI顯示的代碼，沒必要的代碼就放在外部的js文件里，js外部文件優(yōu)化就比較復(fù)雜，為了精簡(jiǎn)行內(nèi)腳本，我們就不得不將大量的js代碼放到外部文件里，早先時(shí)候我都會(huì)盡量將所有外部js文件合并成一個(gè)js文件，但是現(xiàn)在我發(fā)現(xiàn)一個(gè)復(fù)雜的外部腳本很有可能會(huì)讓頁(yè)面的阻塞情況變得更加的嚴(yán)重，因此外部腳本要根據(jù)其功能拆分為展示腳本和邏輯腳本，但是事實(shí)上展示代碼和邏輯代碼很難分離，其實(shí)有個(gè)更加簡(jiǎn)單的標(biāo)準(zhǔn)讓我們拆分代碼：將所有外部代碼分為UI初始化代碼和其他代碼，，UI初始化代碼是在頁(yè)面加載時(shí)候執(zhí)行的代碼，我們現(xiàn)在只要判斷哪些代碼在頁(yè)面加載時(shí)候執(zhí)行就行了，這個(gè)標(biāo)準(zhǔn)就容易多了。

另外，上文我提到過我碰到頁(yè)面被js阻塞的情況，有時(shí)我為了調(diào)試js代碼會(huì)一直等待瀏覽器判斷無效的js加載失敗，那么我是怎么判斷瀏覽器已經(jīng)判斷外部js加載無效了？很簡(jiǎn)單就是查看瀏覽器忙指示結(jié)束，瀏覽器的忙指示如下圖所示：

忙指示(忙指示現(xiàn)象包括：瀏覽器選項(xiàng)卡的旋轉(zhuǎn)圓圈，鼠標(biāo)變成漏斗鼠標(biāo)，瀏覽器左下的狀態(tài)欄顯示正在加載某某url以及老版的ie顯示頁(yè)面加載進(jìn)度的現(xiàn)象)標(biāo)記結(jié)束了，就表明頁(yè)面的加載操作結(jié)束了，為了防止js腳本阻塞頁(yè)面加載，那么我們要做到的就是讓那些不會(huì)用于頁(yè)面初始化展示的js代碼的加載和執(zhí)行操作在瀏覽器忙指示結(jié)束后觸發(fā)，為了做到這一點(diǎn)我們就得知道忙指示結(jié)束后會(huì)觸發(fā)什么命令，這個(gè)命令就是瀏覽器的onload事件，因此我們讓那些和頁(yè)面加載無關(guān)的js腳本在onload方法里執(zhí)行，在onload事件里我就會(huì)使用dom技術(shù)，構(gòu)建script節(jié)點(diǎn)，設(shè)置它的src指向需要加載的腳本路徑，然后將這個(gè)srcipt節(jié)點(diǎn)加入到html文檔的head里，為了完全確保這個(gè)js在忙指示結(jié)束后執(zhí)行，我使用setTimeout方法調(diào)用動(dòng)態(tài)加載腳本的方法,進(jìn)一步確保代碼在忙指示結(jié)束后執(zhí)行，實(shí)踐下來感覺效果的確不錯(cuò)。

理解到這里我本來很高興，認(rèn)為自己又理解了一個(gè)前端開發(fā)的難點(diǎn)，并且有一個(gè)好的解決方案，但是等我回味一下發(fā)現(xiàn)有點(diǎn)不對(duì)頭，我經(jīng)常使用的jQuery定義了ready方法，ready方法會(huì)在dom加載完畢后執(zhí)行，而我自己的方案卻是在onload后執(zhí)行，代碼執(zhí)行遠(yuǎn)遠(yuǎn)落后jQuery的ready方法執(zhí)行時(shí)機(jī)，這個(gè)感覺讓我很不舒服，其次，在頁(yè)面開發(fā)里我們會(huì)使用很多第三方庫(kù)，雖然我現(xiàn)在開發(fā)盡量做到只用jQuery這一個(gè)第三方庫(kù)，但是其他人則不盡然，他們會(huì)使用很多第三方庫(kù)，很多庫(kù)有大量UI操作的通用方法，這些方法非常好用，經(jīng)常使用這些庫(kù)會(huì)導(dǎo)致我們自己寫的控制UI的js代碼常常會(huì)依賴它們，那么拆分UI控制腳本和其他腳本就無從談起了。總之，現(xiàn)在web前端開發(fā)太依賴第三方庫(kù)，就算一個(gè)牛逼的前端團(tuán)隊(duì)，拒絕使用第三方庫(kù)，什么都自己開發(fā)，當(dāng)web應(yīng)用變復(fù)雜后，通用庫(kù)和業(yè)務(wù)代碼的耦合度都是很難解決的問題，這也會(huì)導(dǎo)致我們沒法真正將UI展示代碼和邏輯代碼真正的分離。

我的方案其實(shí)滿足不了實(shí)際生產(chǎn)的需求，不夠***，所以本文到這里沒有推導(dǎo)出通用規(guī)則，真令人失望，面對(duì)上面的新問題那我們?cè)撛趺崔k了？這個(gè)問題不是無解的，現(xiàn)行技術(shù)就有它的解決方案，那就是無阻塞腳本的加載。無阻塞加載腳本技術(shù)的核心就是：加載js腳本時(shí)候，被加載的js腳本不會(huì)阻塞UI線程的執(zhí)行和以阻塞方式加載的腳本。

#p#

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

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

使用動(dòng)態(tài)創(chuàng)建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元素，這種方法還是盡量避免使用，而且這種方法也無法實(shí)現(xiàn)跨域。

Script DOM Element

可跨域方案，利用動(dòng)態(tài)插入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

動(dòng)態(tài)寫腳本的另一種方案，不過只在IE中是并行下載的。

代碼如下：

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

script defer和document.write Srcipt Tag不是跨瀏覽器的方案這里不推薦。

頁(yè)面嵌套iframe方案我沒有詳述，原因是我現(xiàn)在很討厭iframe，iframe是dom元素里開銷***的元素，有它就意味著慢，而且我最近碰到一個(gè)生產(chǎn)問題就是iframe引起，原因就是對(duì)iframe跨域造成，iframe跨域以后，父窗體和子窗體代碼就不能互訪了，而且iframe寫法的不正確（寫的很類似跨站腳本挾持）還會(huì)導(dǎo)致瀏覽器啟動(dòng)默認(rèn)的安全機(jī)制，最終出現(xiàn)用戶無法正常使用頁(yè)面的情況，所以我也不推薦使用iframe。

xhr eval也是我不會(huì)去使用的方式，因?yàn)樗胑val命令，而eval的使用常常會(huì)為黑客留下破壞你網(wǎng)站的漏洞。

因此***的方案就是xhr 注入和script dom element了，這兩個(gè)方案不存在瀏覽器兼容問題，而且后者還能跨域，不過跨域的選擇也是要謹(jǐn)慎的，跨域腳本也會(huì)帶來隱形的安全風(fēng)險(xiǎn)，不管怎么說這兩個(gè)方案使用場(chǎng)景基本上可以包括所有阻塞腳本加載的場(chǎng)景。

注意：無阻塞加載腳本的核心技術(shù)就是動(dòng)態(tài)的創(chuàng)建script的dom節(jié)點(diǎn)。

無阻塞腳本加載技術(shù)還有個(gè)好處就是，那些和頁(yè)面展示無關(guān)的腳本無須非要放在onload事件里執(zhí)行，它隨時(shí)隨地可以運(yùn)行簡(jiǎn)直就是***。

不過無阻塞腳本有個(gè)很大的隱患，這個(gè)隱患是很多會(huì)使用無阻塞腳本技術(shù)的程序員都會(huì)忽視的問題，這個(gè)問題就是無阻塞腳本很容易產(chǎn)生“變量未定義”的問題，這個(gè)問題的本質(zhì)就是無阻塞腳本會(huì)破壞js腳本加載順序的問題，當(dāng)某個(gè)腳本依賴于另一個(gè)腳本時(shí)候，而另一個(gè)腳本又沒有加載執(zhí)行完畢，***就會(huì)產(chǎn)生“變量未定義”的問題，例如jQuery沒有提前加載，因此使用$時(shí)候提示$變量未定義。

那么我們?cè)撊绾谓鉀Q這個(gè)問題了，我們的思路就是讓那些依賴于無阻塞加載的腳本的js代碼在腳本加載完畢后才會(huì)執(zhí)行，我們需要一個(gè)辦法將無序的腳本加載變得有序，上面我推薦的兩種方法都是使用dom技術(shù)創(chuàng)建script節(jié)點(diǎn)，然后將該節(jié)點(diǎn)加入到文檔的head頭部，對(duì)于script節(jié)點(diǎn)，在非ie瀏覽器下有一個(gè)onload事件，該事件會(huì)在script加載完畢后才會(huì)執(zhí)行，ie瀏覽器下有onreadystatechange事件，而ie下script的dom節(jié)點(diǎn)有一個(gè)readystate屬性，它的取值如下：

1.uninitialized（未初始化）：對(duì)象存在尚未初始化；

2.loading（正在加載）：對(duì)象正在加載數(shù)據(jù)；

3.loaded（加載完畢）：對(duì)象數(shù)據(jù)加載完成

4.interactive（交互）：可以操作對(duì)象，但是還沒有完全加載；

5.complete（完成）：對(duì)象已經(jīng)加載完畢。

具體用法如下所示：

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

這個(gè)做法就是為dom加載定義了一個(gè)回調(diào)函數(shù)，當(dāng)dom加載完畢后回調(diào)函數(shù)才會(huì)執(zhí)行，這樣就解決了代碼執(zhí)行順序的問題了。

另外還有一個(gè)方式就是使用setTimeout，具體使用就是定義一個(gè)輪詢，判斷需要使用的變量是否存在，如果不存在，就繼續(xù)輪詢，如果變量存在則停止輪詢，代碼模式如下所示：

代碼如下：

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

無阻塞腳本的好處就是不會(huì)阻塞UI的執(zhí)行，也不會(huì)影響其他同步j(luò)s代碼的執(zhí)行，不過無阻塞腳本改變了腳本的加載順序，所以在使用無阻塞腳本時(shí)候一定要更加注意腳本之間的依賴關(guān)系，保證整個(gè)頁(yè)面的腳本都能正常執(zhí)行。

在以前的文章里我多次提到了js的模塊加載技術(shù)，時(shí)下流行的模塊加載技術(shù)有進(jìn)口貨requirejs和國(guó)產(chǎn)貨seajs，使用這些技術(shù)，我們會(huì)發(fā)現(xiàn)js文件加載都是按模塊加載的，也就是說你頁(yè)面定義了多少個(gè)js模塊，那么這個(gè)頁(yè)面就有多少個(gè)js文件，剛開始使用它們時(shí)候我很詫異，按照前端優(yōu)化原則http請(qǐng)求越少越好，為什么先進(jìn)的模塊技術(shù)卻會(huì)讓js文件變得更多了，接著我分析了下它們加載js的請(qǐng)求，終于明白了，它們都使用的無阻塞腳本加載技術(shù)，即使用script節(jié)點(diǎn)方式加載腳本，這樣就很容易屏蔽js帶來的阻塞問題了。

上面的實(shí)例中我使用script節(jié)點(diǎn)將腳本都是嵌入到head節(jié)點(diǎn)里，這個(gè)似乎和將腳本置于html文檔末尾的原則不同，這個(gè)是不是需要改進(jìn)了，答案是不需要改進(jìn)，將腳本置于文檔末尾目的是為了避免js的阻塞，而我們使用無阻塞腳本了，這個(gè)問題不是解決了嗎？所以代碼置于head標(biāo)簽還是html文檔底部也就無關(guān)緊要了。

***我要糾正一個(gè)錯(cuò)誤的觀點(diǎn)，頁(yè)面加載的總時(shí)間是衡量頁(yè)面加載快捷的標(biāo)準(zhǔn)嗎？答案是，的確是個(gè)標(biāo)準(zhǔn)，但是不是最精確的標(biāo)準(zhǔn)，頁(yè)面同步阻塞加載的時(shí)間才是衡量頁(yè)面加載效率的準(zhǔn)確標(biāo)準(zhǔn)，非阻塞腳本加載可能會(huì)增加整個(gè)頁(yè)面加載的時(shí)間，但是它可以減少頁(yè)面阻塞加載的時(shí)間，而頁(yè)面阻塞才是影響用戶體驗(yàn)的元兇，頁(yè)面優(yōu)化最重要的關(guān)注點(diǎn)就是你所看到的的東西要加載的更加快。

無阻塞腳本可以分割外部腳本的下載和執(zhí)行操作，這是程序員使用的hack技術(shù)，它很酷，但是會(huì)導(dǎo)致程序的復(fù)雜度增加，可讀性下降，所以它應(yīng)該是web前端架構(gòu)師的技術(shù)，日常開發(fā)我們要慎用它。

原文出自：http://www.cnblogs.com/sharpxiajun/p/4072396.html