如今咱們主要接觸的主流瀏覽器有:IE, FireFox, Safari, Chrome,Opera; 你真的瞭解它們嗎?css
主流瀏覽器 js引擎 IE -> Edge JScript(IE3.0-IE8.0) / Chakra Chrome V8(大名鼎鼎) Safari Nitro(4-) Firefox SpiderMonkey(1.0-3.0)/ TraceMonkey(3.5-3.6) Opera Linear A(4.0-6.1)/ Linear B(7.0-9.2)
主流瀏覽器 內核 IE -> Edge trident->EdgeHTML Chrome webkit->blink Safari webkit Firefox Gecko Opera Presto->blink
從網絡層獲取請求文檔的內容(內容的大小通常限制在8000個塊之內)---> 解析HTML構造DOM樹和CSSOM樹--->構建渲染樹(把DOM樹中的一些不可視元素去掉, 而後與CSSOM合成一棵render樹)--->渲染DOM樹佈局(計算出各個節點(元素)在屏幕的位置) -->渲染樹繪製(瀏覽器根據渲染樹將頁面渲染到屏幕)
解析HTML/XHTML文檔時,將各標記逐個轉化成"內容樹"上的DOM節點,遇到css標籤或JS腳本標籤就下載和解析(其中css是異步下載同步執行);html
在構建DOM樹過程當中,當遇到css元素{包括外部CSS樣式以及內聯樣式},瀏覽器會開啓一個異步請求線程,在該線程上,瀏覽器會去請求相應的css文件,而且根據該文件去構建CSSOM樹(也叫css rule),css的加載並不會致使html解析和渲染的中止,即不會阻塞dom樹的構建;該線程會阻塞 JavaScript引擎線程(即css後 面的js模塊的解析會在css解析完畢後執行),由於js腳本不只能夠讀取修改到dom,也能夠讀取修改到cssom。故在js腳本執前,browser必須保證到css文件徹底加載並解析完成,即cssom樹徹底構建好。這就致使了js執行的延遲,也所以致使html解析和渲染延遲。(這就是css阻塞js執行,阻塞渲染的根本緣由)html5
構建DOM樹過程當中,瀏覽器渲染和 JS 執行是共用一個線程,即單線程工做,多線程會產生渲染 DOM 衝突。若是遇到當遇到JS元素時,HTML解析器就會將控制權轉讓給JavaScript引擎線程,該線程會阻斷HTML解析器的運行,就阻塞了DOM樹的構建 當js加載而且執行完畢後,JavaScript引擎線程會將控制權還給HTML解析器,讓其去繼續構建dom樹。也就是說,若是你想首屏渲染的越快,就越不該該在首屏就加載 JS 文件,這也是都建議將 script 標籤放在 body 標籤底部的緣由。固然,並非說 script 標籤必須放在底部,由於你能夠給 script 標籤添加 defer 或者 async 屬性git
JS文件不僅是阻塞DOM的構建,它會致使CSSOM也阻塞DOM的構建。本來DOM和CSSOM的構建是互不影響,井水不犯河水,可是一旦引入了JavaScript,CSSOM也開始阻塞DOM的構建,只有CSSOM構建完畢後,再恢復DOM樹構建。這是由於JavaScript不僅是能夠改DOM,它還能夠更改樣式,也就是它能夠更改CSSOM。由於不完整CSSOM是沒法使用的,若是JavaScript想訪問CSSOM並更改它,那麼在執行JavaScript時,必需要能拿到完整的CSSOM。因此就致使了一個現象,若是瀏覽器還沒有完成CSSOM的下載和構建,而咱們卻想在此時運行腳本,那麼瀏覽器將延遲腳本執行和DOM構建,直至其完成CSSOM的下載和構建。也就是說,在這種狀況下,瀏覽器會先下載和構建CSSOM,而後再執行JavaScript,最後在繼續構建DOM。github
CSS規則樹中的元素是和 DOM 元素相對應的,但並不是一一對應。非可視化的 DOM 元素不會插入規則樹中,例如「head」元素。若是元素的 display 屬性值爲「none」,那麼也不會顯示在規則樹中(可是 visibility 屬性值爲「hidden」的元素仍會顯示)。有一些 DOM 元素對應多個可視化對象。它們每每是具備複雜結構的元素,沒法用單一的矩形來描述。web
經過 CSS 規則樹 匹配 DOM 樹每一個節點分配一個應出如今屏幕上的確切座標,即進行定位座標和大小面試
呈現引擎會遍歷呈現樹,由用戶界面後端層將每一個節點繪製出來。數據庫
2019-05-05 18:42:17 星期日