Introduction
Lorem ipsum dolor sit amet
資訊專欄INFORMATION COLUMN
摘要：瀏覽器初次繪制網(wǎng)頁(yè)的必經(jīng)過程稱之為關(guān)鍵渲染路徑，以下稱。包含在其他元素中間的元素被表示成子節(jié)點(diǎn)。這意味著必須被完整解析，我們才能進(jìn)入頁(yè)面渲染的下一個(gè)階段。它是一個(gè)表示頁(yè)面被最終渲染效果的樹。
原文：https://bitsofco.de/understan...作者：Ire Aderinokun
瀏覽器從接收到服務(wù)器返回的 HTML 到渲染像素到屏幕上，中間經(jīng)歷了很多的步驟。瀏覽器初次繪制網(wǎng)頁(yè)的必經(jīng)過程稱之為“關(guān)鍵渲染路徑（Critical Rendering Path，以下稱CRP）”。
CRP的知識(shí)對(duì)理解怎樣提升網(wǎng)站性能非常有用。CRP有以下6個(gè)階段：
構(gòu)造 DOM 樹
構(gòu)造 CSSOM 樹
運(yùn)行 JavaScript
創(chuàng)建渲染樹（Render Tree）
生成布局
繪制
DOM 樹是一個(gè)表示完整解析過的 HTML 網(wǎng)頁(yè)的對(duì)象。它從根元素 開始，每一個(gè)節(jié)點(diǎn)代表頁(yè)面上的一個(gè)元素或者文本。包含在其他元素中間的元素被表示成子節(jié)點(diǎn)。每一個(gè)節(jié)點(diǎn)記錄著對(duì)應(yīng)元素的所有屬性，舉例來說，一個(gè) 元素對(duì)應(yīng)的節(jié)點(diǎn)包含了元素的 href 屬性。
Understanding the Critical Rendering Path Understanding the Critical Rendering Path
Introduction
Lorem ipsum dolor sit amet
以這個(gè)網(wǎng)頁(yè)為例，它將被解析成下圖的 DOM樹：
A good thing about HTML is that it can be executed in parts. The full document doesn"t have to be loaded for content to start appearing on the page. However, other resources, CSS and JavaScript, can block the render of the page.
HTML 的一點(diǎn)好處是它可以分塊執(zhí)行，無(wú)需加載整個(gè)文檔，內(nèi)容就可以開始出現(xiàn)在頁(yè)面上。但是不好的地方是，諸如CSS 和 JavaScript 文件這樣的資源，卻能夠阻塞頁(yè)面的渲染。
CSSOM （CSS 對(duì)象模型） 是一個(gè)表示DOM相關(guān)聯(lián)樣式的對(duì)象。它與DOM的表現(xiàn)方式類似，但記錄了每個(gè)節(jié)點(diǎn)的關(guān)聯(lián)樣式，包含明確聲明的樣式和默認(rèn)繼承的樣式。
在上面文檔中提到的style.css里， 我們聲明了如下樣式：
body {
font-size: 18px;
}
header {
color: plum;
}
h1 {
font-size: 28px;
}
main {
color: firebrick;
}
h2 {
font-size: 20px;
}
footer {
display: none;
}
上面的樣式會(huì)生成如下的CSSOM 樹：
CSS 被稱為 “渲染阻塞資源（render blocking resource）” 。渲染阻塞資源 沒有經(jīng)過初次完整解析，渲染樹(后面會(huì)解釋) 不會(huì)被構(gòu)建。由于CSS 具有繼承和層疊的特性，它不能像 HTML一樣被分塊解析。在CSS 文檔后面定義的樣式會(huì)覆蓋或更改前面定義的樣式。所以如果我們只解析前面部分的 CSS 樣式，而非整個(gè) CSS 文檔，那么有可能解析出來錯(cuò)誤的結(jié)果。這意味著 CSS 必須被完整解析，我們才能進(jìn)入頁(yè)面渲染的下一個(gè)階段。
CSS 文件只有適用于當(dāng)前設(shè)備的時(shí)候才會(huì)被認(rèn)為是 ”渲染阻塞資源“ 。 標(biāo)簽可以接受一個(gè)媒體屬性，通過改屬性我們可以聲明樣式表適用的設(shè)備。例如：我們有個(gè)樣式表聲明了一個(gè)媒體屬性 orientation:landscape , 只有我們?cè)诳v向模式訪問的時(shí)候，該資源才是阻塞渲染的。
由于 Javascript 文件必須等待 CSSOM 構(gòu)建完成才能夠運(yùn)行。因此也可以說CSS 是 “阻塞腳本”的。
JavaScript 被認(rèn)為是一種 解析阻塞資源，HTML 本身的解析會(huì)被 JavaScript 阻塞。
當(dāng)解析器遇到
布局決定了視窗（viewport）的大小，它提供了 CSS 樣式依賴的上下文，例如視窗的百分比或者單位。
視窗的大小由在文檔頭部提供的 meta 標(biāo)簽 viewport 決定，如果沒有提供，視窗默認(rèn)寬度是980px。
舉例，常用于響應(yīng)設(shè)備寬度的視窗設(shè)置如下:
如果用戶使用寬度為1000px的設(shè)備訪問網(wǎng)頁(yè)，網(wǎng)頁(yè)的大小會(huì)基于這個(gè)單位。一半視窗的大小是500px,10vw會(huì)是100px。
最終的步驟是繪制，頁(yè)面的可見內(nèi)容會(huì)被轉(zhuǎn)化成屏幕上的像素。
繪制過程的耗時(shí)取決于 DOM 的大小和應(yīng)用的樣式。某些樣式比其他樣式需要更多的處理過程。例如：復(fù)雜的漸變背景圖比簡(jiǎn)單的填充背景需要消耗更多的處理時(shí)間。
為了查看 CRP 過程，我們可以打開 chrome 的 devTools,它在Timeline 菜單下面（對(duì)于新版Chrome ,位于Performance菜單下）。
以我們上面的 HTML 為例。
Understanding the Critical Rendering Path Understanding the Critical Rendering Path
Introduction
Lorem ipsum dolor sit amet
打開頁(yè)面加載過程的Event Log選項(xiàng) ,我們可以看到
發(fā)送請(qǐng)求(Send Request) - 發(fā)送獲取 index.html 的 GET 請(qǐng)求
解析HTML(Parse HTML) 、發(fā)送請(qǐng)求(Send Request) - 開始解析 HTML 和 構(gòu)建DOM，并發(fā)起獲取style.css 和 main.js 的 GET 請(qǐng)求
解析樣式表(Parse Stylesheet) - 為 style.css 創(chuàng)建 CSSOM
執(zhí)行腳本(Evaluate script) - 執(zhí)行 main.js
布局(Layout) - 基于HTML 中meta port 標(biāo)簽生成布局
繪制(Paint) - 在文檔上繪制像素
基于這些信息，我們可以做出如何優(yōu)化CRP的決策。
文章版權(quán)歸作者所有，未經(jīng)允許請(qǐng)勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請(qǐng)注明本文地址：http://specialneedsforspecialkids.com/yun/96597.html
摘要：瀏覽器初次繪制網(wǎng)頁(yè)的必經(jīng)過程稱之為關(guān)鍵渲染路徑，以下稱。包含在其他元素中間的元素被表示成子節(jié)點(diǎn)。這意味著必須被完整解析，我們才能進(jìn)入頁(yè)面渲染的下一個(gè)階段。它是一個(gè)表示頁(yè)面被最終渲染效果的樹。 原文：https://bitsofco.de/understan...作者：Ire Aderinokun 瀏覽器從接收到服務(wù)器返回的 HTML 到渲染像素到屏幕上，中間經(jīng)歷了很多的步驟。瀏覽器初...
摘要：下面我們撇開網(wǎng)絡(luò)方面的優(yōu)化，只分析靜態(tài)資源方面的優(yōu)化。不過，也會(huì)阻止的構(gòu)建和延緩網(wǎng)頁(yè)渲染。未優(yōu)化正常加載優(yōu)化后異步加載根據(jù)上面的分析，我們可以清楚的認(rèn)識(shí)到，非必要優(yōu)先加載的，選擇異步加載是最優(yōu)選擇。 為什么做優(yōu)化 經(jīng)典問題：白屏?xí)r間過長(zhǎng)，用戶體驗(yàn)差產(chǎn)生的原因：網(wǎng)絡(luò)問題、關(guān)鍵渲染路徑（CRP）問題 怎么做優(yōu)化 如何做好優(yōu)化呢，網(wǎng)上隨便一搜，就有很多優(yōu)化總結(jié)，無(wú)非就是網(wǎng)絡(luò)優(yōu)化、靜態(tài)資源（h...
摘要：下面我們撇開網(wǎng)絡(luò)方面的優(yōu)化，只分析靜態(tài)資源方面的優(yōu)化。不過，也會(huì)阻止的構(gòu)建和延緩網(wǎng)頁(yè)渲染。未優(yōu)化正常加載優(yōu)化后異步加載根據(jù)上面的分析，我們可以清楚的認(rèn)識(shí)到，非必要優(yōu)先加載的，選擇異步加載是最優(yōu)選擇。 為什么做優(yōu)化 經(jīng)典問題：白屏?xí)r間過長(zhǎng)，用戶體驗(yàn)差產(chǎn)生的原因：網(wǎng)絡(luò)問題、關(guān)鍵渲染路徑（CRP）問題 怎么做優(yōu)化 如何做好優(yōu)化呢，網(wǎng)上隨便一搜，就有很多優(yōu)化總結(jié)，無(wú)非就是網(wǎng)絡(luò)優(yōu)化、靜態(tài)資源（h...
摘要：下面我們撇開網(wǎng)絡(luò)方面的優(yōu)化，只分析靜態(tài)資源方面的優(yōu)化。不過，也會(huì)阻止的構(gòu)建和延緩網(wǎng)頁(yè)渲染。未優(yōu)化正常加載優(yōu)化后異步加載根據(jù)上面的分析，我們可以清楚的認(rèn)識(shí)到，非必要優(yōu)先加載的，選擇異步加載是最優(yōu)選擇。 為什么做優(yōu)化 經(jīng)典問題：白屏?xí)r間過長(zhǎng)，用戶體驗(yàn)差產(chǎn)生的原因：網(wǎng)絡(luò)問題、關(guān)鍵渲染路徑（CRP）問題 怎么做優(yōu)化 如何做好優(yōu)化呢，網(wǎng)上隨便一搜，就有很多優(yōu)化總結(jié)，無(wú)非就是網(wǎng)絡(luò)優(yōu)化、靜態(tài)資源（h...
閱讀 1776·2021-10-27 14:15
閱讀 3835·2021-10-08 10:12
閱讀 1168·2021-09-22 15:55
閱讀 3230·2021-09-22 15:17
閱讀 834·2021-09-02 15:40
閱讀 1748·2019-08-29 18:33
閱讀 1099·2019-08-29 15:22
閱讀 2355·2019-08-29 11:08
