Lighthouse 使用方法：三種分析模式、分數解讀與常見誤判

三種啟動 Lighthouse 的方式

Lighthouse 使用方法有三種：Chrome DevTools 內建面板、獨立 Chrome 擴充功能、以及 Node.js CLI。大多數工程師日常用 DevTools 就夠了，但了解三種方式的差異，之後遇到特殊情況才不會手忙腳亂。

Chrome DevTools 內建（日常首選）

這是最推薦的方式。DevTools 內建的 Lighthouse 面板設定選項最完整，而且可以直接連接到被你偵錯的頁面，包含需要登入才能看到的頁面。

1. 打開 Chrome，前往目標頁面
2. 按 F12（Windows）或 Cmd+Opt+I（Mac）開啟 DevTools
3. 點擊頂端列表中的 Lighthouse 分頁（可能被收進「更多工具」選單裡）
4. 選擇裝置（Mobile / Desktop）和要稽核的類別
5. 點擊 Analyze page load

一個容易被忽略的細節：建議在無痕模式下開啟目標頁面再跑 Lighthouse，因為擴充功能會影響頁面的 JavaScript 執行，進而拉高 TBT 分數。裝了五個擴充套件的 Chrome，跑出來的分數和乾淨環境可能差 10-15 分。

更多 CLI 安裝細節和完整 API 參數，可參考 Lighthouse 官方說明文件。另外，PageSpeed Insights 和 Lighthouse 之間的關係常讓人混淆，兩者用的是同一套引擎，差別在資料來源，這部分在 PageSpeed Insights 和 Lighthouse 的差別 裡有詳細說明。

Lighthouse Chrome 擴充功能

適合臨時要快速看某個頁面的大致狀況，不需要打開 DevTools。安裝後，在瀏覽器右上角會出現 Lighthouse 圖示，點一下就可以跑。

缺點是設定選項比 DevTools 少，無法選擇分析模式，也無法調整節流設定（詳細的 Simulated vs DevTools 節流設定差異另有一篇說明）。拿來做初步篩查還行，要深入診斷還是回 DevTools。想深入了解 Performance 面板的 trace 判讀方式，可以看 Chrome DevTools Performance 面板怎麼看。

Node.js CLI（自動化和 CI 用途）

安裝方式：

npm install -g lighthouse
lighthouse https://example.com --output html --output-path ./report.html

為什麼 CLI 跑出來的分數跟 DevTools 不一樣？原因在於 CLI 用的是 Chromium headless 模式，本機記憶體和 CPU 狀態會更直接影響結果，而 DevTools 有一層軟體節流模擬隔離。這個差異在做 CI/CD 整合時特別重要，下面的章節會再說。

三種分析模式：選錯了，問題找不到

這是 Lighthouse 最被忽視的功能。Lighthouse 的三種分析模式（Navigation、Timespan、Snapshot）設計來回答不同問題，混用會讓你看到一份完全沒有診斷價值的報表。

參考 Chrome DevTools Lighthouse 面板官方文件 對三種模式的詳細說明。

Navigation 模式：從頭量起（預設）

從頁面導航開始，量到頁面載入穩定為止。這是你大部分時間用的模式。

量測的指標：LCP、CLS、TBT、FCP、Speed Index。如果你想知道首次載入速度為什麼慢、LCP 元素是什麼、哪個資源在阻塞渲染，就用這個。

限制：頁面載入後的狀態它看不到。SPA 路由切換後的 CLS、使用者點了按鈕後觸發的 INP，Navigation 模式全部錯過。

Timespan 模式：錄製一段互動

你手動開始、操作頁面、手動結束，Lighthouse 記錄這段期間的效能狀況。適合用來分析：

• SPA 路由切換後的頁面狀態
• 使用者填寫表單、滾動頁面時的 INP 和 CLS
• 互動後載入的動態內容造成的版面位移

注意：Timespan 模式不產生 Performance 總分，因為沒有「完整頁面載入」的概念。它給的是這段互動期間各指標的測量值，不是一個加權分數。

Snapshot 模式：分析當前 DOM 狀態

不做任何載入或錄製，只掃描頁面當前的 DOM 狀態。適合用在：登入後才看得到的頁面、需要特定 UI 狀態才能稽核的 Accessibility 問題。

不量測任何載入效能指標，主要用途是 Accessibility 和 Best Practices 檢查。

模式	適合情境	產生 Performance 分數	量測 INP
Navigation	首次載入效能診斷	是	否
Timespan	互動期間效能診斷	否	是
Snapshot	登入後頁面的 Accessibility 稽核	否	否

跑報表前要先設定好的東西

很多工程師抱怨「Lighthouse 分數每次都不一樣，我到底該信哪個」。這個問題有一半是設定沒調好造成的，另一半是沒有理解 Lab Data 的本質。

