一、同步加載與異步加載的形式
1. 同步加載
我們平時(shí)最常使用的就是這種同步加載形式：
<script src="http://yourdomain.com/script.js"></script>
同步模式，又稱(chēng)阻塞模式，會(huì)阻止瀏覽器的后續(xù)處理，停止了后續(xù)的解析，因此停止了后續(xù)的文件加載（如圖像）、渲染、代碼執(zhí)行。
js 之所以要同步執(zhí)行，是因?yàn)?js 中可能有輸出 document 內(nèi)容、修改dom、重定向等行為，所以默認(rèn)同步執(zhí)行才是安全的。
以前的一般建議是把<script>放在頁(yè)面末尾</body>之前，這樣盡可能減少這種阻塞行為，而先讓頁(yè)面展示出來(lái)。
簡(jiǎn)單說(shuō)：加載的網(wǎng)絡(luò) timeline 是瀑布模型，而異步加載的 timeline 是并發(fā)模型。
2. 常見(jiàn)異步加載（Script DOM Element）

異步加載又叫非阻塞，瀏覽器在下載執(zhí)行 js 同時(shí)，還會(huì)繼續(xù)進(jìn)行后續(xù)頁(yè)面的處理。
這種方法是在頁(yè)面中<script>標(biāo)簽內(nèi)，用 js 創(chuàng)建一個(gè) script 元素并插入到 document 中。這樣就做到了非阻塞的下載 js 代碼。
async屬性是HTML5中新增的異步支持，見(jiàn)后文解釋?zhuān)由虾茫ú患右膊挥绊懀?
此方法被稱(chēng)為 Script DOM Element 法，不要求 js 同源。
將js代碼包裹在匿名函數(shù)中并立即執(zhí)行的方式是為了保護(hù)變量名泄露到外部可見(jiàn)，這是很常見(jiàn)的方式，尤其是在 js 庫(kù)中被普遍使用。
例如 Google Analytics 和 Google+ Badge 都使用了這種異步加載代碼：

但是，這種加載方式在加載執(zhí)行完之前會(huì)阻止 onload 事件的觸發(fā)，而現(xiàn)在很多頁(yè)面的代碼都在 onload 時(shí)還要執(zhí)行額外的渲染工作等，所以還是會(huì)阻塞部分頁(yè)面的初始化處理。


3. onload 時(shí)的異步加載

這和前面的方式差不多，但關(guān)鍵是它不是立即開(kāi)始異步加載 js ，而是在 onload 時(shí)才開(kāi)始異步加載。這樣就解決了阻塞 onload 事件觸發(fā)的問(wèn)題。
補(bǔ)充：DOMContentLoaded 與 OnLoad 事件
DOMContentLoaded : 頁(yè)面(document)已經(jīng)解析完成，頁(yè)面中的dom元素已經(jīng)可用。但是頁(yè)面中引用的圖片、subframe可能還沒(méi)有加載完。
OnLoad：頁(yè)面的所有資源都加載完畢（包括圖片）。瀏覽器的載入進(jìn)度在這時(shí)才停止。
這兩個(gè)時(shí)間點(diǎn)將頁(yè)面加載的timeline分成了三個(gè)階段。
4.異步加載的其它方法
由于Javascript的動(dòng)態(tài)特性，還有很多異步加載方法：
XHR Eval
XHR Injection
Script in Iframe
Script Defer
document.write Script Tag
還有一種方法是用 setTimeout 延遲0秒 與 其它方法組合。
XHR Eval ：通過(guò) ajax 獲取js的內(nèi)容，然后 eval 執(zhí)行。
var xhrObj = getXHRObject();

Script in Iframe：創(chuàng)建并插入一個(gè)iframe元素，讓其異步執(zhí)行 js 。

GMail Mobile：頁(yè)內(nèi) js 的內(nèi)容被注釋?zhuān)圆粫?huì)執(zhí)行，然后在需要的時(shí)候，獲取script元素中 text 內(nèi)容，去掉注釋后 eval 執(zhí)行。

詳見(jiàn)參考資料中2010年的Velocity 大會(huì) Steve Souders 和淘寶的那兩個(gè)講義。

二、async 和 defer 屬性

