聊一聊前端性能優(yōu)化 CRP
什么是 CRP?
CRP又稱關(guān)鍵渲染路徑，引用MDN對它的解釋：
| 關(guān)鍵渲染路徑是指瀏覽器通過把 HTML、CSS 和 JavaScript 轉(zhuǎn)化成屏幕上的像素的步驟順序。優(yōu)化關(guān)鍵渲染路徑可以提高渲染性能。關(guān)鍵渲染路徑包含了 Document Object Model (DOM)，CSS Object Model (CSSOM)，渲染樹和布局。 |
優(yōu)化關(guān)鍵渲染路徑可以提升首屏渲染時間。理解和優(yōu)化關(guān)鍵渲染路徑對于確保回流和重繪可以每秒 60 幀、確保高性能的用戶交互和避免無意義渲染至關(guān)重要。
如何結(jié)合CRP進(jìn)行性能優(yōu)化?
我想對于性能優(yōu)化，大家都不陌生，無論是平時的工作還是面試，是一個老生常談的話題。
如果單純針對一些點(diǎn)去泛泛而談，我想是不太嚴(yán)謹(jǐn)?shù)摹?/p>
今天我們結(jié)合一道非常經(jīng)典的面試題：從輸入URL到頁面展示，這中間發(fā)生了什么?來從其中的某些環(huán)節(jié)，來深入談?wù)勄岸诵阅軆?yōu)化 CRP。
從輸入 URL 到頁面展示，這中間發(fā)生了什么?
這道題的經(jīng)典程度想必不用我多說，這里我用一張圖梳理了它的大致流程：
這個過程可以大致描述為如下：
- URI 解析
- DNS 解析(DNS 服務(wù)器)
- TCP 三次握手(建立客戶端和服務(wù)器端的連接通道)
- 發(fā)送 HTTP 請求
- 服務(wù)器處理和響應(yīng)
- TCP 四次揮手(關(guān)閉客戶端和服務(wù)器端的連接)
- 瀏覽器解析和渲染
- 頁面加載完成
本文我會從瀏覽器渲染過程、緩存、DNS 優(yōu)化幾方面進(jìn)行性能優(yōu)化的說明。
瀏覽器渲染過程
1. 構(gòu)建 DOM 樹
構(gòu)建DOM樹的大致流程梳理為下圖：
我們以下面這段代碼為例進(jìn)行分析：
- <!DOCTYPE html>
- <html>
- <head>
- <meta name="viewport" content="width=device-width,initial-scale=1">
- <link href="style.css" rel="stylesheet">
- <title>構(gòu)建DOM樹</title>
- </head>
- <body>
- <p>森林</p>
- <div>之晨</div>
- </body>
- </html>
首先瀏覽器從磁盤或網(wǎng)絡(luò)中讀取 HTML 原始字節(jié)，并根據(jù)文件的指定編碼將它們轉(zhuǎn)成字符。
然后通過分詞器將字節(jié)流轉(zhuǎn)換為 Token，在Token(也就是令牌)生成的同時，另一個流程會同時消耗這些令牌并轉(zhuǎn)換成 HTML head 這些節(jié)點(diǎn)對象，起始和結(jié)束令牌表明了節(jié)點(diǎn)之間的關(guān)系。
當(dāng)所有的令牌消耗完以后就轉(zhuǎn)換成了DOM(文檔對象模型)。
最終構(gòu)建出的DOM結(jié)構(gòu)如下：
2. 構(gòu)建 CSSOM 樹
DOM樹構(gòu)建完成，接下來就是CSSOM樹的構(gòu)建了。
與HTML的轉(zhuǎn)換類似，瀏覽器會去識別CSS正確的令牌，然后將這些令牌轉(zhuǎn)化成CSS節(jié)點(diǎn)。
子節(jié)點(diǎn)會繼承父節(jié)點(diǎn)的樣式規(guī)則，這里對應(yīng)的就是層疊規(guī)則和層疊樣式表。
構(gòu)建DOM樹的大致流程可梳理為下圖：
我們這里采用上面的HTML為例，假設(shè)它有如下 css：
- body {
- font-size: 16px;
- }
- p {
- font-weight: bold;
- }
- div {
- color: orange;
- }
那么最終構(gòu)建出的CSSOM樹如下：
有了 DOM 和 CSSOM，接下來就可以合成布局樹(Render Tree)了。
3. 構(gòu)建渲染樹
等 DOM 和 CSSOM 都構(gòu)建好之后，渲染引擎就會構(gòu)造布局樹。布局樹的結(jié)構(gòu)基本上就是復(fù)制 DOM 樹的結(jié)構(gòu)，不同之處在于 DOM 樹中那些不需要顯示的元素會被過濾掉，如 display:none 屬性的元素、head 標(biāo)簽、script 標(biāo)簽等。
復(fù)制好基本的布局樹結(jié)構(gòu)之后，渲染引擎會為對應(yīng)的 DOM 元素選擇對應(yīng)的樣式信息，這個過程就是樣式計算。
4. 樣式計算
樣式計算的目的是為了計算出 DOM 節(jié)點(diǎn)中每個元素的具體樣式，這個階段大體可分為三步來完成。
(1) 把 CSS 轉(zhuǎn)換為瀏覽器能夠理解的結(jié)構(gòu)
和 HTML 文件一樣，瀏覽器也是無法直接理解這些純文本的 CSS 樣式，所以當(dāng)渲染引擎接收到 CSS 文本時，會執(zhí)行一個轉(zhuǎn)換操作，將 CSS 文本轉(zhuǎn)換為瀏覽器可以理解的結(jié)構(gòu)——styleSheets。
(2) 轉(zhuǎn)換樣式表中的屬性值，使其標(biāo)準(zhǔn)化
現(xiàn)在我們已經(jīng)把現(xiàn)有的 CSS 文本轉(zhuǎn)化為瀏覽器可以理解的結(jié)構(gòu)了，那么接下來就要對其進(jìn)行屬性值的標(biāo)準(zhǔn)化操作。
什么是屬性值標(biāo)準(zhǔn)化?我們來看這樣的一段CSS：
- body {
- font-size: 2em;
- }
- div {
- font-weight: bold;
- }
- div {
- color: red;
- }
可以看到上面的 CSS 文本中有很多屬性值，如 2em、bold、red，這些類型數(shù)值不容易被渲染引擎理解，所以需要將所有值轉(zhuǎn)換為渲染引擎容易理解的、標(biāo)準(zhǔn)化的計算值，這個過程就是屬性值標(biāo)準(zhǔn)化。
那標(biāo)準(zhǔn)化后的屬性值是什么樣子的?
從圖中可以看到，2em 被解析成了 32px，bold 被解析成了 700，red 被解析成了 rgb(255,0,0)……
(3) 計算出 DOM 樹中每個節(jié)點(diǎn)的具體樣式
現(xiàn)在樣式的屬性已被標(biāo)準(zhǔn)化了，接下來就需要計算 DOM 樹中每個節(jié)點(diǎn)的樣式屬性了，如何計算呢?
這其中涉及到兩點(diǎn)：CSS 的繼承規(guī)則和層疊規(guī)則。
這里由于不是本文的重點(diǎn)，我簡單做下說明：
- CSS 繼承就是每個 DOM 節(jié)點(diǎn)都包含有父節(jié)點(diǎn)的樣式
- 層疊是 CSS 的一個基本特征，它是一個定義了如何合并來自多個源的屬性值的算法。它在 CSS 處于核心地位，CSS 的全稱“層疊樣式表”正是強(qiáng)調(diào)了這一點(diǎn)。
樣式計算完成之后，渲染引擎還需要計算布局樹中每個元素對應(yīng)的幾何位置，這個過程就是計算布局。
5. 計算布局
現(xiàn)在，我們有 DOM 樹和 DOM 樹中元素的樣式，但這還不足以顯示頁面，因為我們還不知道 DOM 元素的幾何位置信息。那么接下來就需要計算出 DOM 樹中可見元素的幾何位置，我們把這個計算過程叫做布局。
6. 繪制
通過樣式計算和計算布局就完成了最終布局樹的構(gòu)建。再之后，就該進(jìn)行后續(xù)的繪制操作了。
到這里，瀏覽器的渲染過程就基本結(jié)束了，通過下面的一張圖來梳理下：
到這里我們已經(jīng)把瀏覽器解析和渲染的完整流程梳理完成了，那么這其中有那些地方可以去做性能優(yōu)化呢?
從瀏覽器的渲染過程中可以做的優(yōu)化點(diǎn)
通常一個頁面有三個階段：加載階段、交互階段和關(guān)閉階段。
- 加載階段，是指從發(fā)出請求到渲染出完整頁面的過程，影響到這個階段的主要因素有網(wǎng)絡(luò)和 JavaScript 腳本。
- 交互階段，主要是從頁面加載完成到用戶交互的整合過程，影響到這個階段的主要因素是 JavaScript 腳本。
- 關(guān)閉階段，主要是用戶發(fā)出關(guān)閉指令后頁面所做的一些清理操作。
這里我們需要重點(diǎn)關(guān)注加載階段和交互階段，因為影響到我們體驗的因素主要都在這兩個階段，下面我們就來逐個詳細(xì)分析下。
1. 加載階段
我們先來分析如何系統(tǒng)優(yōu)化加載階段中的頁面，來看一個典型的渲染流水線，如下圖所示：
通過上面對瀏覽器渲染過程的分析我們知道JavaScript、首次請求的 HTML 資源文件、CSS 文件是會阻塞首次渲染的，因為在構(gòu)建 DOM 的過程中需要 HTML 和 JavaScript 文件，在構(gòu)造渲染樹的過程中需要用到 CSS 文件。
這些能阻塞網(wǎng)頁首次渲染的資源稱為關(guān)鍵資源。而基于關(guān)鍵資源，我們可以繼續(xù)細(xì)化出三個影響頁面首次渲染的核心因素：
- 關(guān)鍵資源個數(shù)。關(guān)鍵資源個數(shù)越多，首次頁面的加載時間就會越長。
- 關(guān)鍵資源大小。通常情況下，所有關(guān)鍵資源的內(nèi)容越小，其整個資源的下載時間也就越短，那么阻塞渲染的時間也就越短。
- 請求關(guān)鍵資源需要多少個RTT(Round Trip Time)。RTT 是網(wǎng)絡(luò)中一個重要的性能指標(biāo)，表示從發(fā)送端發(fā)送數(shù)據(jù)開始，到發(fā)送端收到來自接收端的確認(rèn)，總共經(jīng)歷的時延。
了解了影響加載過程中的幾個核心因素之后，接下來我們就可以系統(tǒng)性地考慮優(yōu)化方案了。總的優(yōu)化原則就是減少關(guān)鍵資源個數(shù)，降低關(guān)鍵資源大小，降低關(guān)鍵資源的 RTT 次數(shù)：
- 如何減少關(guān)鍵資源的個數(shù)?一種方式是可以將 JavaScript 和 CSS 改成內(nèi)聯(lián)的形式，比如上圖的 JavaScript 和 CSS，若都改成內(nèi)聯(lián)模式，那么關(guān)鍵資源的個數(shù)就由 3 個減少到了 1 個。另一種方式，如果 JavaScript 代碼沒有 DOM 或者 CSSOM 的操作，則可以改成 sync 或者 defer 屬性
- 如何減少關(guān)鍵資源的大小?可以壓縮 CSS 和 JavaScript 資源，移除 HTML、CSS、JavaScript 文件中一些注釋內(nèi)容
- 如何減少關(guān)鍵資源 RTT 的次數(shù)?可以通過減少關(guān)鍵資源的個數(shù)和減少關(guān)鍵資源的大小搭配來實現(xiàn)。除此之外，還可以使用 CDN 來減少每次 RTT 時長。
2. 交互階段
接下來我們再來聊聊頁面加載完成之后的交互階段以及應(yīng)該如何去優(yōu)化。
先來看看交互階段的渲染流水線：
其實這塊大致有以下幾點(diǎn)可以優(yōu)化：
(1) 避免DOM的回流。也就是盡量避免重排和重繪操作。
(2) 減少 JavaScript 腳本執(zhí)行時間。有時JavaScript 函數(shù)的一次執(zhí)行時間可能有幾百毫秒，這就嚴(yán)重霸占了主線程執(zhí)行其他渲染任務(wù)的時間。針對這種情況我們可以采用以下兩種策略：
- 一種是將一次執(zhí)行的函數(shù)分解為多個任務(wù)，使得每次的執(zhí)行時間不要過久。
- 另一種是采用 Web Workers。
(3) DOM操作相關(guān)的優(yōu)化。瀏覽器有渲染引擎和JS引擎，所以當(dāng)用JS操作DOM時，這兩個引擎要通過接口互相“交流”，因此每一次操作DOM(包括只是訪問DOM的屬性)，都要進(jìn)行引擎之間解析的開銷，所以常說要減少 DOM 操作。總結(jié)下來有以下幾點(diǎn)：
- 緩存一些計算屬性，如let left = el.offsetLeft。
- 通過DOM的class來集中改變樣式，而不是通過style一條條的去修改。
- 分離讀寫操作。現(xiàn)代的瀏覽器都有渲染隊列的機(jī)制。
- 放棄傳統(tǒng)操作DOM的時代，基于vue/react等采用virtual dom的框架
(4) 合理利用 CSS 合成動畫。合成動畫是直接在合成線程上執(zhí)行的，這和在主線程上執(zhí)行的布局、繪制等操作不同，如果主線程被 JavaScript 或者一些布局任務(wù)占用，CSS 動畫依然能繼續(xù)執(zhí)行。所以要盡量利用好 CSS 合成動畫，如果能讓 CSS 處理動畫，就盡量交給 CSS 來操作。
(5) CSS選擇器優(yōu)化。我們知道CSS引擎查找是從右向左匹配的。所以基于此有以下幾條優(yōu)化方案：
- 盡量不要使用通配符
- 少用標(biāo)簽選擇器
- 盡量利用屬性繼承特性
(6) CSS屬性優(yōu)化。瀏覽器繪制圖像時，CSS的計算也是耗費(fèi)性能的，一些屬性需瀏覽器進(jìn)行大量的計算，屬于昂貴的屬性(box-shadows、border-radius、transforms、filters、opcity、:nth-child等)，這些屬性在日常開發(fā)中經(jīng)常用到，所以并不是說不要用這些屬性，而是在開發(fā)中，如果有其它簡單可行的方案，那可以優(yōu)先選擇沒有昂貴屬性的方案。
(7) 避免頻繁的垃圾回收。我們知道 JavaScript 使用了自動垃圾回收機(jī)制，如果在一些函數(shù)中頻繁創(chuàng)建臨時對象，那么垃圾回收器也會頻繁地去執(zhí)行垃圾回收策略。這樣當(dāng)垃圾回收操作發(fā)生時，就會占用主線程，從而影響到其他任務(wù)的執(zhí)行，嚴(yán)重的話還會讓用戶產(chǎn)生掉幀、不流暢的感覺。
緩存
緩存可以說是性能優(yōu)化中簡單高效的一種優(yōu)化方式了。一個優(yōu)秀的緩存策略可以縮短網(wǎng)頁請求資源的距離，減少延遲，并且由于緩存文件可以重復(fù)利用，還可以減少帶寬，降低網(wǎng)絡(luò)負(fù)荷。下圖是瀏覽器緩存的查找流程圖：
瀏覽器緩存相關(guān)的知識點(diǎn)還是很多的，這里我有整理一張圖：
DNS 相關(guān)優(yōu)化
DNS全稱Domain Name System。它是互聯(lián)網(wǎng)的“通訊錄”，它記錄了域名與實際ip地址的映射關(guān)系。每次我們訪問一個網(wǎng)站，都要通過各級的DNS服務(wù)器查詢到該網(wǎng)站的服務(wù)器ip，然后才能訪問到該服務(wù)器。
DNS相關(guān)的優(yōu)化一般涉及到兩點(diǎn)：瀏覽器DNS緩存和DNS預(yù)解析。
1. DNS緩存
一圖勝千言：
- 瀏覽器會先檢查瀏覽器緩存(瀏覽器緩存有大小和時間限制)，時間過長可能導(dǎo)致IP地址變化，無法解析正確IP地址，過短就會讓瀏覽器重復(fù)解析域名，一般為幾分鐘。
- 如果瀏覽器緩存沒有對應(yīng)域名，則會去操作系統(tǒng)緩存中查找。
- 如果還沒有找到，域名就會發(fā)送到本地區(qū)的域名服務(wù)器(一般由互聯(lián)網(wǎng)供應(yīng)商提供，電信、聯(lián)通之類)，一般在本地區(qū)的域名服務(wù)器上都能找到了。
- 當(dāng)然也可能本地域名服務(wù)器也沒找到，那本地域名服務(wù)器就開始遞歸查找。
一般而言，瀏覽器解析DNS需要20-120ms，因此DNS解析可優(yōu)化之處幾乎沒有。但存在這樣一個場景，網(wǎng)站有很多圖片在不同域名下，那如果在登錄頁就提前解析了之后可能會用到的域名，使解析結(jié)果緩存過，這樣縮短了DNS解析時間，提高網(wǎng)站整體上的訪問速度了，這就是DNS預(yù)解析。
2. DNS預(yù)解析
來看下 MDN 對于DNS預(yù)解析的定義吧：
| X-DNS-Prefetch-Control 頭控制著瀏覽器的 DNS 預(yù)讀取功能。DNS 預(yù)讀取是一項使瀏覽器主動去執(zhí)行域名解析的功能，其范圍包括文檔的所有鏈接，無論是圖片的，CSS 的，還是 JavaScript 等其他用戶能夠點(diǎn)擊的 URL。 |
因為預(yù)讀取會在后臺執(zhí)行，所以 DNS 很可能在鏈接對應(yīng)的東西出現(xiàn)之前就已經(jīng)解析完畢。這能夠減少用戶點(diǎn)擊鏈接時的延遲。
我們這里就簡單看一下如何去做DNS預(yù)解析：
在頁面頭部加入，這樣瀏覽器對整個頁面進(jìn)行預(yù)解析
- <meta http-equiv="x-dns-prefetch-control" content="on">
通過 link 標(biāo)簽手動添加要解析的域名，比如：
- <link rel="dns-prefetch" href="//img10.360buyimg.com"/>