節流（Throttling）設定：預設值不等於你的使用者

Lighthouse 預設使用軟體模擬節流（Simulated Throttling），模擬 mid-tier Android 裝置加上 4G 連線。這個模擬不是在你的機器上跑慢速，而是用統計模型估算如果在那樣的環境下，載入時間會是多少。

問題在哪？模擬誤差。同一頁用 Simulated Throttling 和 Applied Throttling（真正降速你的網路和 CPU）跑，LCP 結果可能差 15-30%，因為模擬係數跟你本機的實際硬體有摩擦。

DevTools 裡還有另一個設定：CPU 節流係數（1x、4x、6x）。預設 4x 代表 Lighthouse 把你的 CPU 速度除以四來模擬低端裝置。如果你用 M2 MacBook Pro 跑 Lighthouse，4x 節流後的結果跟真實 mid-tier Android 仍然不一樣，因為你的基準 CPU 就比它快太多了。

建議做法：

• 日常診斷：用預設 Simulated Throttling，跑 3-5 次取中位數
• 要跟真實 field data 比較：切換到 Applied Throttling，更能重現使用者感受的環境
• CI/CD：固定用 Applied Throttling，確保環境一致性

Lab Data 的本質：Lighthouse 測的不是你的使用者

Lighthouse 跑的是合成環境（Synthetic Monitoring）。每次跑報表，Lighthouse 把頁面的資源請求在模擬環境中重放，用固定的模擬條件算出各項指標。這是實驗室環境，不是真實使用者的體驗。

這代表什麼？幾個實際影響：

• Lighthouse 每次都清快取重跑，但真實使用者第二次造訪有快取，LCP 比 Lighthouse 快很多
• 第三方資源（Google Analytics、FB Pixel）的回應速度依地理位置不同，模擬環境不能完整重現這個 latency
• Lighthouse 跑的頁面通常是台灣時間白天，CDN 節點不一定和使用者在同一個 edge

所以 Lighthouse 的正確用途是：找問題的方向，不是確認問題的嚴重程度。確認要靠 Field Data，也就是真實使用者的 CrUX 數據。怎麼查詢 CrUX 資料，可以參考 CrUX 真實使用者資料查詢 那篇的操作說明。

五個評估類別的分數怎麼看

Lighthouse 報表有五個類別：Performance、Accessibility、Best Practices、SEO、PWA。大多數工程師只看 Performance，但其他類別在某些情境下同樣重要。

Performance 分數的組成

Performance 分數不是某個單一指標，是五個指標的加權計算結果：

• First Contentful Paint (FCP)：10%
• Largest Contentful Paint (LCP)：25%
• Total Blocking Time (TBT)：30%
• Cumulative Layout Shift (CLS)：25%
• Speed Index：10%

加權最高的是 TBT（30%）和 LCP（25%），合計佔分數 55%。這兩個指標和使用者感知的「頁面多快可以互動」最直接相關，所以 Lighthouse 給了它們最高的權重。如果你想快速提分，先從影響這兩個指標的問題入手。

其他四個類別（Accessibility、Best Practices、SEO、PWA）的計算邏輯不同，它們是稽核項目的通過比率，不是加權分數組合。SEO 類別確認的是技術性 SEO 基礎（meta description 有沒有、robots.txt 設定有沒有問題），不等同於整體 SEO 排名能力，詳細說明可參考 Core Web Vitals 三大指標 的完整說明。

分數 90 不代表現場體驗好

這個認知偏差很常見。Lighthouse 跑出 90 分，不代表你的使用者有 90 分等級的體驗。

實際案例：有些頁面 Lighthouse 給 85-90 分，但 Google Search Console 的 Core Web Vitals 報告顯示 LCP 在「需要改善」區間（2.5s-4s）。原因前面說了：Lighthouse 用模擬環境清快取跑，現實使用者遇到的是有快取、有真實網路延遲、有各種第三方資源同時競爭頻寬的情況。

判斷方式：如果 Lighthouse 分數和 CrUX field data 有明顯落差，先相信 field data，用 Lighthouse 找原因。

從建議清單找出真正值得修的項目

Lighthouse 報表裡有兩種建議：Opportunities（機會）和 Diagnostics（診斷）。很多人把它們混在一起看，修了一堆 Diagnostics 但 Performance 分數幾乎沒動。

Opportunities vs Diagnostics

Opportunities 的特點是有估算的節省時間：「Serve images in modern formats, estimated savings: 1.2s」。這個時間估算是 Lighthouse 基於實際資源大小和傳輸速度算出來的，不精確但有參考價值。

Diagnostics 沒有這個數字，它們是「這裡有問題，但我沒辦法幫你估算修好後能省多少」類型的提示。例如 "Avoid large layout shifts" 告訴你有 CLS 問題，但修好後省幾秒它不知道。

