瀏覽器渲染頁面原理,reflow、repaint及其優化

瀏覽器的主要組件包括:

1.      用戶界面 - 包括地址欄、前進/後退按鈕、書籤菜單等。除了瀏覽器主窗口顯示的你請求的頁面外,其他顯示的各個部分都屬於用戶界面。

2.      瀏覽器引擎 - 在用戶界面和渲染引擎之間傳送指令。

3.      渲染引擎 - 負責顯示請求的內容。如果請求的內容是 HTML,它就負責解析 HTML 和 CSS 內容,並將解析後的內容顯示在屏幕上。

4.      網絡 - 用於網絡調用,比如 HTTP 請求。其接口與平臺無關,併爲所有平臺提供底層實現。

5.      用戶界面後端 - 用於繪製基本的窗口小部件,比如組合框和窗口。其公開了與平臺無關的通用接口,而在底層使用操作系統的用戶界面方法。

6.      JavaScript 解釋器。用於解析和執行 JavaScript 代碼,比如chrome的JavaScript解釋器是V8。

7.      數據存儲。這是持久層。瀏覽器需要在硬盤上保存各種數據,例如 Cookie。新的 HTML 規範 (HTML5)定義了“網絡數據庫”,這是一個完整(但是輕便)的瀏覽器內數據庫。

 

關鍵路徑渲染(Critical Rendering Path):漸進式


瀏覽器拿到HTML之後的渲染過程:(不同內核實現不一樣但大概是這樣)

1.      解析HTML,構建DOM tree

2.      解析CSS,構建CSSOM tree

3.      合併DOM treeCSSOM tree,生成render tree

4.      佈局(layout/reflow),計算各元素尺寸、位置。

5.      繪製(paint/repaint),繪製頁面像素信息。

6.      瀏覽器將各層的信息發送給GPUGPU將各層合成,顯示在屏幕上。

當修改了DOMCSSOM,上述過程中的一些步驟就會重複執行。

 

構建OM要經過Bytes characters tokens nodes object model這個過程。

 

TIPS:

解析HTML遇到外部CSS立即請求 ----CSS文件合併,減少HTTP請求;

新的CSS style修改CSSOM,會重新渲染頁面 ----CSS文件應放在頭部,縮短首次渲染時間

遇到<img>會發出請求,但不會阻塞,服務器返回圖片文件,由於圖片佔用了一定面積,影響了後面段落的排布,因此瀏覽器需要回過頭來重新渲染這部分代碼;(最好圖片都設置尺寸,避免重新渲染)

遇到<script> 標籤,會立即執行js代碼,阻塞渲染。script最好放置頁面最下面)

js修改DOM會重新渲染。 (頁面初始化樣式不要使用js控制) 

 

reflow迴流:

當某個部分發生了變化影響了佈局,需要倒回去重新渲染, 該過程稱爲reflow(迴流)。reflow 幾乎是無法避免的。現在界面上流行的一些效果,比如樹狀目錄的摺疊、展開(實質上是元素的顯 示與隱藏)等,都將引起瀏覽器的 reflow。鼠標滑過、點擊……只要這些行爲引起了頁面上某些元素的佔位面積、定位方式、邊距等屬性的變化,都會引起它內部、周圍甚至整個頁面的重新渲染。通常我們無法預估瀏覽器到底會 reflow 哪一部分的代碼,它們彼此相互影響。

repaint重繪:

如果只是改變某個元素的背景色、文字顏色、邊框顏色等等不影響它周圍或內部佈局的屬性,將只會引起瀏覽器 repaint(重繪)。repaint 的速度明顯快於 reflow(在IE下需要換一下說法,reflow 要比 repaint 更緩慢)。

reflow一定引起repaint,而repaint不一定要reflow。reflow的成本比repaint高很多,DOM tree裏每個結點的reflow很可能觸發其子結點、祖先結點、兄弟結點的reflow。reflow(迴流)是導致DOM腳本執行低效的關鍵因素之一。

 現代瀏覽器會對迴流做優化,它會等到足夠數量的變化發生,再做一次批處理迴流。

 GoogleChromeLabs裏面有一個csstriggers,列出了各個CSS屬性對瀏覽器執行Layout、Paint、Composite的影響。

 

