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

異步加載又叫非阻塞，瀏覽器在下載執(zhí)行 js 同時，還會繼續(xù)進行后續(xù)頁面的處理。
這種方法是在頁面中<script>標簽內(nèi)，用 js 創(chuàng)建一個 script 元素并插入到 document 中。這樣就做到了非阻塞的下載 js 代碼。
async屬性是HTML5中新增的異步支持，見后文解釋，加上好（不加也不影響）。
此方法被稱為 Script DOM Element 法，不要求 js 同源。
將js代碼包裹在匿名函數(shù)中并立即執(zhí)行的方式是為了保護變量名泄露到外部可見，這是很常見的方式，尤其是在 js 庫中被普遍使用。
例如 Google Analytics 和 Google+ Badge 都使用了這種異步加載代碼：

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


3. onload 時的異步加載

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

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

GMail Mobile：頁內(nèi) js 的內(nèi)容被注釋，所以不會執(zhí)行，然后在需要的時候，獲取script元素中 text 內(nèi)容，去掉注釋后 eval 執(zhí)行。

詳見參考資料中2010年的Velocity 大會 Steve Souders 和淘寶的那兩個講義。

二、async 和 defer 屬性

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

三、延遲加載（lazy loading）

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

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

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

五、script 標簽使用的歷史

1. script 放在 HEAD 中

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

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


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

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

最新評論