盗墓笔记小说全集,唐家三少,有声小说

新聞中心

這里有您想知道的互聯(lián)網(wǎng)營銷解決方案

聊一聊前端性能優(yōu)化CRP

什么是 CRP?

創(chuàng)新互聯(lián)長期為成百上千客戶提供的網(wǎng)站建設(shè)服務(wù)，團(tuán)隊(duì)從業(yè)經(jīng)驗(yàn)10年，關(guān)注不同地域、不同群體，并針對不同對象提供差異化的產(chǎn)品和服務(wù)；打造開放共贏平臺(tái)，與合作伙伴共同營造健康的互聯(lián)網(wǎng)生態(tài)環(huán)境。為宣威企業(yè)提供專業(yè)的做網(wǎng)站、成都網(wǎng)站制作，宣威網(wǎng)站改版等技術(shù)服務(wù)。擁有十余年豐富建站經(jīng)驗(yàn)和眾多成功案例,為您定制開發(fā)。

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)鍵渲染路徑可以提升首屏渲染時(shí)間。理解和優(yōu)化關(guān)鍵渲染路徑對于確?；亓骱椭乩L可以每秒 60 幀、確保高性能的用戶交互和避免無意義渲染至關(guān)重要。

如何結(jié)合CRP進(jìn)行性能優(yōu)化?

我想對于性能優(yōu)化，大家都不陌生，無論是平時(shí)的工作還是面試，是一個(gè)老生常談的話題。

如果單純針對一些點(diǎn)去泛泛而談，我想是不太嚴(yán)謹(jǐn)?shù)摹?/p>

今天我們結(jié)合一道非常經(jīng)典的面試題：從輸入U(xiǎn)RL到頁面展示，這中間發(fā)生了什么?來從其中的某些環(huán)節(jié)，來深入談?wù)勄岸诵阅軆?yōu)化 CRP。

從輸入 URL 到頁面展示，這中間發(fā)生了什么?

這道題的經(jīng)典程度想必不用我多說，這里我用一張圖梳理了它的大致流程：

這個(gè)過程可以大致描述為如下：

URI 解析
DNS 解析(DNS 服務(wù)器)
TCP 三次握手(建立客戶端和服務(wù)器端的連接通道)
發(fā)送 HTTP 請求
服務(wù)器處理和響應(yīng)
TCP 四次揮手(關(guān)閉客戶端和服務(wù)器端的連接)
瀏覽器解析和渲染
頁面加載完成

本文我會(huì)從瀏覽器渲染過程、緩存、DNS 優(yōu)化幾方面進(jìn)行性能優(yōu)化的說明。

瀏覽器渲染過程

1. 構(gòu)建 DOM 樹

構(gòu)建DOM樹的大致流程梳理為下圖：

我們以下面這段代碼為例進(jìn)行分析：

 
 
 
 
  
  
  
   
  
  
  
   
  
  
  
     
  
  
  
       
  
  
  
       
  
  
  
      構(gòu)建DOM樹 
  
  
  
     
  
  
  
     
  
  
  
      森林
 
  
  
  
      之晨

首先瀏覽器從磁盤或網(wǎng)絡(luò)中讀取 HTML 原始字節(jié)，并根據(jù)文件的指定編碼將它們轉(zhuǎn)成字符。

然后通過分詞器將字節(jié)流轉(zhuǎn)換為 Token，在Token(也就是令牌)生成的同時(shí)，另一個(gè)流程會(huì)同時(shí)消耗這些令牌并轉(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)換類似，瀏覽器會(huì)去識(shí)別CSS正確的令牌，然后將這些令牌轉(zhuǎn)化成CSS節(jié)點(diǎn)。

子節(jié)點(diǎn)會(huì)繼承父節(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)建好之后，渲染引擎就會(huì)構(gòu)造布局樹。布局樹的結(jié)構(gòu)基本上就是復(fù)制 DOM 樹的結(jié)構(gòu)，不同之處在于 DOM 樹中那些不需要顯示的元素會(huì)被過濾掉，如 display:none 屬性的元素、head 標(biāo)簽、script 標(biāo)簽等。

復(fù)制好基本的布局樹結(jié)構(gòu)之后，渲染引擎會(huì)為對應(yīng)的 DOM 元素選擇對應(yīng)的樣式信息，這個(gè)過程就是樣式計(jì)算。

4. 樣式計(jì)算

樣式計(jì)算的目的是為了計(jì)算出 DOM 節(jié)點(diǎn)中每個(gè)元素的具體樣式，這個(gè)階段大體可分為三步來完成。

