瀏覽器解析渲染HTML文檔的過程

CoyPan 發(fā)布于2019-08-30 15:43 / 2324人閱讀

摘要：瀏覽器的預(yù)解析可以減緩渲染被阻塞的情況，例如文檔解析過程中預(yù)加載器發(fā)現(xiàn)了標(biāo)簽，會對文件進(jìn)行加載并放在瀏覽器緩存中，這樣當(dāng)解析器遇到這個標(biāo)記時(shí)，由于預(yù)加載器已經(jīng)將文件加載下來了，所以會被立即執(zhí)行，不需要等待從網(wǎng)絡(luò)抓取資源，減緩了對渲染的阻塞。

參考資料

瀏覽器的工作原理

瀏覽器加載網(wǎng)頁時(shí)的過程是什么？

HTML渲染過程詳解

瀏覽器的工作原理 一、瀏覽器的高層結(jié)構(gòu)

瀏覽器的主要組件為：

用戶界面 - 包括地址欄、前進(jìn)/后退按鈕、書簽菜單等。除了瀏覽器主窗口顯示的您請求的頁面外，其他顯示的各個部分都屬于用戶界面。

瀏覽器引擎 - 在用戶界面和呈現(xiàn)引擎之間傳送指令。

呈現(xiàn)引擎 - 負(fù)責(zé)顯示請求的內(nèi)容。如果請求的內(nèi)容是 HTML，它就負(fù)責(zé)解析 HTML 和 CSS 內(nèi)容，并將解析后的內(nèi)容顯示在屏幕上。

網(wǎng)絡(luò) - 用于網(wǎng)絡(luò)調(diào)用，比如 HTTP 請求。其接口與平臺無關(guān)，并為所有平臺提供底層實(shí)現(xiàn)。

用戶界面后端 - 用于繪制基本的窗口小部件，比如組合框和窗口。其公開了與平臺無關(guān)的通用接口，而在底層使用操作系統(tǒng)的用戶界面方法。

JavaScript 解釋器。用于解析和執(zhí)行 JavaScript 代碼。

數(shù)據(jù)存儲。這是持久層。瀏覽器需要在硬盤上保存各種數(shù)據(jù)，例如 Cookie。新的 HTML 規(guī)范 (HTML5) 定義了“網(wǎng)絡(luò)數(shù)據(jù)庫”，這是一個完整（但是輕便）的瀏覽器內(nèi)數(shù)據(jù)庫。

值得注意的是，和大多數(shù)瀏覽器不同，Chrome 瀏覽器的每個標(biāo)簽頁都分別對應(yīng)一個呈現(xiàn)引擎實(shí)例。每個標(biāo)簽頁都是一個獨(dú)立的進(jìn)程。

二、主流程

呈現(xiàn)引擎一開始會從網(wǎng)絡(luò)層獲取請求文檔的內(nèi)容，內(nèi)容的大小一般限制在 8000 個塊以內(nèi)。

然后進(jìn)行如下所示的基本流程：

呈現(xiàn)引擎將開始解析 HTML 文檔，并將各標(biāo)記逐個轉(zhuǎn)化成“內(nèi)容樹”上的 DOM 節(jié)點(diǎn)。同時(shí)也會解析外部 CSS 文件以及樣式元素中的樣式數(shù)據(jù)。HTML 中這些帶有視覺指令的樣式信息將用于創(chuàng)建另一個樹結(jié)構(gòu)：呈現(xiàn)樹。

呈現(xiàn)樹包含多個帶有視覺屬性（如顏色和尺寸）的矩形。這些矩形的排列順序就是它們將在屏幕上顯示的順序。

呈現(xiàn)樹構(gòu)建完畢之后，進(jìn)入“布局”處理階段，也就是為每個節(jié)點(diǎn)分配一個應(yīng)出現(xiàn)在屏幕上的確切坐標(biāo)。下一個階段是繪制 - 呈現(xiàn)引擎會遍歷呈現(xiàn)樹，由用戶界面后端層將每個節(jié)點(diǎn)繪制出來。

需要著重指出的是，這是一個漸進(jìn)的過程。為達(dá)到更好的用戶體驗(yàn)，呈現(xiàn)引擎會力求盡快將內(nèi)容顯示在屏幕上。它不必等到整個 HTML 文檔解析完畢之后，就會開始構(gòu)建呈現(xiàn)樹和設(shè)置布局。在不斷接收和處理來自網(wǎng)絡(luò)的其余內(nèi)容的同時(shí)，呈現(xiàn)引擎會將部分內(nèi)容解析并顯示出來。

主流程示例：

三、處理腳本和樣式表的順序

腳本
網(wǎng)絡(luò)的模型是同步的。網(wǎng)頁作者希望解析器遇到標(biāo)簽，會對 last.js 文件進(jìn)行加載并放在瀏覽器緩存中，這樣當(dāng)解析器遇到這個

