從瀏覽器內部執行機制看效能優化

2021-10-04 06:43:58 字數 1612 閱讀 5816

了解瀏覽器背後的執行機制就是了解瀏覽器的核心,現在市面上主流瀏覽器的核心名稱分別如下:

** 注:blink核心其實是基於webkit核心衍生出的乙個新分支 **

獲取到的html/css/js資源經過瀏覽器核心的處理生成影象呈現在瀏覽器上,那麼下面我們就詳細說說瀏覽器核心在拿到資源之後是經過哪些處理來生成我們最終所看到的頁面。

瀏覽器在處理資源的過程中是由多個模組協同工作的,主要關注下面幾個模組:

上面整個過程就是瀏覽器渲染頁面的主要過程,在這個過程中主要是按順序生成了下面幾棵樹:

在渲染過程這部分內容我們了解到在渲染過程中會根據css來形成css樹,那麼能在這個過程中做哪些優化呢?在說明css優化的方法之前先介紹一下css的解析規則。

我們在編寫css的過程中,一般是從左到右去進行編寫,比如我們想給類名為test_parent下的p標籤去增加樣式的時候,一般會這樣寫:

.test_parent p

但是這樣些會造成很大的效能問題,為什麼呢?因為瀏覽器在解析css的過程中對於宣告是從右往左進行匹配的。對於上面這種寫法瀏覽器的做法會先找到dom樹中的所有標籤為p的節點,然後再去這些p節點中去找哪些p節點的父節點的類為test_parent。由於p節點在我們的頁面中可能會有很多很多,這樣就導致尋找的過程會變長。

從上面的內容中我們就可以得出第乙個css優化的思路,優化css宣告的編寫,有下面幾種優化方式:

介紹完css選擇器的優化之後,我們再來回想一下上面的渲染過程,頁面形成的過程中一顆重要的樹render樹是由dom樹和css樹合力生成的,那麼如果沒有css樹render樹也就不會形成,更不必談最終的頁面了,所以第二個優化思路就是盡快讓css樹去形成,而css樹的形成是瀏覽器解析css檔案生成的,那麼為了讓css樹形成,我們可以採取下面的方式去優化:

至此我們已經對css樹的形成和render樹的形成做了優化,那麼css還有可優化的點嗎?答案是有的,在上述的渲染過程中在render樹後面還形成了一棵布局渲染樹,那麼在這棵樹的形成過程中我們能做哪些優化呢?布局渲染樹是瀏覽器根據render樹去計算每個dom節點的大小以及所在頁面中的位置,這些計算是依賴我們編寫的css宣告,比如:

.wrap

為了能夠讓瀏覽器快速的計算節點的位置和大小我們應該遵循css的宣告順序:

至此關於css的優化已經結束了,下面來說說渲染過程中js的一些優化

看到這我們會發現上面很少提及js,不是js不重要哈,是在渲染過程中js基本上不需要,那麼為什麼要提及js呢,因為js會阻塞html的解析,比如下面這段**

>

>

js之前的htmldiv

>

>

console.

log(

'js執行了');

script

>

>

js之後的htmldiv

>

body

>

瀏覽器解析時,遇到上面的js時瀏覽器會把控制權交給js引擎,這時瀏覽器就會停止dom樹的解析。這樣就延遲了dom樹的生成。那麼對於這種情況我們有哪些優化呢?

async和defer的作用:

JS執行機制 瀏覽器快取

1.dcotype及作用 dtd 告訴瀏覽器是什麼文件型別 xml html 決定哪種協議來解析 及切換瀏覽器模式 dcotype 用來宣告文件型別和dtd規範,乙個主要用途是檔案的合法性驗證。若檔案 不合法,那麼瀏覽器解析時便會出錯。dcotype型別和寫法 2.瀏覽器渲染過程 3.重拍reflo...

js執行機制(瀏覽器多程序)

瀏覽器的每個tab相當於乙個程序,可在瀏覽器的任務管理器中檢視,如下 在這裡瀏覽器應該也有自己的優化機制,有時候開啟多個tab頁後,可以在chrome任務管理器中看到,有些程序被合併了 所以每乙個tab標籤對應乙個程序並不一定是絕對的 瀏覽器多程序設計的優勢 1.充分利用瀏覽器的多核優勢 2.避免單...

瀏覽器渲染機制與效能優化

詳讀了很多文章,最終對比總結出來的瀏覽器渲染機制,並提出相應的優化原則 瀏覽器將從伺服器中獲取的html文件逐步解析,構建dom樹 在構建dom樹時,如果碰到js和css,會載入執行並阻塞html的解析,即html解析器會將控制權交給js或css解析器,當這個元素被解析完之後,將控制權重交回給htm...