策略建議：

1. 先掃 Opportunities，照估算節省時間由大到小排
2. 評估工程成本：「Properly size images」通常容易修；「Eliminate render-blocking resources」可能需要重構 critical CSS
3. Diagnostics 裡挑明確影響 LCP 或 TBT 的項目先修

修 LCP 相關問題的完整方法，在 LCP 優化指南 裡有逐步說明，包含 fetchpriority 設定和 preload 的正確用法。

參考 使用 Lighthouse 最佳化 Core Web Vitals 這篇，web.dev 列出了每個 CWV 指標對應的主要 Opportunities。

哪些建議先不要動

"Serve images in modern formats" 的估算有時候偏樂觀，因為它假設你的使用者瀏覽器全部支援 AVIF/WebP，但實際轉換後在某些情況下節省沒那麼多。

"Minify CSS" 和 "Minify JavaScript" 通常節省量很小（1-5ms），除非你的專案根本沒啟用 minification，否則排在最後修。

Diagnostics 裡的 "Document does not have a meta description" 影響的是 SEO 類別分數，不是 Performance 分數。如果你的目標是提升 Performance，先跳過這類。

讓分數可重現：跑亂數的根本原因

「我修了一個東西，分數反而掉了五分。」這句話我聽過不止一次。大部分情況不是你的修改出問題，是 Lighthouse 的測量本身就有變異性。

根本原因是 Lighthouse 用的是合成環境，而合成環境受本機資源狀態影響：CPU 有沒有在跑其他程序、Chrome 分頁數量、記憶體使用率、網路波動。這些變因不控制，同一頁跑五次可能出現 62、71、68、73、65 的分數。

讓分數更穩定的方法：

1. 無痕模式跑：清掉快取、禁用擴充功能、隔離環境
2. 關閉其他 Chrome 分頁：減少記憶體競爭
3. 至少跑 3-5 次，取中位數：不要相信單次結果，Google 官方也建議這樣做
4. 用 Lighthouse CI：在固定的 GitHub Actions / Netlify CI 環境跑，消除本機變因，是目前最可靠的方式

Lighthouse CI 的基本設定檔（lighthouserc.json）大概長這樣：

{
  "ci": {
    "collect": {
      "url": ["https://your-site.com/"],
      "numberOfRuns": 5
    },
    "assert": {
      "assertions": {
        "categories:performance": ["warn", { "minScore": 0.8 }],
        "categories:accessibility": ["error", { "minScore": 0.9 }]
      }
    }
  }
}

numberOfRuns: 5 讓 CI 自動跑 5 次取中位數，解決單次測量不穩定的問題。assert 區塊讓你設定效能門檻，分數掉到 80 以下就讓 CI 跑失敗，防止效能回歸悄悄進 production。

Lighthouse CI 的好處是每次跑的環境固定，分數的趨勢才有意義。如果你每次在自己的機器上跑，比較的是「這台 MacBook 今天心情好不好」，不是網站效能有沒有進步。

Lighthouse 看不到的問題

學會用 Lighthouse 很重要，但更重要的是知道它看不到什麼。把它當萬能診斷工具，遲早會被它的盲區坑到。

除了 Lighthouse 的盲區，另一個常被誤用的工具是Web Vitals Chrome Extension 的現況與 Chrome DevTools 替代工作流。

四個 Lighthouse 無法捕捉的問題：

• 瀏覽器快取的影響：Lighthouse 每次清快取重跑，但回訪使用者有快取，他們的 LCP 比 Lighthouse 量到的快很多。如果你的 Cache-Control 設定正確，真實使用者體驗遠比 Lighthouse 報表好看。
• 第三方資源的地理延遲：台灣使用者請求 Google Analytics 或 Hotjar 的時間，跟 Lighthouse 模擬環境請求的時間不同。某些情況下 third-party 腳本是 LCP 的瓶頸，但 Lighthouse 在模擬環境裡可能跑得很順。
• Long Session 的效能衰退：Lighthouse 只看首次載入那幾秒。使用者在頁面停留 20 分鐘後的記憶體洩漏、DOM 節點堆積造成的 INP 劣化，Lighthouse 完全看不到。這種問題只能用 Performance DevTools 的 Timeline 錄製長時間操作才能發現。
• 個人化和 A/B 測試狀態：Lighthouse 跑的是沒有登入狀態、沒有 A/B 測試分組的頁面。如果你的頁面對特定用戶群載入了額外的廣告模組或推薦系統，Lighthouse 看到的不是這些使用者的真實體驗。

Lighthouse 是實驗室儀器，用來找問題方向、驗證修改有沒有效果。真實使用者體驗要靠 CrUX Field Data 和 RUM（Real User Monitoring）確認。這兩種工具的角色不是競爭關係，而是互補關係。

常見問題

Lighthouse 可以分析需要登入的頁面嗎？

