[轉]瀏覽器渲染機制——一定要放在body底部的js引用

標籤：

轉自：http://blog.csdn.net/u012251421/article/details/50536265

說明：

1. 本文提到的瀏覽器均是指Chrome。

2. “script標籤“指的都是普通的不帶其他屬性的外聯javascript。

3. web效能最佳化的手段並不是非黑即白的，有些手段過頭了反而降低效能，所以在討論條件和結論的時候，雖然很多條件本身會帶來其他細微的負面或正面影響，為了不使論述失去重點，不會擴充太開。

一、從一個面試題說起

面試前端的時候我喜歡問一些看上去是常識的問題。比如：為什麼大家普遍把<script src=""></script>這樣的代碼放在body最底部？（為了溝通效率，我會提前和對方約定所有的討論都以chrome為例）

應聘者一般會回答：因為瀏覽器產生Dom樹的時候是一行一行讀HTML代碼的，script標籤放在最後面就不會影響前面的頁面的渲染。

我很雞賊地接著問：既然Dom樹完全產生好後頁面才能渲染出來，瀏覽器又必須讀完全部HTML才能產生完整的Dom樹，script標籤不放在body底部是不是也一樣？

這其實是個開放性的問題，裡面涉及的概念的界定本身就很重要。

“頁面渲染出來了” 指的是什嗎？

嚴格來說，我的最後一問是有歧義的：我們需要統一一下什麼叫我們經常掛在嘴邊的“頁面渲染出來了” —— 指的是是 “首屏顯示出來了” 還是 “頁面完整地載入好了”（後面統稱StepC） ？ 
如果指的是首屏顯示出來了，那麼問題又來了：假設網頁首屏有圖片，這裡的“首屏” 指的是 “顯示了全部圖片的首屏”（後面統稱StepB） 還是 “沒有圖片的首屏”（後面統稱StepA）。

確定清楚 “頁面渲染出來了” 指的是 StepA、StepB、StepC 中的哪一個是非常關鍵的（雖然至今還沒有一個應聘者嘗試這麼做過），如果 “頁面渲染出來了” 指的是 StepC，那麼我的最後一問的答案是肯定的——script標籤不放在body底部不會拖慢頁面完整地載入好的時間。

顯然，我們往往更關心首屏時間，所以，如果 “頁面渲染出來了” 特指“沒有圖片的首屏”，那我的最後一問變成了下面這樣，又該如何回答呢？

既然Dom樹完全產生好後才能顯示“沒有圖片的首屏”，瀏覽器又必須讀完全部HTML才能產生完整的Dom樹，script標籤不放在body底部是不是也一樣？

陷阱

然而上面的問題還是存在一個陷阱——既然Dom樹完全產生好後才能顯示“沒有圖片的首屏”這句話是帶詐騙，“沒有圖片的首屏”並不以“完整的Dom樹”為必要條件。也就是說：在產生Dom樹的過程中只要某些條件具備了，“沒有圖片的首屏”就能顯示出來。

所以，拋開這些歧義和陷阱，我的問題變成了：

script標籤的位置會影響首屏時間嗎？

然而答案並不是那麼顯而易見，這得從瀏覽器的渲染機制說起。（再一次說明：本文所說的瀏覽器都是指chrome）

二、瀏覽器的渲染機制

Google Web Fundamentals 是一個非常優秀的文檔，裡面講到了跟web、瀏覽器、前端的方方面面。我總結一下其中的 Ilya Grigorik 寫的 Critical rendering path 瀏覽器渲染機制部分的內容如下：

幾個概念

1、DOM：Document Object Model，瀏覽器將HTML解析成樹形的資料結構，簡稱DOM。

2、CSSOM：CSS Object Model，瀏覽器將CSS代碼解析成樹形的資料結構。

3、DOM 和 CSSOM 都是以 Bytes → characters → tokens → nodes → object model. 這樣的方式產生最終的資料。如所示：

DOM 樹的構建過程是一個深度遍曆過程：當前節點的所有子節點都構建好後才會去構建當前節點的下一個兄弟節點。

4、Render Tree：DOM 和 CSSOM 合并後產生 Render Tree，如：

Render Tree 和DOM一樣，以多叉樹的形式儲存了每個節點的css屬性、節點本身屬性、以及節點的孩子節點。

注意：display:none 的節點不會被加入 Render Tree，而 visibility: hidden 則會，所以，如果某個節點最開始是不顯示的，設為 display:none 是更優的。（具體可以看這裡）

瀏覽器的渲染過程