(1) 把 CSS 轉(zhuǎn)換為瀏覽器能夠理解的結(jié)構(gòu)

和 HTML 文件一樣，瀏覽器也是無法直接理解這些純文本的 CSS 樣式，所以當(dāng)渲染引擎接收到 CSS 文本時(shí)，會(huì)執(zhí)行一個(gè)轉(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)化的計(jì)算值，這個(gè)過程就是屬性值標(biāo)準(zhǔn)化。

那標(biāo)準(zhǔn)化后的屬性值是什么樣子的?

從圖中可以看到，2em 被解析成了 32px，bold 被解析成了 700，red 被解析成了 rgb(255,0,0)……

(3) 計(jì)算出 DOM 樹中每個(gè)節(jié)點(diǎn)的具體樣式

現(xiàn)在樣式的屬性已被標(biāo)準(zhǔn)化了，接下來就需要計(jì)算 DOM 樹中每個(gè)節(jié)點(diǎn)的樣式屬性了，如何計(jì)算呢?

這其中涉及到兩點(diǎn)：CSS 的繼承規(guī)則和層疊規(guī)則。

這里由于不是本文的重點(diǎn)，我簡單做下說明：

CSS 繼承就是每個(gè) DOM 節(jié)點(diǎn)都包含有父節(jié)點(diǎn)的樣式
層疊是 CSS 的一個(gè)基本特征，它是一個(gè)定義了如何合并來自多個(gè)源的屬性值的算法。它在 CSS 處于核心地位，CSS 的全稱“層疊樣式表”正是強(qiáng)調(diào)了這一點(diǎn)。

樣式計(jì)算完成之后，渲染引擎還需要計(jì)算布局樹中每個(gè)元素對應(yīng)的幾何位置，這個(gè)過程就是計(jì)算布局。

5. 計(jì)算布局

現(xiàn)在，我們有 DOM 樹和 DOM 樹中元素的樣式，但這還不足以顯示頁面，因?yàn)槲覀冞€不知道 DOM 元素的幾何位置信息。那么接下來就需要計(jì)算出 DOM 樹中可見元素的幾何位置，我們把這個(gè)計(jì)算過程叫做布局。

6. 繪制

通過樣式計(jì)算和計(jì)算布局就完成了最終布局樹的構(gòu)建。再之后，就該進(jìn)行后續(xù)的繪制操作了。

到這里，瀏覽器的渲染過程就基本結(jié)束了，通過下面的一張圖來梳理下：

到這里我們已經(jīng)把瀏覽器解析和渲染的完整流程梳理完成了，那么這其中有那些地方可以去做性能優(yōu)化呢?

從瀏覽器的渲染過程中可以做的優(yōu)化點(diǎn)

通常一個(gè)頁面有三個(gè)階段：加載階段、交互階段和關(guān)閉階段。

加載階段，是指從發(fā)出請求到渲染出完整頁面的過程，影響到這個(gè)階段的主要因素有網(wǎng)絡(luò)和 JavaScript 腳本。
交互階段，主要是從頁面加載完成到用戶交互的整合過程，影響到這個(gè)階段的主要因素是 JavaScript 腳本。
關(guān)閉階段，主要是用戶發(fā)出關(guān)閉指令后頁面所做的一些清理操作。

這里我們需要重點(diǎn)關(guān)注加載階段和交互階段，因?yàn)橛绊懙轿覀凅w驗(yàn)的因素主要都在這兩個(gè)階段，下面我們就來逐個(gè)詳細(xì)分析下。

1. 加載階段

我們先來分析如何系統(tǒng)優(yōu)化加載階段中的頁面，來看一個(gè)典型的渲染流水線，如下圖所示：

通過上面對瀏覽器渲染過程的分析我們知道JavaScript、首次請求的 HTML 資源文件、CSS 文件是會(huì)阻塞首次渲染的，因?yàn)樵跇?gòu)建 DOM 的過程中需要 HTML 和 JavaScript 文件，在構(gòu)造渲染樹的過程中需要用到 CSS 文件。

這些能阻塞網(wǎng)頁首次渲染的資源稱為關(guān)鍵資源。而基于關(guān)鍵資源，我們可以繼續(xù)細(xì)化出三個(gè)影響頁面首次渲染的核心因素：

