關鍵渲染路徑 LCP CLS INP

Critical Rendering Path 是什麼：瀏覽器渲染的阻塞機制與優化優先順序

Critical Rendering Path（關鍵渲染路徑）決定瀏覽器從 HTML 到畫面出現的速度。從 DOM 構建到 Render Tree 說起，重點放在 render-blocking 原理、DevTools 診斷方式、HTTP/2 下策略的轉變。工程師視角，每個建議都附優先順序與改善幅度。

陳

陳柏翰

網站效能工程師

2026/4/20

Critical Rendering Path 是什麼：瀏覽器渲染的阻塞機制與優化優先順序

Critical Rendering Path 是什麼：從 HTML 到畫面的 8 個步驟

Critical Rendering Path（關鍵渲染路徑）是瀏覽器從收到第一個 byte 的 HTML，到畫面上出現第一個可見像素，中間必須完成的一連串工作。這條路徑上的任何資源，只要下載或執行拖慢了，FCP 和 LCP 就跟著往後延。。關於消除渲染阻塞資源的完整修復方法，可以參考渲染阻塞消除的完整實作方法。

瀏覽器的渲染流程按這個順序進行：

下載並解析 HTML，建立 DOM 樹
下載並解析所有 CSS，建立 CSSOM（CSS Object Model）
執行 render-blocking 的 JavaScript（如果有的話）
合併 DOM 與 CSSOM，建立 Render Tree（只包含可見節點）
計算每個節點的位置與大小：Layout（Reflow）
把每個節點繪製成像素：Paint（Rasterization）
將不同的繪製層合成最終畫面：Composite
顯示到螢幕：Display

Critical Rendering Path 8 個步驟水平時間軸：HTML DOM CSSOM Render Tree Layout Paint Composite Display — 瀏覽器渲染流程的 8 個步驟，從 HTML 下載到像素顯示在螢幕上的完整路徑

這 8 步裡，步驟 1 到 3 是最容易出問題的地方。外部 CSS 和特定位置的 JavaScript 會讓瀏覽器暫停渲染流程等待，這就是 web.dev 官方的 critical path 課程模組所說的 render-blocking 行為。

從 HTML 到像素的 8 個步驟

DOM 構建是串流式的，CSSOM 是阻塞式的，這個差異是 render-blocking 設計的根源。DOM 的建立瀏覽器邊下載 HTML 邊解析，不需要等整個文件完成。但 CSSOM 不一樣：CSS 解析必須完整，瀏覽器才能建立完整的 CSSOM 繼續往後走。

Render Tree 只包含頁面上實際可見的節點。`display: none` 的元素不在 Render Tree 裡；`visibility: hidden` 的元素在，因為它還佔位。這個差異對 Layout 的計算量有直接影響。

Layout（有時候也叫 Reflow）是計算成本最高的步驟之一。DOM 節點越多，Layout 要計算的工作量越大。有個常被引用的實測數據：同樣 10 萬行的 DOM，一般渲染約需 242ms，改用虛擬化（Virtualization）只需 2.4ms，差了 100 倍。這不是 CRP 本身的問題，但說明 Layout 的計算量跟 DOM 大小直接相關。

哪些資源會擋住這條路

Render-blocking 資源是指瀏覽器在處理它之前，拒絕繼續生成 Render Tree 的資源。主要是放在 `` 裡的外部 CSS 和沒有 `async`/`defer` 屬性的 `