一篇，我們介紹了DOM，CSSOM和渲染樹是怎么回事，如果有不知道的，最好先回顧一下這篇文章Web渲染性能，DOM，CSSOM和渲染，看完這個你就全懂了(一)， 接下來將繼續我們的渲染歷程。

渲染順序

理解這個過程對開發設計人員來說很關鍵，它會幫助我們設計站點的時候充分考慮到用戶體驗和性能問題。頁面加載后，瀏覽器會構造DOM，CSSOM和渲染樹，當這些都創建好之后，就會開始在屏幕上繪制每一個元素。

布局操作

首先瀏覽器給每個渲染樹節點創建布局(layout)信息, 它包含了節點的將來顯示的位置數據(像素點位置)。這個過程叫布局(Layout)，也可以叫回流(reflow), 因為它也可能發生在窗口的大小改變，滾動等事件或DOM元素操作中。

注：我們應該盡量避免頁面產生多次布局操作，因為這是代價昂貴的操作。

顯示操作

到現在為止，我們已經有了一棵渲染樹，也就是節點位置列表，包含了需要顯示的所有信息。

因為渲染樹上的節點可以重疊顯示，它們的CSS屬性，決定了它們的外觀，位置，如何變化(動畫)。我了更好的控制渲染，瀏覽器引入了層的概念。建立層，瀏覽器可以高效地在頁面生命周期內執行顯示操作。層也可以幫助元素以堆棧的形式顯示(Z軸方向)。

在每一層，瀏覽器將會顯示元素的每一個像素，比如邊框，背景，顏色，陰影，文字等。這個過程也叫柵格化。為了改進性能，瀏覽器必須使用不同的線程去做這種柵格化操作。

這個層跟Photoshop中的層類似，你可以通過Chrome開發者工具看到頁面中的不同層。打開開發者工具->更多工具->選擇層，你將會看到更多細節。

注：柵格化通常是CPU完成的，但現在我們有新技術可以使用GPU來做這個操作，從而提高性能

合成操作

直到現在，我們還沒有在顯示器上畫出任何一個像素。我們有的只是一些不同的層(位圖Bitmap Image)，這些層將會以特定的順序被顯示出來。在合成操作中，它們將被發送給GPU，最終顯示在顯示屏上。

一次性發送所有層顯然是低效的。因為如果有回流或者重繪操作，這個每次都會發生。所以一個層會被打碎成很多個可顯示的小塊(Tiles)。你可以在開發者工具的渲染面板中看到這些小塊。

綜合上面的信息，我們可以看到瀏覽器的事件順序，我們把這個執行順序叫做關鍵渲染路徑，如下圖。

瀏覽器引擎

創建DOM樹，CSSOM樹和處理渲染邏輯的工作，是被一個叫做瀏覽器引擎的軟件完成的。它內置于瀏覽器中。這個引擎包含了渲染所需要的所有東西，能夠把從HTML字符串文檔最終轉化成屏幕上的像素點。

如果你聽人們討論WebKit, 他們就是在說瀏覽器引擎。WebKit是APPLE Safari瀏覽器的默認引擎。Google Chrome使用的是Blink, 微軟最新的Edge瀏覽器也使用了跟Chrome一樣的引擎。還有一些其他公司的，比如Firefox...

瀏覽器中的渲染過程

我們都知道，JavaScript語言是遵循ECMAScript標準的， 因此每個JavaScript引擎比如V8，Chakra，Spider Monkey等，都被必須遵守這個標準。

有了這個標準，運行JavaScript就能給我們一致的體驗，無論是在瀏覽器中，還是Node.js中，Deno等環境中運行相同的JS代碼，都能給我們相同的結果。。這很棒，并且會提高我們的產品質量。

然而，這種情況在瀏覽器渲染中就不存在了，盡管HTML，CSS，JavaScript，這些語言的標準被一些機構控制，但瀏覽器把它們組合到一起，如何渲染出來，這個過程沒有標準化。各個公司就各個公司的辦法。比如Chrome就跟Safari的做法不一樣。

