crp（critical rendering path）：關鍵渲染路徑；渲染的機制和步驟，去詳細地進行每一步的優化，以此來提高頁面的渲染速度和執行效能。
頁面之所以能渲染
從伺服器獲取到需要渲染的內容(url解析/dns/tcp/http…)
瀏覽器會基於自己的渲染引擎（例如：webkit/gecko/trident/blink…）開始自上而下載入渲染**
從伺服器獲取的是檔案流（進製**的內容）
瀏覽器首先會把16進製制的位元組資訊編譯為「**字串」
按照w3c規則進行字串解析，生成對應的tokens，最後轉換為瀏覽器核心可以識別渲染的dom節點（詞法解析）
按照節點最後解析為對應的樹 dom tree / cssom tree
瀏覽器拿到**後自上而下渲染解析，宣告文件標識，宣告html，head，title…
程序 vs 執行緒
乙個程序可能包含多個執行緒瀏覽器開啟頁面會開闢乙個程序（每乙個頁面都是乙個程序），瀏覽器本身是多執行緒，有多個執行緒就能同時做很多事情，乙個執行緒同時只能幹一件事情。
瀏覽器可以開闢多個執行緒 / 程序的：
同步程式設計 vs 非同步程式設計
同步程式設計：一般只有乙個執行緒去處理事情，上面的事情處理不完，下面的事情無法處理（一件一件事情的去幹）
非同步程式設計：
css樣式的方式
頁面渲染過程中
遇到link，瀏覽器會開闢乙個新的http執行緒去載入資源檔案資訊，同時gui渲染執行緒會繼續向下渲染**，不論css是否請求回來，**繼續渲染（非同步）
遇到的是@import ，瀏覽器開闢乙個http執行緒去伺服器請求資源檔案，gui渲染執行緒會暫時停止渲染，資源檔案沒有返回之前，是不會繼續渲染的@import阻礙瀏覽器的渲染，專案中盡量少用（同步）
遇到:阻礙gui的渲染,可以新增一些事件解決這個問題
* 假如有五個js請求，如果不設定任何屬性，肯定是按照順序請求和渲染js的【依賴關係是有效的】；但是如果設定async，誰先請求回來就先渲染誰，依賴關係無效；如果使用defer是可以建立依賴關係的(瀏覽器內部在gui渲染完成後，等待所有設定defer的資源都請求回來，在按照編寫的的依賴順序去載入js。
* 真實專案開發中，一般把link放在頁面的頭部【為了在沒有渲染dom的時候，就通知http去請求css，這樣dom渲染完，css差不多也就回來了，更有效利用時間，提高頁面的渲染速度】；把js放在頁面的底部，防止其阻礙guide渲染，如果不放在底部，我們最好設定async / defer。 async / defer載入發生在load之前，domcontentload之後觸發
構建dom樹、cssom樹、render樹
【dom樹】
【cssom樹】
【render-tree渲染樹】
步驟總結：
這樣才能看到所有頁面內容了
render-tree（domcontentloaded事件觸發）-> 執行js -> cssom tree ->render tree渲染樹【瀏覽器未來是按照這個樹來繪製頁面的】，-> layout布局計算【回流 / 重排】->painting繪製【重繪】
效能優化
減少dom樹渲染時間（html層級不要太深，標籤語義化...）
減少cssom樹渲染時間（選擇器是從右到左解析的，所以盡可能減少選擇器的層級【less/sass中的層級巢狀雖然好用 ，但是是乙個大坑】）
減少http的請求次數和請求大小（http的資源檔案有併發上線6~7）
一般會把css請求放在頁面的開始位置（充分利用http多請求併發機制），提前請求資源 用link 不用@import，對於移動端來講，如果css比較少，盡量使用內嵌式）
為了避免白屏，進來第一件事，快速生成一套loading的渲染樹（前端骨架屏：位置留好了，但是沒有內容）；伺服器的ssr骨架屏所提高的渲染是為了避免客服端再次單獨請求資料，而不是樣式和結構上的（首屏處理）
js載入放到頁面的底部，並且盡可能使用async或者defer 避免阻塞的js載入
以上這些叫做crp效能優化節點。
白屏
所謂白屏，就是當前裝置開啟頁面，第一步從伺服器請求回來html，然後渲染，渲染過程中請求css資源，生成dom樹、cssom樹、render-tree渲染樹，最後整個渲染頁面，這個過程是需要時間的，從請求頁面到整個所有東西沒有完成之前所經歷的時間會產生乙個白屏的效果。
白屏優化：減少第一次頁面渲染時間，包括後續開啟時間，這些優化就是項效能優化的關鍵點。
瀏覽器底層渲染機制（筆記）
瀏覽器底層渲染機制 從伺服器獲取的是檔案流 進製編碼內容 1.瀏覽器首先把16進製制的字元資訊編譯為 字串 2.按照w3c規則進行字元解析，生成對應的tokens,最後轉化為瀏覽器內部可以識別渲染的dom節點 3.按照節點最後解析為對應的樹dom tree css tree 程序是乙個應用程式，乙個...
瀏覽器底層渲染機制和效能優化
1.客戶端從伺服器獲取到需要渲染的源 後 瀏覽器開闢乙個 gui渲染執行緒 自上而下解析 最後繪製出對應的頁面 1 關於css 的資源的載入 遇到的是 內嵌樣式 同步 交給gui渲染執行緒解析 遇到的是 外鏈樣式 非同步 開闢乙個新的 http網路請求執行緒 注意 同乙個源下，根據不同的瀏覽器，最多...
瀏覽器渲染機制
google web fundamentals 是乙個非常優秀的文件，裡面講到了跟web 瀏覽器 前端的方方面面。我總結一下其中的 ilya grigorik 寫的 critical rendering path 瀏覽器渲染機制部分的內容如下 1 dom document object model，...