1. Create/Update DOM And request css/image/js：瀏覽器請求到HTML代碼後，在產生DOM的最開始階段（應該是 Bytes → characters 後），並行發起css、圖片、js的請求，無論他們是否在HEAD裡。
   注意：發起 js 檔案的下載 request 並不需要 DOM 處理到那個 script 節點，比如：簡單的正則匹配就能做到這一點，雖然實際上並不一定是通過正則：）。這是很多人在理解渲染機制的時候存在的誤區。

2. Create/Update Render CSSOM：CSS檔案下載完成，開始構建CSSOM

3. Create/Update Render Tree：所有CSS檔案下載完成，CSSOM構建結束後，和 DOM 一起產生 Render Tree。

4. Layout：有了Render Tree，瀏覽器已經能知道網頁中有哪些節點、各個節點的CSS定義以及他們的從屬關係。下一步操作稱之為Layout，顧名思義就是計算出每個節點在螢幕中的位置。

5. Painting：Layout後，瀏覽器已經知道了哪些節點要顯示（which nodes are visible）、每個節點的CSS屬性是什麼（their computed styles）、每個節點在螢幕中的位置是哪裡（geometry）。就進入了最後一步：Painting，按照算出來的規則，通過顯卡，把內容畫到螢幕上。

以上五個步驟前3個步驟之所有使用 “Create/Update” 是因為DOM、CSSOM、Render Tree都可能在第一次Painting後又被更新多次，比如JS修改了DOM或者CSS屬性。

Layout 和 Painting 也會被重複執行，除了DOM、CSSOM更新的原因外，圖片下載完成後也需要調用Layout 和 Painting來更新網頁。

看 Timeline，一目瞭然

我扒了一段有贊PC首頁的代碼到本地，通過Node跑起來。Node作為Server端，對/js/jquery.js 做了延時2s返回的處理，並且把<script src="http://127.0.0.1:8080/js/jquery.js"></script> 放到導覽列的下面，結果是這樣的：

從上面的Timeline我們可以看出：

• 首屏時間和DomContentLoad事件沒有必然的先後關係

• 所有CSS儘早載入是減少首屏時間的最關鍵

• js的下載和執行會阻塞Dom樹的構建（嚴謹地說是中斷了Dom樹的更新），所以script標籤放在首屏範圍內的HTML程式碼片段裡會截斷首屏的內容。

• script標籤放在body底部，做與不做async或者defer處理，都不會影響首屏時間，但影響DomContentLoad和load的時間，進而影響依賴他們的代碼的執行的開始時間。

三、問題的答案

回到前面的問題：

script標籤的位置會影響首屏時間嗎？

答案是：不影響（如果這裡裡的首屏指的是頁面從白板變成網頁畫面——也就是第一次Painting），但有可能截斷首屏的內容，使其只顯示上面一部分。

為什麼說是“有可能”呢？，如果該js下載地比css還快，或者script標籤不在第一屏的html裡，實際上是不影響的。明白這一影響邊界非常重要，這樣我們在考察頁面效能瓶頸的時候就有的放矢了。舉個例子：在網頁的第二屏有一個通用模組，實際上我們是可以把它的js邏輯獨立成一個檔案，將模組的html和js標籤放在一起做成獨立的模板引進來的（如果它的js比較小或者說因為多了一個檔案會多佔用一個TCP串連和頻寬，這實際上是另外一個話題了，請參考我文章開頭的聲明）。

四、總結、再進一步

所以，總算弄清楚這個眾所周知的常識了。我們來總結一下：

• 如果script標籤的位置不在首屏範圍內，不影響首屏時間

• 所有的script標籤應該放在body底部是很有道理的

• 但從效能最優的角度考慮，即使在body底部的script標籤也會拖慢首屏出來的速度，因為瀏覽器在最一開始就會請求它對應的js檔案，而這，佔用了有限的TCP連結數、頻寬甚至運行它所需要的CPU。這也是為什麼script標籤會有async或defer屬性的原因之一。

可是，在複雜的實際應用情境中，要貫徹這幾條結論可能會遇到問題，比如：

• 你的頁面是分模組來寫的，每一個模組都有自己的html、js甚至css，當把這些模組湊到一個頁面中的時候就會出現js自然而然地出現在HTML中間部分。你很難把script標籤都放到底部

• 即使你把script標籤都放到底部，但script標籤的存在終究是拖慢了首屏時間、DomContendLoad和loaded的時間。如果只有一個script標籤，我們可以加一個async，但多個async的script標籤的結果會是js檔案被亂序執行的，這顯然不是我們想要的。

我們也遇到了這樣的問題，所以就做了一個開源項目：Tiny-Loader —— A small loader that load CSS/JS in best way for page performance 簡單好用。

[轉]瀏覽器渲染機制——一定要放在body底部的js引用