可以，但要用 DevTools 的 Snapshot 或 Navigation 模式，先在瀏覽器手動登入頁面，再開 DevTools 跑 Lighthouse。DevTools 模式可以存取當前已登入的 session，Chrome 擴充功能版本通常做不到這件事。如果是需要特定狀態（例如購物車有商品）才有意義的頁面，用 Snapshot 模式更合適。

為什麼 Lighthouse 分數跟 PageSpeed Insights 不一樣？

兩者用的引擎相同，但 PageSpeed Insights 跑的是 Google 的伺服器環境，你的 DevTools Lighthouse 跑的是你的本機環境。伺服器環境的 CPU 和網路設定是固定的，所以 PSI 結果通常比本機 DevTools 更穩定，也更接近 Lighthouse 分數的「基準值」。另外，PSI 還會同時顯示 CrUX 真實使用者數據，是它比單純跑 DevTools Lighthouse 更有用的地方。

Mobile 和 Desktop 模式的分數為什麼差那麼多？

主要是節流設定不同。Mobile 預設 4x CPU 節流加上模擬 4G 連線，Desktop 預設不做 CPU 節流、連線速度也快很多。如果你的 Desktop 分數 90，Mobile 40，問題通常在 JavaScript 執行時間太長（被 CPU 節流放大了）或圖片沒有針對行動裝置優化。

同一頁跑五次分數都不同，哪個算數？

取中位數，也就是把五個數字排序後取中間那個。不要用最高的（可能是本機資源剛好很空的時刻），也不要用最低的。如果五次的範圍超過 15 分，代表環境不穩定，先關閉其他分頁和擴充套件，在無痕模式重新跑。

Lighthouse 報表裡的 TBT 和 INP 是同一件事嗎？

不是，但有關係。TBT（Total Blocking Time）是 Lighthouse 在 Lab 環境量到的主線程阻塞時間，是 INP（Interaction to Next Paint）的實驗室代理指標。TBT 高通常代表 INP 也高，但 INP 更準確，因為它量的是真實使用者的互動延遲。Lighthouse Navigation 模式量 TBT，Timespan 模式才能量真實互動的 INP。

Lighthouse 的 SEO 稽核可靠嗎？

對技術性 SEO 基礎是可靠的：有沒有 meta description、robots.txt 有沒有封鎖爬蟲、有沒有 canonical 標籤、連結有沒有可爬取等。但 Lighthouse SEO 分數不等於 Google 排名。它不量測內容品質、E-E-A-T、反向連結，這些才是排名的主要因素。SEO 分數 100 只代表技術面沒有明顯問題，不代表會排名。

在本機開發環境跑 Lighthouse 結果準嗎？

基本上不準，別太依賴這個結果。本機開發環境沒有網路延遲、沒有 CDN、沒有真實的 DNS 查詢和 TLS 握手，Lighthouse 跑出來的分數幾乎都是 90 以上，因為這些延遲不存在。Lighthouse 應該跑在 staging 環境或生產環境，用接近真實使用情境的條件量測。

Lighthouse CI 和本機 DevTools 的結果為什麼不同？

Lighthouse CI 在固定的 CI 伺服器環境跑，CPU 和記憶體規格不同於你的本機，用的是 headless Chromium 而不是帶 GUI 的 Chrome，這些都會讓結果有差異。比較重要的是 Lighthouse CI 的一致性，每次跑的環境固定，分數趨勢有意義，而本機每次環境不一樣，趨勢不可靠。設定 Lighthouse CI 後，要以 CI 的數字為準，不要拿 CI 結果和本機 DevTools 結果比。

分數從 70 提到 90 難嗎？從 90 到 100 呢？

70 到 90 通常是可以做的：壓縮圖片、換 WebP/AVIF 格式、修掉明顯的 render-blocking 資源、加 preload LCP 圖片。大概幾天到兩週的工，視頁面複雜度而定。90 到 100 就難了，通常卡在 TBT，代表主線程有大型 JavaScript bundle 或 long tasks 要拆解，這個通常需要重構，成本高但 UX 效益明顯。很多情況下，停在 85-92 並不是壞事，這個區間的真實使用者體驗通常已經很好，繼續追分的工程成本不划算。

Lighthouse 能偵測到第三方腳本造成的效能問題嗎？

部分能，但不完整。Lighthouse 的 Diagnostics 裡有 "Reduce the impact of third-party code"，會列出第三方資源的 main thread blocking time。但如果第三方資源的 CDN 在真實環境下很慢（例如台灣使用者存取某個美國 CDN 節點），Lighthouse 在模擬環境不一定能重現這個延遲。要確認第三方腳本的真實影響，用 WebPageTest 的 Network Blocking 功能，或在 DevTools Network 面板手動 block 第三方資源再重新跑，效果更直接。