1. defer 屬性
<script src="file.js" defer></script>
defer屬性聲明這個(gè)腳本中將不會(huì)有 document.write 或 dom 修改。
瀏覽器將會(huì)并行下載 file.js 和其它有 defer 屬性的script，而不會(huì)阻塞頁(yè)面后續(xù)處理。
defer屬性在IE 4.0中就實(shí)現(xiàn)了，超過(guò)13年了！Firefox 從 3.5 開(kāi)始支持defer屬性 。
注：所有的defer 腳本保證是按順序依次執(zhí)行的。
2. async 屬性
<script src="file.js" async></script>
async屬性是HTML5新增的。作用和defer類(lèi)似，但是它將在下載后盡快執(zhí)行，不能保證腳本會(huì)按順序執(zhí)行。它們將在onload 事件之前完成。
Firefox 3.6、Opera 10.5、IE 9 和 最新的Chrome 和 Safari 都支持 async 屬性。可以同時(shí)使用 async 和 defer，這樣IE 4之后的所有 IE 都支持異步加載。
3. 詳細(xì)解釋
<script> 標(biāo)簽在 HTML 4.01 與 HTML5 的區(qū)別：
type 屬性在HTML 4中是必須的，在HTML5中是可選的。
async 屬性是HTML5中新增的。
個(gè)別屬性（xml:space）在HTML5中不支持。
說(shuō)明：
沒(méi)有 async 屬性，script 將立即獲取（下載）并執(zhí)行，然后才繼續(xù)后面的處理，這期間阻塞了瀏覽器的后續(xù)處理。
如果有 async 屬性，那么 script 將被異步下載并執(zhí)行，同時(shí)瀏覽器繼續(xù)后續(xù)的處理。
HTML4中就有了defer屬性，它提示瀏覽器這個(gè) script 不會(huì)產(chǎn)生任何文檔元素（沒(méi)有document.write），因此瀏覽器會(huì)繼續(xù)后續(xù)處理和渲染。
如果沒(méi)有 async 屬性 但是有 defer 屬性，那么script 將在頁(yè)面parse之后執(zhí)行。
如果同時(shí)設(shè)置了二者，那么 defer 屬性主要是為了讓不支持 async 屬性的老瀏覽器按照原來(lái)的 defer 方式處理，而不是同步方式。
另參見(jiàn)官方說(shuō)明：script async
個(gè)人補(bǔ)充：
既然 HTML5 中已經(jīng)支持異步加載，為什么還要使用前面推薦的那種麻煩（動(dòng)態(tài)創(chuàng)建 script 元素）的方式？
答：為了兼容尚不支持 async 老瀏覽器。如果將來(lái)所有瀏覽器都支持了，那么直接在script中加上async 屬性是最簡(jiǎn)單的方式。

三、延遲加載（lazy loading）

前面解決了異步加載（async loading）問(wèn)題，再談?wù)勈裁词茄舆t加載。
延遲加載：有些 js 代碼并不是頁(yè)面初始化的時(shí)候就立刻需要的，而稍后的某些情況才需要的。延遲加載就是一開(kāi)始并不加載這些暫時(shí)不用的js，而是在需要的時(shí)候或稍后再通過(guò)js 的控制來(lái)異步加載。
也就是將 js 切分成許多模塊，頁(yè)面初始化時(shí)只加載需要立即執(zhí)行的 js ，然后其它 js 的加載延遲到第一次需要用到的時(shí)候再加載。
特別是頁(yè)面有大量不同的模塊組成，很多可能暫時(shí)不用或根本就沒(méi)用到。
就像圖片的延遲加載，在圖片出現(xiàn)在可視區(qū)域內(nèi)時(shí)（在滾動(dòng)條下拉）才加載顯示圖片。

四、script 的兩階段加載 與 延遲執(zhí)行（lazy execution）

