關鍵渲染路徑

概念

關鍵渲染路徑

定義

瀏覽器從收到 HTML 到畫出第一個像素之間，必須依序完成的那串工作。排在這條路徑上的資源（印在 <head> 的同步 CSS、同步 JS）會擋住繪製，稱為渲染阻塞資源；不在路徑上的資源可以邊載邊顯示。

改善首屏速度的核心手法通常不是「刪掉檔案」，而是「把檔案移出關鍵路徑」：總下載量可能一位元組都沒少，但瀏覽器不必等它就能開始畫，首屏時間就下降。

關鍵數據點（附來源）

  • 一支 232KB 的 Google Fonts CSS 印在 <head>，單獨造成 12.2 秒的渲染阻塞（lighthouse-cli-website-speed-diagnosis）
  • 同一個站的伺服器回應（Root document）只花 80ms，證明瓶頸與主機無關（同上）
  • 前 15 大網路請求中 12 個是字型檔；佈景主題一次載三套字型、七種字重（同上）
  • 改成 media="print" + onload 的非阻塞載入後，FCP 從 13.8s 降到 1.3s，快 91%（同上）
  • 補上 fonts.googleapis.com 的 preconnect 單獨再省 0.34 秒（同上）

前提與局限性

  • 非阻塞載入有代價：字型延後套用會造成切換位移，本案 CLS 從 0 升到 0.054。
  • media="print" + onload 的技巧依賴 JavaScript，需要 <noscript> fallback。
  • 中文字型是這個問題的放大器（單一字重數百 KB 到 MB），純英文站同樣的錯誤影響小一個數量級。
  • 移出關鍵路徑只改善首屏，不減少總傳輸量；頻寬受限的裝置仍要付下載成本。
  • 瓶頸修掉之後會移動：本案首屏解決後，下一個瓶頸變成未轉 WebP 的圖片（LCP 4.3s）。

衝突標記

無。與 [[WordPress 效能最佳化]] 的後端診斷路徑互補而非衝突，兩者靠 TBT／CLS／TTFB 三個數字分流。

關聯概念

  • [[WordPress 效能最佳化]]
  • [[除錯排查方法論]]
  • [[SEO 結構基礎]]
  • 方法論：[[Lighthouse CLI 前端效能診斷流程]]