因此很難預測在一個特殊瀏覽器中的渲染順序和機制。盡管如此，HTML規范也做了些努力來標準化渲染操作。但是瀏覽器怎么遵守，遵守多少完全取決于他們自己。

除了這些不一致性，有些共通的東西是在所有瀏覽器中是一樣的。 讓我們來理解一下通常瀏覽器渲染事件的過程是怎么樣的。

解析和外部資源

解析是讀取HTML構造DOM樹的過程。所以這個過程也叫DOM解析，做這個工作的程序叫DOM Parser。

大多數瀏覽器提供了DOMParser API來構造一個DOM樹。你可以試著構造一個DOMParser的實例，然后使用parseFromString方法，看看可以構造出一個什么DOM樹。

當瀏覽器請求一個頁面，服務器返回了HTML文本(Content-Type設成text/html), 瀏覽器可以在只接收到整個文檔中的開始幾行或幾個字符就開始解析操作。所以瀏覽器可以增量地構造DOM樹，一次一個節點地從頭到尾解析。

在上面這個例子中，我們訪問incremental.html文件，設置網速只有10kbps，這樣它會花很長時間來下載這個包含了1000個H1元素文件。從下圖可以看到，瀏覽器從最初的收到的一些字節就開始構造DOM樹，并把他們顯示出來。剩下的東西還在后臺下載中，就這樣邊下載邊解析。

上面是該請求的性能圖表， 你會看到這些事件發生的時間。當他們發生的越早，用時越短，說明用戶體驗越好。

FP表示首次渲染，表示瀏覽器開始在顯示器上顯示東西了。可能就是簡單到顯示Body中背景的第一個像素。

FCP表示首次內容渲染，說明瀏覽器已經渲染了圖片或文字的第一個像素

LCP表示最大內容渲染，說明瀏覽器渲染了最大的一塊文字或圖片

L表示onload事件，是由瀏覽器的window對象發出的。類似的DCL由document對象發出，它冒泡至window，這樣你就可以在window對象上監聽它。這些事件有些復雜，我們接下來討論它。

只要瀏覽器解析時碰到外部文件，它就會開始后臺下載那個文件(非主線程)。比如JavaScript <script src="url"></script>, CSS <link rel="stylesheet" href="url" />, image <img src="url" />或者其他任何外部資源都會這樣。

最重要的就是要記住，解析通常發生在主線程。如果主線程解析JavaScript很忙，DOM解析操作就會停止工作，直到主線程再次空閑。之所以重要，因為只有script標簽(JavaScript文件)會阻塞解析，而其他請求如image，stylesheet, pdf, video等外部文件不會阻塞解析。

解析阻塞腳本

當瀏覽器碰到script元素，如果是一段內嵌腳本，瀏覽器停止HTML解析，立即執行該腳本，然后繼續解析HTML。所有內嵌JavaScript都會阻塞HTML解析。

如果script是外部腳本文件，瀏覽器會停止主線程工作(停止DOM解析)，去下載js文件并等待其完成下載。當js下載后，瀏覽器會先執行下載的文件，然后繼續主線程的DOM解析工作。如果瀏覽器發現另外一個script標簽，它也會做同樣的操作。為什么瀏覽器要停止當前的DOM解析工作呢?

我們知道，瀏覽器從JavaScript運行時暴露了DOM API，意味著我們可以用JavaScript訪問或操作DOM元素。這就是那些動態的web框架可以工作的原理。比如React, Vue, Angular...但如果瀏覽器同時運行DOM解析和執行JS，那就會產生競爭關系，因為倆線程都可能改變DOM，最終導致DOM樹不準確，所以DOM解析和JS執行都必須在主線程上。

盡管如此，當下載JS文件的時候，停止DOM解析在大多數情況下是完全沒有必要的。所以HTML5增加了async屬性給script標簽。當瀏覽器碰到帶async的script標簽，它下載JS文件的時候不會停止DOM解析，一旦下載結束，就會阻塞DOM解析并且立即執行JavaScript代碼。

