摘要：所以，拋開這些歧義和陷阱，我的問題變成了標(biāo)簽的位置會(huì)影響首屏?xí)r間么然而答案并不是那么顯而易見，這得從瀏覽器的渲染機(jī)制說起。

說明：

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

“script標(biāo)簽“指的都是普通的不帶其他屬性的外聯(lián)javascript。

web性能優(yōu)化的手段并不是非黑即白的，有些手段過頭了反而降低性能，所以在討論條件和結(jié)論的時(shí)候，雖然很多條件本身會(huì)帶來其他細(xì)微的負(fù)面或正面影響，為了不使論述失去重點(diǎn)，不會(huì)擴(kuò)展太開。

面試前端的時(shí)候我喜歡問一些看上去是常識(shí)的問題。比如：為什么大家普遍把這樣的代碼放在body最底部？（為了溝通效率，我會(huì)提前和對(duì)方約定所有的討論都以chrome為例）
應(yīng)聘者一般會(huì)回答：因?yàn)闉g覽器生成Dom樹的時(shí)候是一行一行讀HTML代碼的，script標(biāo)簽放在最后面就不會(huì)影響前面的頁面的渲染。
我很雞賊地接著問：既然Dom樹完全生成好后頁面才能渲染出來，瀏覽器又必須讀完全部HTML才能生成完整的Dom樹，script標(biāo)簽不放在body底部是不是也一樣？

留
一
段
空
白
讓
你
先
想
一
想

這其實(shí)是個(gè)開放性的問題，里面涉及的概念的界定本身就很重要。

嚴(yán)格來說，我的最后一問是有歧義的：我們需要統(tǒng)一一下什么叫我們經(jīng)常掛在嘴邊的“頁面渲染出來了” —— 指的是是 “首屏顯示出來了” 還是 “頁面完整地加載好了”（后面統(tǒng)稱StepC） ？
如果指的是首屏顯示出來了，那么問題又來了：假設(shè)網(wǎng)頁首屏有圖片，這里的“首屏” 指的是 “顯示了全部圖片的首屏”（后面統(tǒng)稱StepB） 還是 “沒有圖片的首屏”（后面統(tǒng)稱StepA）。

確定清楚 “頁面渲染出來了” 指的是 StepA、StepB、StepC 中的哪一個(gè)是非常關(guān)鍵的（雖然至今還沒有一個(gè)應(yīng)聘者嘗試這么做過），如果 “頁面渲染出來了” 指的是 StepC，那么我的最后一問的答案是肯定的——script標(biāo)簽不放在body底部不會(huì)拖慢頁面完整地加載好的時(shí)間。

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

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

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

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

script標(biāo)簽的位置會(huì)影響首屏?xí)r間么？

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

Google Web Fundamentals 是一個(gè)非常優(yōu)秀的文檔，里面講到了跟web、瀏覽器、前端的方方面面。我總結(jié)一下其中的 Ilya Grigorik 寫的 Critical rendering path 瀏覽器渲染機(jī)制部分的內(nèi)容如下：

1、DOM：Document Object Model，瀏覽器將HTML解析成樹形的數(shù)據(jù)結(jié)構(gòu)，簡(jiǎn)稱DOM。

2、CSSOM：CSS Object Model，瀏覽器將CSS代碼解析成樹形的數(shù)據(jù)結(jié)構(gòu)。

3、DOM 和 CSSOM 都是以 Bytes → characters → tokens → nodes → object model. 這樣的方式生成最終的數(shù)據(jù)。如下圖所示：

DOM 樹的構(gòu)建過程是一個(gè)深度遍歷過程：當(dāng)前節(jié)點(diǎn)的所有子節(jié)點(diǎn)都構(gòu)建好后才會(huì)去構(gòu)建當(dāng)前節(jié)點(diǎn)的下一個(gè)兄弟節(jié)點(diǎn)。

4、Render Tree：DOM 和 CSSOM 合并后生成 Render Tree，如下圖：

Render Tree 和DOM一樣，以多叉樹的形式保存了每個(gè)節(jié)點(diǎn)的css屬性、節(jié)點(diǎn)本身屬性、以及節(jié)點(diǎn)的孩子節(jié)點(diǎn)。

注意：display:none 的節(jié)點(diǎn)不會(huì)被加入 Render Tree，而 visibility: hidden 則會(huì)，所以，如果某個(gè)節(jié)點(diǎn)最開始是不顯示的，設(shè)為 display:none 是更優(yōu)的。（具體可以看這里）

Create/Update DOM And request css/image/js：瀏覽器請(qǐng)求到HTML代碼后，在生成DOM的最開始階段（應(yīng)該是 Bytes → characters 后），并行發(fā)起css、圖片、js的請(qǐng)求，無論他們是否在HEAD里。
注意：發(fā)起 js 文件的下載 request 并不需要 DOM 處理到那個(gè) script 節(jié)點(diǎn)，比如：簡(jiǎn)單的正則匹配就能做到這一點(diǎn)，雖然實(shí)際上并不一定是通過正則：）。這是很多人在理解渲染機(jī)制的時(shí)候存在的誤區(qū)。

Create/Update Render CSSOM：CSS文件下載完成，開始構(gòu)建CSSOM

Create/Update Render Tree：所有CSS文件下載完成，CSSOM構(gòu)建結(jié)束后，和 DOM 一起生成 Render Tree。