在哪些情況下會導致reflow發生:

l  改變窗囗大小

l  改變文字大小

l  添加/刪除樣式表

l  內容的改變,如用戶在輸入框中敲字

l  激活僞類,如:hover (IE裏是一個兄弟結點的僞類被激活)

l  操作class屬性

l  腳本操作DOM

l  計算offsetWidth和offsetHeight

l  設置style屬性

 

優化,儘量避免reflow:

l  儘可能限制reflow的影響範圍,修改DOM層級較低的結點。不要通過父級元素影響子元素樣式。最好直接加在子元素上。改變子元素樣式儘可能不要影響父元素和兄弟元素的尺寸。

l  不要一條一條的修改DOM的style,最好通過設置class的方式。 避免觸發多次reflow和repaint。

l  經常reflow的元素,比如動畫,position設爲fixed或absolute,使其脫離文檔流,不影響其它元素的佈局。

l  權衡速度的平滑。比如實現一個動畫,以1個像素爲單位移動這樣最平滑,但reflow就會過於頻繁,CPU很快就會被完全佔用。如果以3個像素爲單位移動就會好很多。

l  不要用tables佈局。tables中某個元素一旦觸發reflow就會導致table裏所有的其它元素reflow。在適合用table的場合,可以設置table-layout爲auto或fixed,這樣可以讓table一行一行的渲染,這種做法也是爲了限制reflow的影響範圍。

l  避免使用css expression(每次都會重新計算)。

l  減少不必要的 DOM 層級(DOM depth)。改變 DOM 樹中的一級會導致所有層級的改變,上至根部,下至被改變節點的子節點。這導致大量時間耗費在執行 reflow 上面。

l  避免不必要的複雜的 CSS 選擇器,尤其是後代選擇器(descendant selectors),因爲爲了匹配選擇器將耗費更多的 CPU。

l  儘量不要頻繁的增加、修改、刪除元素,可以先把DOM節點抽離到內存中進行復雜的操作然後再display到頁面上。(display:none的節點不會被加入render tree,而visibility:hidden會;display:none會觸發reflow,而visibility:hidden只會觸發repaint,因爲layout沒有變化)。

 

讓要進行復雜操作的元素進行“離線處理”,處理完後一起更新:

1.          使用DocumentFragment, DocumentFragment節點不屬於文檔樹,繼承的parentNode屬性總是null。

    //不建議的做法
for(var i = 0 ; i < 10000; i ++) {
        var p = document.createElement("p");
        var oTxt = document.createTextNode("段落" + i);
        p.appendChild(oTxt);
        document.body.appendChild(p);
    }
    //將這些元素添加到DocumentFragment中,再將DocumentFragment添加到頁面
    var oFragment = document.createDocumentFragment();
    for(var i = 0 ; i < 10000; i ++) {
        var p = document.createElement("p");
        var oTxt = document.createTextNode("段落" + i);
        p.appendChild(oTxt);
        oFragment.appendChild(p);
    }
    document.body.appendChild(oFragment);

jQuery的 append等方法內部也是通過createDocumentFragment來實現的,最好在循環外一次性批量添加DOM元素。 

    //不建議的做法

    varbrowserList = ["IE", "Mozilla Firefox", "Safari", "Chrome", "Opera"];

   $.each(browserList, function (index,value) {

        $('<li>').text(value).appendTo($('ul').eq(0));

    })

    //好的做法NO1

    varbrowserList = ["IE", "Mozilla Firefox", "Safari", "Chrome", "Opera"];

    varmyHTML = '';

   $.each(browserList, function (index, value) {

        myHTML += '<li>' + value + '</li>';

    })

    $('ul').eq(0).html(myHTML);

    //好的作法NO2

    var frag= document.createDocumentFragment();

    varbrowserList = ["IE", "Mozilla Firefox", "Safari", "Chrome", "Opera"];

   $.each(browserList, function (index, value) {

        varli = document.createElement("li");

       li.textContent = value;

        frag.appendChild(li);

    })

    $('ul').eq(0).append($(frag));