我們還有一個更好用的defer屬性，它跟async類似，下載的時候不會阻塞DOM解析。不一樣的是，當defer文件下載完畢后，不會立即執行，會等到DOM樹完全構造完成后才會執行。

在上面的例子中, parser-blocking.html文件，在30元素后，有一個阻塞解析的script, 這就是為什么瀏覽器開始顯示了30個元素，然后停止了DOM解析，開始下載JavaScript文件。第二個script文件有defer屬性，所以它會在DOM樹完全建立后才執行。

如果看性能面板，瀏覽器一開始構造DOM樹，有了一些HTML內容時，FP和FCP就發生了。我們就看到一下東西呈現出來了。

LCP發生于5秒后，因為需要處理JavaScript，所以DOM解析就會被阻塞5秒(JS文件的下載時間)，并且只有30個文本元素被顯示。但是這些東西還不足以成為最大的渲染內容(根據Google標準)。一旦JS文件下載并執行完成， DOM解析恢復，這時最大內容會被顯示出來，所以LCP就觸發了。

渲染阻塞-CSS

我們已經知道，任何其他外部資源，除了JavaScript文件，都不會阻塞DOM解析。所以CSS也不會直接阻塞DOM解析。。。等等。。。不會直接阻塞！！！什么意思？其實CSS會阻塞DOM解析，但我們需要先了解渲染過程。

瀏覽器引擎會將HTML文本變成DOM樹，并且它也從stylesheet可以構造CSSOM樹。但是DOM樹和CSSOM樹的構造都是在主線程上進行的，然后它倆合并成渲染樹。我們已經知道DOM樹是生成是增量的，一邊讀HTML一邊生成節點添加到樹上。但這不是CSSOM的構造過程，CSSOM樹構造不是增量型的，是必須在某一特定時候發生的。

當瀏覽器發現<style>塊，它會解析所有的內嵌CSS并且更新CSSOM樹，然后繼續進行正常的DOM解析，inline樣式也一樣的處理。

然而，如果碰到外部CSS文件，事情就大不一樣了。不像外部JavaScript文件，外部CSS文件不是解析阻塞資源，所以瀏覽器可以在后臺繼續下載，DOM解析仍然會繼續。

另外，不像HTML，CSSOM構造不是增量型的，它不能邊讀邊被構造。原因是一個文件末尾的CSS規則，可能會修改文件最頂部的規則。所以，如果進行增量構造，那就會導致渲染樹的多次渲染，因此CSSOM節點隨時可能會發生變化。那將會極大的降低用戶體驗，用戶就可能看到頁面效果不停的變化。所以當所有CSS規則被處理后，CSSOM樹會被更新，然后渲染樹也會被更新，最后才在顯示器上呈現。

CSS確實是渲染阻塞資源。一旦瀏覽器發送一個請求去外部stylesheet，渲染樹的構造就停止了。因此關鍵渲染路徑(Critical Redering Path)也會被卡住，什么都顯示不了。盡管如此，DOM樹的解析仍然繼續。

想一下瀏覽器可能已經使用老的CSSOM樹就生成了渲染樹，并且顯示了一些東西在顯示器上，然后又碰到了外部CSS文件，怎么辦？這種情況很糟糕，一旦外部CSS文件下載完成，CSSOM樹要被更新，渲染樹也要被更新，所有那些已經被顯示的元素要被新渲染樹的內容所替代重新顯示，這就會導致閃爍，是很糟糕的用戶體驗。

所以瀏覽器會等等stylesheet下載解析完成，這樣CSSOM準備好，渲染樹就可以準備好，渲染關鍵路徑就不會被阻塞了。基于上述原因，通常建議所有外部CSS文件要盡早的被加載，最好是放在<head>里。

另一種情況，外部JS文件已經被完全下載了，而外部CSS文件仍然在后臺下載，這是瀏覽器會執行JS文件么？有什么危害么？