Layout：有了Render Tree，瀏覽器已經(jīng)能知道網(wǎng)頁中有哪些節(jié)點(diǎn)、各個(gè)節(jié)點(diǎn)的CSS定義以及他們的從屬關(guān)系。下一步操作稱之為Layout，顧名思義就是計(jì)算出每個(gè)節(jié)點(diǎn)在屏幕中的位置。

Painting：Layout后，瀏覽器已經(jīng)知道了哪些節(jié)點(diǎn)要顯示（which nodes are visible）、每個(gè)節(jié)點(diǎn)的CSS屬性是什么（their computed styles）、每個(gè)節(jié)點(diǎn)在屏幕中的位置是哪里（geometry）。就進(jìn)入了最后一步：Painting，按照算出來的規(guī)則，通過顯卡，把內(nèi)容畫到屏幕上。

以上五個(gè)步驟前3個(gè)步驟之所有使用 “Create/Update” 是因?yàn)镈OM、CSSOM、Render Tree都可能在第一次Painting后又被更新多次，比如JS修改了DOM或者CSS屬性。

Layout 和 Painting 也會(huì)被重復(fù)執(zhí)行，除了DOM、CSSOM更新的原因外，圖片下載完成后也需要調(diào)用Layout 和 Painting來更新網(wǎng)頁。

我扒了一段有贊PC首頁的代碼到本地，通過Node跑起來。Node作為Server端，對(duì)/js/jquery.js 做了延時(shí)2s返回的處理，并且把 放到導(dǎo)航欄的下面，結(jié)果是這樣的：

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

首屏?xí)r間和DomContentLoad事件沒有必然的先后關(guān)系

所有CSS盡早加載是減少首屏?xí)r間的最關(guān)鍵

js的下載和執(zhí)行會(huì)阻塞Dom樹的構(gòu)建（嚴(yán)謹(jǐn)?shù)卣f是中斷了Dom樹的更新），所以script標(biāo)簽放在首屏范圍內(nèi)的HTML代碼段里會(huì)截?cái)嗍灼恋膬?nèi)容。

script標(biāo)簽放在body底部，做與不做async或者defer處理，都不會(huì)影響首屏?xí)r間，但影響DomContentLoad和load的時(shí)間，進(jìn)而影響依賴他們的代碼的執(zhí)行的開始時(shí)間。

回到前面的問題：

script標(biāo)簽的位置會(huì)影響首屏?xí)r間么？

答案是：不影響（如果這里里的首屏指的是頁面從白板變成網(wǎng)頁畫面——也就是第一次Painting），但有可能截?cái)嗍灼恋膬?nèi)容，使其只顯示上面一部分。

為什么說是“有可能”呢？，如果該js下載地比css還快，或者script標(biāo)簽不在第一屏的html里，實(shí)際上是不影響的。明白這一影響邊界非常重要，這樣我們?cè)诳疾祉撁嫘阅芷款i的時(shí)候就有的放矢了。舉個(gè)例子：在網(wǎng)頁的第二屏有一個(gè)通用模塊，實(shí)際上我們是可以把它的js邏輯獨(dú)立成一個(gè)文件，將模塊的html和js標(biāo)簽放在一起做成獨(dú)立的模板引進(jìn)來的（如果它的js比較小或者說因?yàn)槎嗔艘粋€(gè)文件會(huì)多占用一個(gè)TCP連接和帶寬，這實(shí)際上是另外一個(gè)話題了，請(qǐng)參考我文章開頭的聲明）。

所以，總算弄清楚這個(gè)眾所周知的常識(shí)了。我們來總結(jié)一下：

如果script標(biāo)簽的位置不在首屏范圍內(nèi)，不影響首屏?xí)r間

所有的script標(biāo)簽應(yīng)該放在body底部是很有道理的

但從性能最優(yōu)的角度考慮，即使在body底部的script標(biāo)簽也會(huì)拖慢首屏出來的速度，因?yàn)闉g覽器在最一開始就會(huì)請(qǐng)求它對(duì)應(yīng)的js文件，而這，占用了有限的TCP鏈接數(shù)、帶寬甚至運(yùn)行它所需要的CPU。這也是為什么script標(biāo)簽會(huì)有async或defer屬性的原因之一。

可是，在復(fù)雜的實(shí)際應(yīng)用場(chǎng)景中，要貫徹這幾條結(jié)論可能會(huì)遇到問題，比如：

你的頁面是分模塊來寫的，每一個(gè)模塊都有自己的html、js甚至css，當(dāng)把這些模塊湊到一個(gè)頁面中的時(shí)候就會(huì)出現(xiàn)js自然而然地出現(xiàn)在HTML中間部分。你很難把script標(biāo)簽都放到底部

即使你把script標(biāo)簽都放到底部，但script標(biāo)簽的存在終究是拖慢了首屏?xí)r間、DomContendLoad和loaded的時(shí)間。如果只有一個(gè)script標(biāo)簽，我們可以加一個(gè)async，但多個(gè)async的script標(biāo)簽的結(jié)果會(huì)是js文件被亂序執(zhí)行的，這顯然不是我們想要的。

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

本文首發(fā)于我的
SegmentFault專欄：http://segmentfault.com/a/1190000004292479
個(gè)人技術(shù)博客：http://delai.me/code/js-and-performance/
轉(zhuǎn)載請(qǐng)注明出處