Lighthouse CLI 前端效能診斷流程

方法論 2026/8/24

Lighthouse CLI 前端效能診斷流程

這是 [[WP-CLI 效能診斷流程]] 第五步「前台 Lighthouse 檢查」的完整展開版。

適用場景

網站首屏慢，但伺服器回應正常（TTFB 低）
需要把「感覺很慢」轉換成「改哪一支檔案的哪一行」
想把效能掃描排進 CI 或定期監測

不適用場景

瓶頸在資料庫、外掛執行或伺服器層（改走 [[WP-CLI 效能診斷流程]]）
沒有 Node.js 環境（改用 PageSpeed Insights，但拿不到可解析的 JSON）
要驗收真實使用者體驗（lab data 無法取代 CrUX 的 field data）

步驟

第一步：掃描

npm install -g lighthouse
lighthouse https://www.example.com \
  --output=html --output=json \
  --output-path=./report \
  --form-factor=mobile --screenEmulation.mobile=true \
  --chrome-flags="--headless"

從自己的電腦掃公開網址，不要從主機掃 localhost（會少掉 DNS、CDN、傳輸這一段）
預設跑 mobile，因為 Google 以行動裝置優先建立索引
全程唯讀，掃正式站安全，避開流量尖峰即可

第二步：判讀（載入還是執行）

先看三個數字決定往哪走：

訊號	判讀
TBT 高	JavaScript 卡住主執行緒，往 JS 執行方向查
CLS 高	版面位移，往圖片尺寸、字型切換、廣告插入方向查
TBT 與 CLS 都是 0、FCP／LCP 卻很慢	瓶頸在「載入」，往網路請求查
Root document 回應時間高	瓶頸在伺服器端，改走 WP-CLI 那條路

第三步：定位

解析 JSON 的 opportunities，找可省秒數最大的項目，再對照最大網路請求清單，抓出具體檔案名稱與大小。

第四步：對應

把那個檔案回溯到佈景主題或外掛的某一行程式碼（本案是 functions.php 的字型載入）。這一步是整套流程的產出，前面三步都只是為了走到這裡。

第五步：修復（由影響大到小）

把渲染阻塞資源移出關鍵路徑：media="print" + onload，加 <noscript> fallback
補齊 preconnect（fonts.googleapis.com 與 fonts.gstatic.com 兩個都要）
砍掉 CSS 未引用的字重：先把每個 font-weight 對應回 font-family 再動手，避免砍到正在用的
圖片轉 next-gen 格式（WebP）

第六步：驗證

清掉 CDN 快取後重掃，比對前後數值。留意改善會帶副作用（本案 CLS 由 0 升到 0.054），要一起記錄。

典型成效（單一案例）

指標	修改前	修改後
Performance	55	84
FCP	13.8 s	1.3 s
LCP	17.4 s	4.3 s
Speed Index	13.8 s	2.2 s

關聯概念

[[關鍵渲染路徑]]
[[WordPress 效能最佳化]]
[[除錯排查方法論]]
[[WP-CLI 效能診斷流程]]