由上面兩張截圖可以看到，jquery.min.js 腳本文件與 bootstrap.css 等樣式文件并行加載，但是由于 chrome 的并發(fā)連接數(shù)上限為 6 個，因此 bootstrap.min.js 腳本、xxx.css 樣式等文件的加載會等待前面的文件加載完成，有可用連接數(shù)的時(shí)候才開始加載。

了解以上信息之后，我們可以對該頁面進(jìn)行相應(yīng)優(yōu)化，例如對CSS文件進(jìn)行壓縮處理、使用 CDN，將資源分布在多個域名下、合并 CSS 文件，減少 HTTP 請求數(shù)量等，來提高 CSS 的加載速度，減少 HTML 文檔解析和渲染的阻塞時(shí)間。

browser only allows six TCP connections per origin on HTTP 1.

瀏覽器的并發(fā)請求數(shù)目限制是針對同一域名的。因此可以使用 CDN 加速技術(shù)來提高用戶訪問網(wǎng)站的響應(yīng)速度，這樣使用了 CDN 的資源加載不會占用當(dāng)前域名下的并發(fā)連接數(shù)，從而減少阻塞的時(shí)間。

網(wǎng)頁性能

了解 HTML 文檔的解析和渲染的過程對于分析網(wǎng)頁性能有著重要意義，它可以幫助我們找到影響網(wǎng)頁性能的關(guān)鍵因素。例如，我們知道 JS 外部腳本的執(zhí)行會阻塞文檔的解析，那么重量級的第三方插件則會影響首頁加載的速度，如果因此影響到了用戶體驗(yàn)，我們就需要考慮這個第三方插件的使用成本是不是太高了，能否使用其他輕量級的插件進(jìn)行替代，或者只使用其中一部分模塊。

以 Datatables 為例：

上圖是一個項(xiàng)目頁面的 Network 截圖，紅色框中的部分出現(xiàn)了約 700ms 左右的空白，我們需要知道為什么頁面的加載會出現(xiàn)這樣的情況，這段空白時(shí)間瀏覽器在干什么？

我們分析 Timeline 圖，看看瀏覽器在這段時(shí)間的具體信息，如下：

通過 Timeline 圖我們可以看到，在 250ms~900ms 時(shí)間區(qū)間內(nèi)，瀏覽器在執(zhí)行 datatables.min.js 腳本代碼，這個腳本的執(zhí)行阻塞了文檔的解析，耗時(shí)約 700ms，對應(yīng)了 Network 圖中的空白。

我們繼續(xù)查看頁面總的耗時(shí)時(shí)間，評估 700ms 耗時(shí)的影響，如下：

可以看到，頁面總的完成耗時(shí)為 1.66s，由此可知 datatables.min.js 的執(zhí)行耗時(shí)占了很大比重，應(yīng)當(dāng)慎重考慮是否一定要使用這個插件，能否使用其他輕量級的插件進(jìn)行替代，或者能否精簡插件的不必要模塊，或者舍棄插件的使用。

參考資料-1
瀏覽器接收到html代碼，可能是一份完整的文檔，也可能是一個chunk，即開始解析。解析過程是先構(gòu)建dom樹，再根據(jù)dom樹構(gòu)建渲染樹，最后瀏覽器將渲染樹繪制到頁面上。
構(gòu)建dom樹的過程即根據(jù)html代碼自上而下進(jìn)行構(gòu)建，當(dāng)遇到script文件加載／執(zhí)行會阻塞后面dom樹的構(gòu)建（javascript可能會改變dom樹），而遇到css文件則會阻塞渲染樹的構(gòu)建，即dom樹依然繼續(xù)構(gòu)建（除非遇到script標(biāo)簽并且css文件依舊未加載完成），但不會渲染繪制到頁面上。而無論哪個阻塞，該加載的文件還是會加載，例如html文檔中的其他css／js／圖片文件。
另外javascript被加載后就會被執(zhí)行，執(zhí)行的過程也阻塞樹的構(gòu)建。是執(zhí)行完了才解析其他內(nèi)容，而不是執(zhí)行完了才加載其他內(nèi)容。

作者：加冰
鏈接：https://www.zhihu.com/questio...

參考資料-2
首先，開源瀏覽器一般以8k每塊下載html頁面。
然后解析頁面生成DOM樹，遇到css標(biāo)簽或JS腳本標(biāo)簽就新起線程去下載他們，并繼續(xù)構(gòu)建DOM。
下載完后解析CSS為CSS規(guī)則樹，瀏覽器結(jié)合CSS規(guī)則樹和DOM樹生成Render Tree。
注意：構(gòu)建CSS Object Model（CSSOM)會阻塞JavaScript的執(zhí)行。JavaScript的執(zhí)行也會阻塞DOM的構(gòu)建。
JavaScript下載后可以通過DOM API修改DOM，通過CSSOM API修改樣式作用域Render Tree。
每次修改會造成Render Tree的重新布局和重繪。只要修改DOM或修改了元素的形狀或大小，就會觸發(fā)Reflow，單純修改元素的顏色只需Repaint一下（調(diào)用操作系統(tǒng)Native GUI的API繪制）。

作者：陳金
鏈接：https://www.zhihu.com/questio...