關(guān)鍵資源個(gè)數(shù)。關(guān)鍵資源個(gè)數(shù)越多，首次頁面的加載時(shí)間就會(huì)越長。
關(guān)鍵資源大小。通常情況下，所有關(guān)鍵資源的內(nèi)容越小，其整個(gè)資源的下載時(shí)間也就越短，那么阻塞渲染的時(shí)間也就越短。
請求關(guān)鍵資源需要多少個(gè)RTT(Round Trip Time)。RTT 是網(wǎng)絡(luò)中一個(gè)重要的性能指標(biāo)，表示從發(fā)送端發(fā)送數(shù)據(jù)開始，到發(fā)送端收到來自接收端的確認(rèn)，總共經(jīng)歷的時(shí)延。

了解了影響加載過程中的幾個(gè)核心因素之后，接下來我們就可以系統(tǒng)性地考慮優(yōu)化方案了。總的優(yōu)化原則就是減少關(guān)鍵資源個(gè)數(shù)，降低關(guān)鍵資源大小，降低關(guān)鍵資源的 RTT 次數(shù)：

如何減少關(guān)鍵資源的個(gè)數(shù)?一種方式是可以將 JavaScript 和 CSS 改成內(nèi)聯(lián)的形式，比如上圖的 JavaScript 和 CSS，若都改成內(nèi)聯(lián)模式，那么關(guān)鍵資源的個(gè)數(shù)就由 3 個(gè)減少到了 1 個(gè)。另一種方式，如果 JavaScript 代碼沒有 DOM 或者 CSSOM 的操作，則可以改成 sync 或者 defer 屬性
如何減少關(guān)鍵資源的大小?可以壓縮 CSS 和 JavaScript 資源，移除 HTML、CSS、JavaScript 文件中一些注釋內(nèi)容
如何減少關(guān)鍵資源 RTT 的次數(shù)?可以通過減少關(guān)鍵資源的個(gè)數(shù)和減少關(guān)鍵資源的大小搭配來實(shí)現(xiàn)。除此之外，還可以使用 CDN 來減少每次 RTT 時(shí)長。

2. 交互階段

接下來我們再來聊聊頁面加載完成之后的交互階段以及應(yīng)該如何去優(yōu)化。

先來看看交互階段的渲染流水線：

其實(shí)這塊大致有以下幾點(diǎn)可以優(yōu)化：

(1) 避免DOM的回流。也就是盡量避免重排和重繪操作。

(2) 減少 JavaScript 腳本執(zhí)行時(shí)間。有時(shí)JavaScript 函數(shù)的一次執(zhí)行時(shí)間可能有幾百毫秒，這就嚴(yán)重霸占了主線程執(zhí)行其他渲染任務(wù)的時(shí)間。針對這種情況我們可以采用以下兩種策略：

一種是將一次執(zhí)行的函數(shù)分解為多個(gè)任務(wù)，使得每次的執(zhí)行時(shí)間不要過久。
另一種是采用 Web Workers。

(3) DOM操作相關(guān)的優(yōu)化。瀏覽器有渲染引擎和JS引擎，所以當(dāng)用JS操作DOM時(shí)，這兩個(gè)引擎要通過接口互相“交流”，因此每一次操作DOM(包括只是訪問DOM的屬性)，都要進(jìn)行引擎之間解析的開銷，所以常說要減少 DOM 操作?？偨Y(jié)下來有以下幾點(diǎn)：

緩存一些計(jì)算屬性，如let left = el.offsetLeft。
通過DOM的class來集中改變樣式，而不是通過style一條條的去修改。
分離讀寫操作?，F(xiàn)代的瀏覽器都有渲染隊(duì)列的機(jī)制。
放棄傳統(tǒng)操作DOM的時(shí)代，基于vue/react等采用virtual dom的框架

(4) 合理利用 CSS 合成動(dòng)畫。合成動(dòng)畫是直接在合成線程上執(zhí)行的，這和在主線程上執(zhí)行的布局、繪制等操作不同，如果主線程被 JavaScript 或者一些布局任務(wù)占用，CSS 動(dòng)畫依然能繼續(xù)執(zhí)行。所以要盡量利用好 CSS 合成動(dòng)畫，如果能讓 CSS 處理動(dòng)畫，就盡量交給 CSS 來操作。

(5) CSS選擇器優(yōu)化。我們知道CSS引擎查找是從右向左匹配的。所以基于此有以下幾條優(yōu)化方案：

盡量不要使用通配符
少用標(biāo)簽選擇器
盡量利用屬性繼承特性

(6) CSS屬性優(yōu)化。瀏覽器繪制圖像時(shí)，CSS的計(jì)算也是耗費(fèi)性能的，一些屬性需瀏覽器進(jìn)行大量的計(jì)算，屬于昂貴的屬性(box-shadows、border-radius、transforms、filters、opcity、:nth-child等)，這些屬性在日常開發(fā)中經(jīng)常用到，所以并不是說不要用這些屬性，而是在開發(fā)中，如果有其它簡單可行的方案，那可以優(yōu)先選擇沒有昂貴屬性的方案。

