script標簽中的async和defer詳細說明與使用場景

更新時間：2023年02月18日 14:54:56 作者：賈順名

這篇文章主要介紹了script標簽中的async和defer詳細說明與使用場景,需要的朋友可以參考下

script標簽用于加載腳本與執(zhí)行腳本，在前端開發(fā)中可以說是非常重要的標簽了。
直接使用script腳本的話，html會按照順序來加載并執(zhí)行腳本，在腳本加載&執(zhí)行的過程中，會阻塞后續(xù)的DOM渲染。

現在大家習慣于在頁面中引用各種的第三方腳本，如果第三方服務商出現了一些小問題，比如延遲之類的，就會使得頁面白屏。
好在script提供了兩種方式來解決上述問題，async和defer，這兩個屬性使得script都不會阻塞DOM的渲染。
但既然會存在兩個屬性，那么就說明，這兩個屬性之間肯定是有差異的。

defer

如果script標簽設置了該屬性，則瀏覽器會異步的下載該文件并且不會影響到后續(xù)DOM的渲染；
如果有多個設置了defer的script標簽存在，則會按照順序執(zhí)行所有的script；
defer腳本會在文檔渲染完畢后，DOMContentLoaded事件調用前執(zhí)行。

我們做了一個測試頁面，頁面中包含了兩個script標簽的加載，給他們都加上defer標識。
P.S. 為了更直觀，我們給script1.js添加了1s的延遲，給script2.js添加了2s的延遲。

下圖是頁面加載的過程&script腳本的輸出順序。
不難看出，雖然script1加載用時雖然比script2短，但因為defer的限制，所以Ta只能等前邊的腳本執(zhí)行完畢后才能執(zhí)行。

async

async的設置，會使得script腳本異步的加載并在允許的情況下執(zhí)行
async的執(zhí)行，并不會按著script在頁面中的順序來執(zhí)行，而是誰先加載完誰執(zhí)行。

我們修改測試頁面如下：

遂得到了如下的結果，頁面加載時長上，并沒有什么變化，畢竟都是異步加載的腳本。
但是我們可以看到一個小細節(jié)，DOMContentLoaded事件的觸發(fā)并不受async腳本加載的影響，在腳本加載完之前，就已經觸發(fā)了DOMContentLoaded。

我們接著修改測試頁面。加載一個沒有延遲的script腳本，使得腳本可以即時的加載完畢。
我們要測試一下，如果async腳本加載的足夠快，是否會在DOMContentLoaded之前就執(zhí)行（這個實驗是基于對async的描述“在允許的情況下執(zhí)行”的論證）。
同時為了保證測試的穩(wěn)定性，我們在script腳本引入的后邊添加了數千個空的div節(jié)點，用來延長文檔的渲染時間。

執(zhí)行結果不出所料，如果給async一定的時間，是有可能在DOMContentLoaded事件之前就執(zhí)行的。

P.S. 從上圖中左上角的火焰圖中，我們也能看到，出現了多段的藍色（更新：晚上寫的時候懵了，紫色的才是渲染，藍色的是解析）文檔渲染。以及下邊Console的順序。
說明的確，async的執(zhí)行是加載完成就會去執(zhí)行，而不像defer那樣要等待所有的腳本加載完后按照順序執(zhí)行。

畫幾張圖簡要說明

網上有了不少這種類似的圖，但是基本都是拿一個script就舉例的
未免太過寒酸，so咱們來一個豪華版，來畫一下多個腳本加載時的甘特圖
就像近年來各大手機廠商，出新機都喜歡來一個X+X plus

拿四個不同的顏色來標明各自代表的含義

更正：文檔渲染應該為文檔解析

普通script

文檔解析的過程中，如果遇到script腳本，就會停止頁面的解析進行下載（但是Chrome會做一個優(yōu)化，如果遇到script腳本，會快速的查看后邊有沒有需要下載其他資源的，如果有的話，會先下載那些資源，然后再進行下載script所對應的資源，這樣能夠節(jié)省一部分下載的時間 @Update: 2018-08-17）。
資源的下載是在解析過程中進行的，雖說script1腳本會很快的加載完畢，但是他前邊的script2并沒有加載&執(zhí)行，所以他只能處于一個掛起的狀態(tài)，等待script2執(zhí)行完畢后再執(zhí)行。
當這兩個腳本都執(zhí)行完畢后，才會繼續(xù)解析頁面。