JS的加載其實(shí)是由兩階段組成：下載內(nèi)容（download bytes）和執(zhí)行（parse and execute）。
瀏覽器在下載完 js 的內(nèi)容后就會(huì)立即對(duì)其解析和執(zhí)行，不管是同步加載還是異步加載。
前面說(shuō)的異步加載，解決的只是下載階段的問(wèn)題，但代碼在下載后會(huì)立即執(zhí)行。
而瀏覽器在解析執(zhí)行 JS 階段是阻塞任何操作的，這時(shí)的瀏覽器處于無(wú)響應(yīng)狀態(tài)。
我 們都知道通過(guò)網(wǎng)絡(luò)下載 script 需要明顯的時(shí)間，但容易忽略了第二階段，解析和執(zhí)行也是需要時(shí)間的。script的解析和執(zhí)行所花的時(shí)間比我們想象的要多，尤其是script 很多很大的時(shí)候。有些是需要立刻執(zhí)行，而有些則不需要（比如只是在展示某個(gè)界面或執(zhí)行某個(gè)操作時(shí)才需要）。
這些script 可以延遲執(zhí)行，先異步下載緩存起來(lái)，但不立即執(zhí)行，而是在第一次需要的時(shí)候執(zhí)行一次。
利用特殊的技巧可以做到 下載 與 執(zhí)行的分離 (再次感謝 javascript 的動(dòng)態(tài)特性)。比如將 JS 的內(nèi)容作為 Image或 object 對(duì)象加載緩存起來(lái)，所以就不會(huì)立即執(zhí)行了，然后在第一次需要的時(shí)候再執(zhí)行。
此部分的更多解釋 請(qǐng)查看末尾參考資料中 ControlJS 的相關(guān)鏈接。
小技巧：
1. 模擬較長(zhǎng)的下載時(shí)間：
寫(xiě)個(gè)后端腳本，讓其 sleep 一定時(shí)間。如在 jsp 中 Thread.sleep(5000); ，這樣5秒后才能收到內(nèi)容。
2. 模擬較長(zhǎng)的 js 代碼執(zhí)行時(shí)間（因?yàn)檫@步一般比較快不容易觀察到）：
var t_start = Number(new Date());
while ( t_start + 5000 > Number(new Date()) ) {}
這個(gè)代碼將使 js 執(zhí)行5秒才能完成！

五、script 標(biāo)簽使用的歷史

1. script 放在 HEAD 中

阻止了后續(xù)的下載；
在IE 6-7 中 script 是順序下載的，而不是現(xiàn)在的 “并行下載、順序執(zhí)行” 的方式；
在下載和解析執(zhí)行階段阻止渲染（rendering）；
2. script 放在頁(yè)面底部（2007）
...
<script src=“…”></script>
</body>

不阻止其它下載；
在IE 6-7 中 script 是順序下載的；
在下載和解析執(zhí)行階段阻止渲染（rendering）；
3. 異步加載script（2009）


這就是本文主要說(shuō)的方式。
不阻止其它下載；
在所有瀏覽器中，script都是并行下載；
只在解析執(zhí)行階段阻止渲染（rendering）；
4. 異步下載 + 按需執(zhí)行 (2010)

把下載 js 與 解析執(zhí)行 js 分離出來(lái)
不阻止其它下載；
在所有瀏覽器中，script都是并行下載；
不阻止渲染（rendering）直到真正需要時(shí)；
六、異步加載的問(wèn)題
在異步加載的時(shí)候，無(wú)法使用 document.write 輸出文檔內(nèi)容。
在同步模式下，document.write 是在當(dāng)前 script 所在的位置輸 出文檔的。而在異步模式下，瀏覽器繼續(xù)處理后續(xù)頁(yè)面內(nèi)容，根本無(wú)法確定 document.write 應(yīng)該輸出到什么位置，所以異步模式下 document.write 不可行。而到了頁(yè)面已經(jīng) onload 之后，再執(zhí)行 document.write 將導(dǎo)致當(dāng)前頁(yè)面的內(nèi)容被清空，因?yàn)樗鼤?huì)自動(dòng)觸發(fā) document.open 方法。
實(shí)際上document.write的名聲并不好，最好少用。
替代方法：
1. 雖然異步加載不能用 document.write，但還是可以onload之后執(zhí)行操作dom（創(chuàng)建dom或修改dom）的，這樣可以實(shí)現(xiàn)一些自己的動(dòng)態(tài)輸出。比如要在頁(yè)面異步創(chuàng)建一個(gè)浮動(dòng)元素，這和它在頁(yè)面中的位置就沒(méi)關(guān)系了，只要?jiǎng)?chuàng)建出該dom元素添加到 document 中即可。
2. 如果需要在固定位置異步生成元素的內(nèi)容，那么可以在該固定位置設(shè)置一個(gè)dom元素作為目標(biāo)，這樣就知道位置了，異步加載之后就可以對(duì)這個(gè)元素進(jìn)行修改。
六、JS 模塊化管理
異步加載，需要將所有 js 內(nèi)容按模塊化的方式來(lái)切分組織，其中就存在依賴(lài)關(guān)系，而異步加載不保證執(zhí)行順序。
另外，namespace 如何管理 等相關(guān)問(wèn)題。這部分已超出本文內(nèi)容，可參考：

最新評(píng)論