Fundebug經授權轉載，版權歸原作者所有。
前言
瀏覽器的內核是指支持瀏覽器運行的最核心的程序，分為兩個部分的，一是渲染引擎，另一個是JS引擎。渲染引擎在不同的瀏覽器中也不是都相同的。比如在 Firefox 中叫做 Gecko，在 Chrome 和 Safari 中都是基於 WebKit 開發的。本文我們主要介紹關於 WebKit 的這部分渲染引擎內容以及幾個相關的問題。
瀏覽器工作大體流程
瀏覽器工作流程大體分為如下三部分：
1）瀏覽器會解析三個東西：
- 一個是HTML/SVG/XHTML，事實上，Webkit有三個C++的類對應這三類文檔。解析這三種文件會產生一個DOM Tree。
- CSS，解析CSS會產生CSS規則樹。
- Javascript，腳本，主要是通過DOM API和CSSOM API來操作DOM Tree和CSS Rule Tree.
2）解析完成后，瀏覽器引擎會通過DOM Tree 和 CSS Rule Tree 來構造 Rendering Tree。
- Rendering Tree 渲染樹並不等同於DOM樹，因為一些像Header或display:none的東西就沒必要放在渲染樹中了。
- CSS 的 Rule Tree主要是為了完成匹配並把CSS Rule附加上Rendering Tree上的每個Element。也就是DOM結點。也就是所謂的Frame。
- 然后，計算每個Frame（也就是每個Element）的位置，這又叫layout和reflow過程。
3）最后通過調用操作系統Native GUI的API繪制。
接下來我們針對這其中所經歷的重要步驟，一一詳細闡述。
構建DOM
瀏覽器會遵守一套步驟將HTML 文件轉換為 DOM 樹。宏觀上，可以分為幾個步驟：
- 瀏覽器從磁盤或網絡讀取HTML的原始字節，並根據文件的指定編碼（例如 UTF-8）將它們轉換成字符串。
在網絡中傳輸的內容其實都是 0 和 1 這些字節數據。當瀏覽器接收到這些字節數據以后，它會將這些字節數據轉換為字符串，也就是我們寫的代碼。
- 將字符串轉換成Token，例如：
<html>、<body>等。Token中會標識出當前Token是“開始標簽”或是“結束標簽”亦或是“文本”等信息。
這時候你一定會有疑問，節點與節點之間的關系如何維護？
事實上，這就是Token要標識“起始標簽”和“結束標簽”等標識的作用。例如“title”Token的起始標簽和結束標簽之間的節點肯定是屬於“head”的子節點。
上圖給出了節點之間的關系，例如：“Hello”Token位於“title”開始標簽與“title”結束標簽之間，表明“Hello”Token是“title”Token的子節點。同理“title”Token是“head”Token的子節點。
- 生成節點對象並構建DOM
事實上，構建DOM的過程中，不是等所有Token都轉換完成后再去生成節點對象，而是一邊生成Token一邊消耗Token來生成節點對象。換句話說，每個Token被生成后，會立刻消耗這個Token創建出節點對象。注意：帶有結束標簽標識的Token不會創建節點對象。
接下來我們舉個例子，假設有段HTML文本：
<html>
<head>
<title>Web page parsing</title>
</head>
<body>
<div>
<h1>Web page parsing</h1>
<p>This is an example Web page.</p>
</div>
</body>
</html>
上面這段HTML會解析成這樣：
構建CSSOM
DOM會捕獲頁面的內容，但瀏覽器還需要知道頁面如何展示，所以需要構建CSSOM。
構建CSSOM的過程與構建DOM的過程非常相似，當瀏覽器接收到一段CSS，瀏覽器首先要做的是識別出Token，然后構建節點並生成CSSOM。
在這一過程中，瀏覽器會確定下每一個節點的樣式到底是什么，並且這一過程其實是很消耗資源的。因為樣式你可以自行設置給某個節點，也可以通過繼承獲得。在這一過程中，瀏覽器得遞歸 CSSOM 樹，然后確定具體的元素到底是什么樣式。
注意：CSS匹配HTML元素是一個相當復雜和有性能問題的事情。所以，DOM樹要小，CSS盡量用id和class，千萬不要過渡層疊下去。
構建渲染樹
當我們生成 DOM 樹和 CSSOM 樹以后，就需要將這兩棵樹組合為渲染樹。
在這一過程中，不是簡單的將兩者合並就行了。渲染樹只會包括需要顯示的節點和這些節點的樣式信息，如果某個節點是 display: none 的，那么就不會在渲染樹中顯示。
布局與繪制
當瀏覽器生成渲染樹以后，就會根據渲染樹來進行布局（也可以叫做回流）。這一階段瀏覽器要做的事情是要弄清楚各個節點在頁面中的確切位置和大小。通常這一行為也被稱為“自動重排”。
布局流程的輸出是一個“盒模型”，它會精確地捕獲每個元素在視口內的確切位置和尺寸，所有相對測量值都將轉換為屏幕上的絕對像素。
布局完成后，瀏覽器會立即發出“Paint Setup”和“Paint”事件，將渲染樹轉換成屏幕上的像素。
以上我們詳細介紹了瀏覽器工作流程中的重要步驟，接下來我們討論幾個相關的問題：
問題一：渲染過程中遇到JS文件怎么處理？
JavaScript的加載、解析與執行會阻塞DOM的構建，也就是說，在構建DOM時，HTML解析器若遇到了JavaScript，那么它會暫停構建DOM，將控制權移交給JavaScript引擎，等JavaScript引擎運行完畢，瀏覽器再從中斷的地方恢復DOM構建。
也就是說，如果你想首屏渲染的越快，就越不應該在首屏就加載 JS 文件，這也是都建議將 script 標簽放在 body 標簽底部的原因。當然在當下，並不是說 script 標簽必須放在底部，因為你可以給 script 標簽添加 defer 或者 async 屬性（下文會介紹這兩者的區別）。
JS文件不只是阻塞DOM的構建，它會導致CSSOM也阻塞DOM的構建。
原本DOM和CSSOM的構建是互不影響，井水不犯河水，但是一旦引入了JavaScript，CSSOM也開始阻塞DOM的構建，只有CSSOM構建完畢后，DOM再恢復DOM構建。
這是什么情況？
這是因為JavaScript不只是可以改DOM，它還可以更改樣式，也就是它可以更改CSSOM。前面我們介紹，不完整的CSSOM是無法使用的，但JavaScript中想訪問CSSOM並更改它，那么在執行JavaScript時，必須要能拿到完整的CSSOM。所以就導致了一個現象，如果瀏覽器尚未完成CSSOM的下載和構建，而我們卻想在此時運行腳本，那么瀏覽器將延遲腳本執行和DOM構建，直至其完成CSSOM的下載和構建。也就是說，在這種情況下，瀏覽器會先下載和構建CSSOM，然后再執行JavaScript，最后在繼續構建DOM。
問題二：你真的了解回流和重繪嗎
我們知道，當網頁生成的時候，至少會渲染一次。在用戶訪問的過程中，還會不斷重新渲染。重新渲染會重復上圖中的第四步(回流)+第五步(重繪)或者只有第五個步(重繪)。
- 重繪:當render tree中的一些元素需要更新屬性，而這些屬性只是影響元素的外觀、風格，而不會影響布局的，比如background-color。
- 回流:當render tree中的一部分(或全部)因為元素的規模尺寸、布局、隱藏等改變而需要重新構建
回流必定會發生重繪，重繪不一定會引發回流。重繪和回流會在我們設置節點樣式時頻繁出現，同時也會很大程度上影響性能。回流所需的成本比重繪高的多，改變父節點里的子節點很可能會導致父節點的一系列回流。
1）常見引起回流屬性和方法
任何會改變元素幾何信息(元素的位置和尺寸大小)的操作，都會觸發回流，
- 添加或者刪除可見的DOM元素；
- 元素尺寸改變——邊距、填充、邊框、寬度和高度
- 內容變化，比如用戶在input框中輸入文字
- 瀏覽器窗口尺寸改變——resize事件發生時
- 計算 offsetWidth 和 offsetHeight 屬性
- 設置 style 屬性的值
2）常見引起重繪屬性和方法
下面例子中，觸發了幾次回流和重繪？
var s = document.body.style;
s.padding = "2px"; // 回流+重繪
s.border = "1px solid red"; // 再一次 回流+重繪
s.color = "blue"; // 再一次重繪
s.backgroundColor = "#ccc"; // 再一次 重繪
s.fontSize = "14px"; // 再一次 回流+重繪
// 添加node，再一次 回流+重繪
document.body.appendChild(document.createTextNode('abc!'));
3）如何減少回流、重繪
- 使用 transform 替代 top
- 使用 visibility 替換 display: none ，因為前者只會引起重繪，后者會引發回流（改變了布局）
- 不要把節點的屬性值放在一個循環里當成循環里的變量。
for(let i = 0; i < 1000; i++) {
// 獲取 offsetTop 會導致回流，因為需要去獲取正確的值
console.log(document.querySelector('.test').style.offsetTop)
}
- 不要使用 table 布局，可能很小的一個小改動會造成整個 table 的重新布局
- 動畫實現的速度的選擇，動畫速度越快，回流次數越多，也可以選擇使用 requestAnimationFrame
- CSS 選擇符從右往左匹配查找，避免節點層級過多
- 將頻繁重繪或者回流的節點設置為圖層，圖層能夠阻止該節點的渲染行為影響別的節點。比如對於 video 標簽來說，瀏覽器會自動將該節點變為圖層。
問題三：async和defer的作用是什么？有什么區別?
接下來我們對比下 defer 和 async 屬性的區別：
其中藍色線代表JavaScript加載；紅色線代表JavaScript執行；綠色線代表 HTML 解析。
1）情況1<script src="script.js"></script>
沒有 defer 或 async，瀏覽器會立即加載並執行指定的腳本，也就是說不等待后續載入的文檔元素，讀到就加載並執行。
2）情況2<script async src="script.js"></script> (異步下載)
async 屬性表示異步執行引入的 JavaScript，與 defer 的區別在於，如果已經加載好，就會開始執行——無論此刻是 HTML 解析階段還是 DOMContentLoaded 觸發之后。需要注意的是，這種方式加載的 JavaScript 依然會阻塞 load 事件。換句話說，async-script 可能在 DOMContentLoaded 觸發之前或之后執行，但一定在 load 觸發之前執行。
3）情況3 <script defer src="script.js"></script>(延遲執行)
defer 屬性表示延遲執行引入的 JavaScript，即這段 JavaScript 加載時 HTML 並未停止解析，這兩個過程是並行的。整個 document 解析完畢且 defer-script 也加載完成之后（這兩件事情的順序無關），會執行所有由 defer-script 加載的 JavaScript 代碼，然后觸發 DOMContentLoaded 事件。
defer 與相比普通 script，有兩點區別：**載入 JavaScript 文件時不阻塞 HTML 的解析，執行階段被放到 HTML 標簽解析完成之后。
在加載多個JS腳本的時候，async是無順序的加載，而defer是有順序的加載。**
問題四：為什么操作 DOM 慢
因為 DOM 是屬於渲染引擎中的東西，而 JS 又是 JS 引擎中的東西。當我們通過 JS 操作 DOM 的時候，其實這個操作涉及到了兩個線程之間的通信，那么勢必會帶來一些性能上的損耗。操作 DOM 次數一多，也就等同於一直在進行線程之間的通信，並且操作 DOM 可能還會帶來重繪回流的情況，所以也就導致了性能上的問題。
問題五：渲染頁面時常見哪些不良現象？
由於瀏覽器的渲染機制不同，在渲染頁面時會出現兩種常見的不良現象----白屏問題和FOUS（無樣式內容閃爍）
FOUC：由於瀏覽器渲染機制（比如firefox），再CSS加載之前，先呈現了HTML，就會導致展示出無樣式內容，然后樣式突然呈現的現象；
白屏：有些瀏覽器渲染機制（比如chrome）要先構建DOM樹和CSSOM樹，構建完成后再進行渲染，如果CSS部分放在HTML尾部，由於CSS未加載完成，瀏覽器遲遲未渲染，從而導致白屏；也可能是把js文件放在頭部，腳本會阻塞后面內容的呈現，腳本會阻塞其后組件的下載，出現白屏問題。
總結
-
瀏覽器工作流程：構建DOM -> 構建CSSOM -> 構建渲染樹 -> 布局 -> 繪制。
-
CSSOM會阻塞渲染，只有當CSSOM構建完畢后才會進入下一個階段構建渲染樹。
-
通常情況下DOM和CSSOM是並行構建的，但是當瀏覽器遇到一個script標簽時，DOM構建將暫停，直至腳本完成執行。但由於JavaScript可以修改CSSOM，所以需要等CSSOM構建完畢后再執行JS。
-
如果你想首屏渲染的越快，就越不應該在首屏就加載 JS 文件，建議將 script 標簽放在 body 標簽底部。
參考文章
- async 和 defer 的區別 | SegmentFault
- 瀏覽器的渲染原理簡介
- 前端面試之道
- 瀏覽器的渲染：過程與原理
- 你真的了解回流和重繪嗎
- 關鍵渲染路徑
- 頁面重繪和回流以及優化
- 瀏覽器重繪(repaint)重排(reflow)與優化[瀏覽器機制]
關於Fundebug
Fundebug專注於JavaScript、微信小程序、微信小游戲、支付寶小程序、React Native、Node.js和Java線上應用實時BUG監控。 自從2016年雙十一正式上線，Fundebug累計處理了9億+錯誤事件，付費客戶有Google、360、金山軟件、百姓網等眾多品牌企業。歡迎大家免費試用！