2.      使用display:none,先隱藏後顯示,只會引起兩次reflow和repaint。因display:none的元素不在render tree,對其操作不會引起其他元素的reflow和repaint。

3.      使用cloneNodereplaceChild,引發一次reflow和repaint

 

阻塞渲染:CSS JavaScript

談論資源的阻塞時,我們要清楚,現代瀏覽器總是並行加載資源。例如,當 HTML 解析器(HTML Parser)被腳本阻塞時,解析器雖然會停止構建 DOM,但仍會識別該腳本後面的資源,並進行預加載。

同時,由於下面兩點:

1. 默認情況下,CSS 被視爲阻塞渲染的資源,這意味着瀏覽器將不會渲染任何已處理的內容,直至 CSSOM 構建完畢。

2. JavaScript 不僅可以讀取和修改 DOM 屬性,還可以讀取和修改 CSSOM 屬性。

存在阻塞的 CSS 資源時,瀏覽器會延遲 JavaScript 的執行和 DOM 構建。另外:

1. 當瀏覽器遇到一個 script 標記時,DOM 構建將暫停,直至腳本完成執行。

2. JavaScript 可以查詢和修改 DOM CSSOM

3. CSSOM 構建時,JavaScript 執行將暫停,直至 CSSOM 就緒。

所以,script 標籤的位置很重要。實際使用時,可以遵循下面兩個原則:

1. CSS 優先:引入順序上,CSS 資源先於 JavaScript 資源。

2. JavaScript 應儘量少影響 DOM 的構建。

瀏覽器的發展日益加快(目前的 Chrome 官方穩定版是 61),具體的渲染策略會不斷進化,但瞭解這些原理後,就能想通它進化的邏輯。下面來看看 CSS JavaScript 具體會怎樣阻塞資源。

CSS

<style>p{color:red;}</style>
<link rel="stylesheet" href="index.css">

這樣的 link 標籤(無論是否 inline)會被視爲阻塞渲染的資源,瀏覽器會優先處理這些 CSS 資源,直至 CSSOM 構建完畢。

渲染樹(Render-Tree)的關鍵渲染路徑中,要求同時具有 DOM CSSOM,之後纔會構建渲染樹。即,HTML CSS 都是阻塞渲染的資源。HTML 顯然是必需的,因爲包括我們希望顯示的文本在內的內容,都在 DOM 中存放,那麼可以從 CSS 上想辦法。

最容易想到的當然是精簡 CSS 並儘快提供它。除此之外,還可以用媒體類型(media type)和媒體查詢(media query)來解除對渲染的阻塞。

<link href="index.css" rel="stylesheet">
<link href="print.css" rel="stylesheet" media="print">
<link href="other.css" rel="stylesheet" media="(min-width: 30em) and (orientation: landscape)">

第一個資源會加載並阻塞。
第二個資源設置了媒體類型,會加載但不會阻塞,print 聲明只在打印網頁時使用。
第三個資源提供了媒體查詢,會在符合條件時阻塞渲染。

JavaScript

JavaScript的情況比 CSS 要更復雜一些。觀察下面的代碼:

<p>Do not go gentle into that good night,</p>
<script>console.log("inline")</script>
<p>Old age should burn and rave at close of day;</p>
<script src="app.js"></script>
<p>Rage, rage against the dying of the light.</p>
 
<p>Do not go gentle into that good night,</p>
<script src="app.js"></script>
<p>Old age should burn and rave at close of day;</p>
<script>console.log("inline")</script>
<p>Rage, rage against the dying of the light.</p>

這樣的 script 標籤會阻塞 HTML 解析,無論是不是 inline-script。上面的 P 標籤會從上到下解析,這個過程會被兩段 JavaScript 分別打斷一次(加載並且執行的時間段內)。

所以實際工程中,我們常常將資源放到文檔底部。

改變阻塞模式:defer async