我們知道，CSSOM提供了JavaScript API來跟DOM元素的樣式進行交互。比如，你可以讀取更新元素的背景顏色el.style.backgourndColor 屬性。這個與el關聯的style屬性暴露了CSSOM API。
當stylesheet在后臺下載的時候，JavaScript仍然會被執行，因為我們的主線程沒有被阻塞。如果我們的JavaScript程序訪問DOM元素的CSS屬性，它會拿到當前CSSOM上的值。但是一旦stylesheet下載完成并被解析后，這就會導致CSSOM被更新，我們剛才JavaScript拿到的值就過時了，因此，在下載CSS的時候去執行JS是不安全的，應該盡量避免。

根據HTML5規范，瀏覽器可以下載一個JavaScript文件，但不會立即執行，直到所有stylesheets先被處理了。當一個stylesheet阻塞了JavaScript執行，這叫做腳本阻塞CSS。

上面這個例子，script-blocking.html包含了一個link標簽(這個是CSS)，然后跟著一個script標簽(這個是JavaScript文件)，這里JavaScript文件下載特別快，沒有任何延遲，但CSS文件花費了6秒去下載。所以盡管JavaScript文件加載完成，它仍然不會被瀏覽器立即執行。只有當CSS文件被處理完，我們才能看到JavaScript輸出的Hello World。

文檔的DOMContentLoaded事件

這個事件DOMContentLoaded(簡稱DCL)在瀏覽器已經完成了所有DOM樹的構建而發出的。這里有很多因素會影響這個事件的發生。

如果我們的HTML沒有任何腳本，DOM解析不會被阻塞，DCL就會在解析完整個HTML立即發生。如果我們有阻塞的腳本，DCL就會等所有阻塞腳本被下載執行后再發生。

另外，如果我們把CSS考慮進來，事情就變得復雜了。盡管沒有外部腳本，DCL仍然要等所有stylesheets被加載。因為DCL就記錄一個時間點，說明整個DOM樹準備好了，但如果CSSOM沒有準備好，DOM樹并不能被安全的訪問。所以大多數瀏覽器會等CSSOM也準備好才發出這個事件。

DCL是最重要的網站性能指標之一，我們要優化它，越小越好。最佳實踐之一就是使用defer，async標簽給script元素。讓這些腳本可以在后臺下載。第二，我們要優化渲染阻塞的stylesheets.

Window的load事件

我們已經知道JavaScript可以阻塞DOM樹的生成，帶其他外部文件不行，比如CSS，圖片，視頻等等。

DOMContentLoaded事件記錄了DOM樹完成構造并且可以安全訪問的時間點。window.onload記錄了當外部的css和其他文件被下載完成的時間點。

在上面的例子中， rendering.html 文件有一個外部CSS文件在head中，它要花5秒被下載。因為它在head中，所以FP和FCP是在5秒后發生的。這個css文件會阻塞渲染，看不到任何東西。

在那之后，我們有個圖片元素，大概需要10秒去下載，所以瀏覽器仍然繼續在后臺下載這個文件，并且繼續進行DOM解析和渲染。

接下來，我們有3個JavaScript文件，他們將花3秒，6秒，9秒去下載。更重要的是，他們不是async的，這就意味著總共需要18秒順序執行下載。而且直到前一個被下載并執行完成后，后面一個才會繼續下載執行。盡管如此，我們的現代瀏覽器似乎采用了新的策略，更高效地下載了它們，所以總共用時9秒左右。因為最后一個文件下載會影響DCL， 所以DCL發生在9.1秒。

這時仍然有其他外部資源在下載，就是那張圖片，它仍然在后臺下載，大概花了10秒下載完成了，所以window.load事件在10.2秒被觸發，意味著整個頁面加載完成。

以上就是瀏覽器的整個渲染過程，希望可以幫助大家理解它的原理，也希望大家可以批評指正錯誤，一起討論學習。