(7) 避免頻繁的垃圾回收。我們知道 JavaScript 使用了自動(dòng)垃圾回收機(jī)制，如果在一些函數(shù)中頻繁創(chuàng)建臨時(shí)對象，那么垃圾回收器也會(huì)頻繁地去執(zhí)行垃圾回收策略。這樣當(dāng)垃圾回收操作發(fā)生時(shí)，就會(huì)占用主線程，從而影響到其他任務(wù)的執(zhí)行，嚴(yán)重的話還會(huì)讓用戶產(chǎn)生掉幀、不流暢的感覺。

緩存

緩存可以說是性能優(yōu)化中簡單高效的一種優(yōu)化方式了。一個(gè)優(yōu)秀的緩存策略可以縮短網(wǎng)頁請求資源的距離，減少延遲，并且由于緩存文件可以重復(fù)利用，還可以減少帶寬，降低網(wǎng)絡(luò)負(fù)荷。下圖是瀏覽器緩存的查找流程圖：

瀏覽器緩存相關(guān)的知識(shí)點(diǎn)還是很多的，這里我有整理一張圖：

DNS 相關(guān)優(yōu)化

DNS全稱Domain Name System。它是互聯(lián)網(wǎng)的“通訊錄”，它記錄了域名與實(shí)際ip地址的映射關(guān)系。每次我們訪問一個(gè)網(wǎng)站，都要通過各級(jí)的DNS服務(wù)器查詢到該網(wǎng)站的服務(wù)器ip，然后才能訪問到該服務(wù)器。

DNS相關(guān)的優(yōu)化一般涉及到兩點(diǎn)：瀏覽器DNS緩存和DNS預(yù)解析。

1. DNS緩存

一圖勝千言：

瀏覽器會(huì)先檢查瀏覽器緩存(瀏覽器緩存有大小和時(shí)間限制)，時(shí)間過長可能導(dǎo)致IP地址變化，無法解析正確IP地址，過短就會(huì)讓瀏覽器重復(fù)解析域名，一般為幾分鐘。
如果瀏覽器緩存沒有對應(yīng)域名，則會(huì)去操作系統(tǒng)緩存中查找。
如果還沒有找到，域名就會(huì)發(fā)送到本地區(qū)的域名服務(wù)器(一般由互聯(lián)網(wǎng)供應(yīng)商提供，電信、聯(lián)通之類)，一般在本地區(qū)的域名服務(wù)器上都能找到了。
當(dāng)然也可能本地域名服務(wù)器也沒找到，那本地域名服務(wù)器就開始遞歸查找。

一般而言，瀏覽器解析DNS需要20-120ms，因此DNS解析可優(yōu)化之處幾乎沒有。但存在這樣一個(gè)場景，網(wǎng)站有很多圖片在不同域名下，那如果在登錄頁就提前解析了之后可能會(huì)用到的域名，使解析結(jié)果緩存過，這樣縮短了DNS解析時(shí)間，提高網(wǎng)站整體上的訪問速度了，這就是DNS預(yù)解析。

2. DNS預(yù)解析

來看下 MDN 對于DNS預(yù)解析的定義吧：

X-DNS-Prefetch-Control 頭控制著瀏覽器的 DNS 預(yù)讀取功能。DNS 預(yù)讀取是一項(xiàng)使瀏覽器主動(dòng)去執(zhí)行域名解析的功能，其范圍包括文檔的所有鏈接，無論是圖片的，CSS 的，還是 JavaScript 等其他用戶能夠點(diǎn)擊的 URL。

因?yàn)轭A(yù)讀取會(huì)在后臺(tái)執(zhí)行，所以 DNS 很可能在鏈接對應(yīng)的東西出現(xiàn)之前就已經(jīng)解析完畢。這能夠減少用戶點(diǎn)擊鏈接時(shí)的延遲。

我們這里就簡單看一下如何去做DNS預(yù)解析：

在頁面頭部加入，這樣瀏覽器對整個(gè)頁面進(jìn)行預(yù)解析

通過 link 標(biāo)簽手動(dòng)添加要解析的域名，比如：

新聞標(biāo)題：聊一聊前端性能優(yōu)化CRP
標(biāo)題URL：http://fisionsoft.com.cn/article/djdipoh.html

新聞中心

其他資訊