大家好，我卡頌。
在中文社群，這麼多年一直流傳一個說法：
JS執行緒負責執行JS，GUI渲染執行緒負責渲染，這兩者是互斥的，所以JS執行時會阻塞渲染。
但隨著Dev Tools使用的增多，逐漸開始懷疑以上說法。本文會以實際案例來解釋為什麼JS阻塞渲染。
歡迎加入人類高質量前端框架群，帶飛
到底幾個執行緒
在講解JS執行緒與GUI執行緒互斥的文章中，通常會列出渲染程式包含的執行緒，比如：
GUI渲染執行緒JS引擎執行緒- 事件觸發執行緒
- 定時觸發器執行緒
HTTP請求執行緒
等
但是，我們以百度的搜尋頁舉例，開啟Performance皮膚開啟錄製：
上圖錄制結果中：
Chrome_ChildIOThread對應IO執行緒的任務記錄，使用者輸入、網路、裝置相關事件都與他相關Raster記錄光柵化執行緒池任務、GPU記錄GPU合成點陣圖的任務、Compositor記錄合成執行緒的任務執行，以上三者都與瀏覽器渲染相關Main記錄渲染程式的主執行緒中的任務
從這個角度看，瀏覽器實際的執行緒情況與那些GUI執行緒相關的文章描述的並不相同。
主執行緒的任務
接下來，讓我們進入Main。紅線框內長短不一的灰色塊，就是主執行緒中執行的任務。
注意看紅框內的綠色塊FP，代表First Paint（首次繪製）：
那麼在首次繪製前都要執行什麼任務呢？可以看到主要有3個Task（任務）：
第一個任務是請求HTML資料：
Parse HTML
當請求回HTML位元組流後，開始第二個任務，將HTML位元組流解析為DOM，這個任務的名字就是圖中的藍色塊Parse HTML：
注意其中有些執行時長不一的Evaluate Script，這些是解析DOM樹過程中遇到的JS程式碼。
從DOM樹中可以看到這些阻塞DOM樹生成的JS指令碼：
他們的存在顯著拉長了Parse HTML的用時。
Recaculate Style
解析完DOM樹（藍色Parse HTML）後，下一個任務是紫色Recaculate Style：
他負責將HTML中的CSS樣式（外聯、內聯）輸出為styleSheets，styleSheets有兩個作用：
- 可以與
DOM樹結合為頁面帶來樣式 JS可以操作styleSheets改變頁面樣式
我們可以從控制檯列印document.styleSheets直觀感受他的存在：
Layout
有了DOM樹與styleSheets，接下來需要為檢視中可見部分生成一棵樹（比如display: none部分就不需要在這棵樹中顯示）。
這個任務是紫色Layout：
Update Layer Tree
使用者看到的頁面實際是由多層頁面重疊後的結果，開發者可以用很多手段（比如z-index）改變某部分的層級。
比如滾動條就會形成自己獨立的層級：
既然是多層結構，那麼就需要更新每層的資訊，這個任務是紫色的Update Layer Tree：
Paint
我們可以發現，在FP之前，Update Layer Tree之後只剩下Paint這一任務了：
從字面意義講，這就是繪製麼？並不是。
Paint的任務是整理每一層頁面的繪製資訊，構成繪製列表，這些資料會交給合成執行緒負責後續繪製操作。
可以發現，具體的繪製操作是交由合成執行緒完成，他與JS所線上程（主執行緒）並不是互斥的。
JS為啥阻塞渲染
我們現在知道，JS執行與Paint任務都發生在主執行緒。
渲染被阻塞的原因很明顯：因為Paint任務沒有及時執行，即繪製列表沒有及時提交給合成執行緒。
之所以沒有及時執行，可能是因為JS執行時間過長，導致這一幀沒有時間執行Paint。
比如，我們開啟B站，記錄下主執行緒的任務。
可以看到，有個JS執行時長達到231.88ms，超過了一幀的時間，在此期間主執行緒就沒時間執行Paint了：
總結
JS之所以阻塞渲染，是因為JS執行與渲染相關任務都在爭奪主執行緒有限的資源。
當JS執行時間過長，渲染相關任務就沒時間執行了。