爲什麼要將 script 加載的 defer async 方式放到後面呢?因爲這兩種方式是的出現,全是由於前面講的那些阻塞條件的存在。換句話說,defer async 方式可以改變之前的那些阻塞情形。

首先,注意 async defer 屬性對於 inline-script 都是無效的,所以下面這個示例中三個 script 標籤的代碼會從上到下依次執行。

<!-- 按照從上到下的順序輸出 1 2 3 -->
<script async>
  console.log("1");
</script>
<script defer>
  console.log("2");
</script>
<script>
  console.log("3");
</script>

故,下面兩節討論的內容都是針對設置了 src 屬性的 script 標籤。

defer

<script src="app1.js" defer></script>
<script src="app2.js" defer></script>
<script src="app3.js" defer></script>

defer屬性表示延遲執行引入的 JavaScript,即這段 JavaScript 加載時 HTML 並未停止解析,這兩個過程是並行的。整個 document 解析完畢且 defer-script 也加載完成之後(這兩件事情的順序無關),會執行所有由 defer-script 加載的 JavaScript 代碼,然後觸發 DOMContentLoaded 事件。

defer不會改變 script 中代碼的執行順序,示例代碼會按照 123 的順序執行。所以,defer 與相比普通 script,有兩點區別:載入 JavaScript 文件時不阻塞 HTML 的解析,執行階段被放到 HTML 標籤解析完成之後。

async

<script src="app.js" async></script>
<script src="ad.js" async></script>
<script src="statistics.js" async></script>

async屬性表示異步執行引入的 JavaScript,與 defer 的區別在於,如果已經加載好,就會開始執行——無論此刻是 HTML 解析階段還是 DOMContentLoaded 觸發之後。需要注意的是,這種方式加載的 JavaScript 依然會阻塞 load 事件。換句話說,async-script 可能在 DOMContentLoaded 觸發之前或之後執行,但一定在 load 觸發之前執行。

從上一段也能推出,多個 async-script 的執行順序是不確定的。值得注意的是,向 document 動態添加 script 標籤時,async 屬性默認是 true,下一節會繼續這個話題。

document.createElement

使用 document.createElement 創建的 script 默認是異步的,示例如下。

console.log(document.createElement("script").async);// true

所以,通過動態添加 script 標籤引入 JavaScript 文件默認是不會阻塞頁面的。如果想同步執行,需要將 async 屬性人爲設置爲 false

如果使用 document.createElement 創建 link 標籤會怎樣呢?

conststyle=document.createElement("link");
style.rel="stylesheet";
style.href="index.css";
document.head.appendChild(style);// 阻塞?

其實這隻能通過試驗確定,已知的是,Chrome 中已經不會阻塞渲染FirefoxIE 在以前是阻塞的,現在會怎樣我沒有試驗。

document.write innerHTML

通過 document.write 添加的 link script 標籤都相當於添加在 document 中的標籤,因爲它操作的是 document stream(所以對於 loaded 狀態的頁面使用 document.write 會自動調用 document.open,這會覆蓋原有文檔內容)。即正常情況下, link 會阻塞渲染,script 會同步執行。不過這是不推薦的方式,Chrome 已經會顯示警告,提示未來有可能禁止這樣引入。如果給這種方式引入的 script 添加 async 屬性,Chrome 會檢查是否同源,對於非同源的 async-script 是不允許這麼引入的。

如果使用 innerHTML 引入 script 標籤,其中的 JavaScript 不會執行。當然,可以通過 eval() 來手工處理,不過不推薦。如果引入 link 標籤,我試驗過在 Chrome 中是可以起作用的。另外,outerHTMLinsertAdjacentHTML() 應該也是相同的行爲,我並沒有試驗。這三者應該用於文本的操作,即只使用它們添加 text 或普通 HTML Element

  

參考:

http://www.cnblogs.com/Peng2014/p/4687218.html

https://segmentfault.com/a/1190000014070240

https://developers.google.com/web/fundamentals/performance/critical-rendering-path/

https://zhuanlan.zhihu.com/p/29418126 

 

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章