瀏覽器底層渲染機制
從伺服器獲取的是檔案流（進製編碼內容）
1.瀏覽器首先把16進製制的字元資訊編譯為"**字串"
2.按照w3c規則進行字元解析，生成對應的tokens,最後轉化為瀏覽器內部可以識別渲染的dom節點
3.按照節點最後解析為對應的樹dom-tree/css-tree
程序是乙個應用程式，乙個程序中可能包含多個執行緒。乙個執行緒同時只能幹一件事情，瀏覽器渲染頁面的叫做gui執行緒，請求資源就是http執行緒，瀏覽器是多執行緒的。link和import(從伺服器獲取我們的樣式檔案)的區別：瀏覽器資源請求併發6-7個
1.遇到link 瀏覽器會派發乙個新的執行緒 http執行緒去載入資源檔案，與此同時gui執行緒會繼續向下渲染**（不論css是否請求回來，**繼續渲染）２.遇到＠import時候會停止gui，直到資源檔案請求回來再繼續執行gui
３.如果是style，gui直接執行
頁面渲染第一步 ：在ｃｓｓ資源還沒有請求回來之前，先生成dom樹（dom層級關係／節點關係）
頁面渲染第二步：當所有的css請求回來之後，瀏覽器按照css匯入順序，依次進行渲染，最後生成cssom樹
頁面渲染第三步：把dom樹和cssom樹結合到一起，生成有樣式有結構的render-tree渲染樹最後瀏覽器按照渲染樹在頁面進行渲染和解析
1）計算元素在裝置視口中的大小和位置 布局/回流
2）根據渲染樹以及回流得到的幾何資訊，得到節點的絕對畫素 重繪
效能優化(crp效能節點優化)
1.減少dom樹渲染時間（thml層級不要太深，標籤語義化）
2.減少cssom樹渲染時間（選擇器是從右向左解析，盡可能減少選擇器的層級【less／sass的層級巢狀雖然好用，但是效能會不好】）
3.減少http的請求次數和請求大小
４.一般會把css放到css頁面開始的位置（對於移動端來講，如果css比較少，盡可能使用內嵌樣式）
５.為了避免白屏，可以進來第一件事情，快速生成一套lodging的渲染樹（前端骨架屏）；伺服器的ssr骨架屏所提高的渲染是避免了客戶端再次單獨請求資料，而不是樣式和結構的；
6.正常情況下js也會阻礙gui的渲染，所以一般放在底部，確保dom生成完才去載入js，使用async和defer非同步去管控js 請求defer等待所有的js載入完，根據順序去分別渲染js（js中有相互依賴的必須用defer）
//此段**要等 link請求完，即使下面的是內嵌樣式。才能讓下面生成cssomtree 、dom tree
=>遇到js都是先把js執行的，
按照指定的順序依次渲染css** cssom樹render tree
laout 計算元素在頁面中的位置和大小
pating 按照計算的結果進行繪製【分圖層繪製】
defer async
defer 遇到 script defer：gui繼續渲染，同時http去請求，請求回來也不會立即執行，而是等到gui渲染完，再去按照之前引入的script順序 依次去執行 （依賴順序的）
async ： gui繼續，http請求，當請求回來後，立即執行js（gui暫停），js執行完gui繼續 誰先回來誰執行（沒有依賴順序）
理論上 只有 dom tree +cssom tree =>render tree layout pating 頁面才會呈現出內容
真實情況下 如果乙個css資源請求時間過長，瀏覽器也不等了，自己先把渲染好的 呈現處理
了解瀏覽器底層渲染機制
crp critical rendering path 關鍵渲染路徑 渲染的機制和步驟，去詳細地進行每一步的優化，以此來提高頁面的渲染速度和執行效能。頁面之所以能渲染 從伺服器獲取到需要渲染的內容 url解析 dns tcp http 瀏覽器會基於自己的渲染引擎 例如 webkit gecko tr...
瀏覽器底層渲染機制和效能優化
1.客戶端從伺服器獲取到需要渲染的源 後 瀏覽器開闢乙個 gui渲染執行緒 自上而下解析 最後繪製出對應的頁面 1 關於css 的資源的載入 遇到的是 內嵌樣式 同步 交給gui渲染執行緒解析 遇到的是 外鏈樣式 非同步 開闢乙個新的 http網路請求執行緒 注意 同乙個源下，根據不同的瀏覽器，最多...
瀏覽器渲染機制
google web fundamentals 是乙個非常優秀的文件，裡面講到了跟web 瀏覽器 前端的方方面面。我總結一下其中的 ilya grigorik 寫的 critical rendering path 瀏覽器渲染機制部分的內容如下 1 dom document object model，...