Web Performance

如何閱讀 Lighthouse 報告而不慌張

一份實用指南，幫助你理解效能稽核中真正重要的事，以及哪些可以安全忽略

The Wux Webtools Team The Wux Webtools Team 7 分鐘閱讀 AI輔助，人類審核
Stylized lighthouse beam illuminating a clear path through fog, representing clarity in performance diagnostics
目錄
  1. 第一條規則：你的分數不等於你的網站
  2. 先看什麼：Core Web Vitals
  3. Opportunities 與 Diagnostics：知道差異
  4. 通常可以忽略的稽核
  5. 當一切都是紅色時該怎麼辦
  6. Lab data vs. field data：現實檢查
  7. 何時重新執行 Lighthouse
  8. 幫助你處理 Lighthouse 發現的工具
  9. 重點整理
  10. FAQ
  11. Sources

第一條規則：你的分數不等於你的網站

第一次打開 Lighthouse 報告時，你會看到一整面數字、以顏色標示的方塊，以及一堆你從未聽過的警告。自然反應通常是慌張。分數是紅色的。有十七項稽核失敗。網站肯定壞了吧？

很可能不是。Lighthouse 是診斷工具，不是成績單。分數是在實驗室條件下執行的合成基準測試——通常會使用受限的連線，模擬一支 2017 年的中階手機。它告訴你的是網站在那個特定情境下的表現，而不是真實使用者在現實環境中的體驗。

這點很重要，因為多數團隊會盯著分數看，卻忽略了脈絡。對一個有即時資料的複雜 web app 來說，65 分可能還可以。95 分也可能仍然提供糟糕的體驗，如果最佳化的是錯的地方。分數是調查的起點，不是成功指標。

先看什麼：Core Web Vitals

先跳過整體效能分數。往下捲到 Metrics 區塊，查看三個數字：Largest Contentful Paint (LCP)、Cumulative Layout Shift (CLS)，以及 Interaction to Next Paint (INP)。這些是 Core Web Vitals，也是 Google 唯一用作排名訊號的效能指標。

  • LCP 衡量最大可見元素需要多久才會渲染出來。目標：低於 2.5 秒。如果超過 4 秒，代表使用者等太久才看得到有意義的內容。
  • CLS 衡量視覺穩定性——頁面載入時跳動的程度。目標：低於 0.1。如果超過 0.25，使用者可能會因為按鈕移動而誤點錯誤的項目。
  • INP 衡量回應速度——頁面對點擊、輕觸與按鍵輸入的反應有多快。目標：低於 200ms。如果超過 500ms，網站會讓人感覺遲鈍。

這三個指標與實際的使用者挫折感高度相關。在擔心其他任何事情之前，先修正它們。

Opportunities 與 Diagnostics：知道差異

Lighthouse 會把發現分成兩類：Opportunities 與 Diagnostics。Opportunities 依預估可節省時間排序。Diagnostics 則是額外脈絡——有些可能是問題，有些可能不是。

從 Opportunities 開始。如果 Lighthouse 說「消除阻礙轉譯的資源」可以節省 1.2 秒，那就是具體的收益。如果它說「減少未使用的 JavaScript」可以節省 0.1 秒，那大概不值得為此重構。

Diagnostics 比較棘手。「避免過大的 DOM 大小」聽起來很糟，但如果你的 CLS 沒問題、INP 也很快，一個大型 DOM 可能沒有傷害任何人。Diagnostics 是線索，不是命令。調查那些與你實際指標相符的項目。

通常可以忽略的稽核

有些 Lighthouse 警告帶有歷史包袱，或是過於激進。以下是最常造成不必要恐慌的項目：

  • 「未使用 passive listeners 以改善捲動效能」 — 這是一種微幅最佳化，通常很少真正改變結果。除非你有捲動卡頓的證據，否則可以跳過。
  • 「圖片元素沒有明確的 width 與 height」 — 這對 CLS 很重要，但前提是圖片正在造成版面位移。如果你的 CLS 已經很好，不必為了通過稽核而重構。
  • 「使用次世代格式提供圖片」 — 是的，WebP 和 AVIF 比較小。但如果你的圖片已經最佳化，且 LCP 很快，這是加分項，不是危機。
  • 「避免過大的網路酬載」 — Lighthouse 會標記任何超過 1.6 MB 的內容。但一個載入很快的 2 MB 頁面，勝過一個阻擋轉譯的 500 KB 頁面。重點不只是總量，而是位元組被傳遞的方式。

當一切都是紅色時該怎麼辦

如果你的 Lighthouse 分數低於 50，而且多數稽核都失敗，你很可能正在面對以下三種根本原因之一：

  1. 未最佳化的字型。 Web fonts 仍然是多數網站最容易取得的效能改善。檢查你是否載入了六種字重，實際上卻只用到兩種；或是仍在傳送 WOFF 檔案，而不是 WOFF2。
  2. 阻礙轉譯的 CSS 與 JavaScript。 如果你的 First Contentful Paint (FCP) 超過 3 秒，代表有東西阻止瀏覽器繪製畫面。檢查 <head> 中是否有大型 CSS 檔案或同步 scripts。
  3. 過大的圖片。 如果你的 LCP 元素是一張圖片，而且它有 4 MB，那就是問題所在。壓縮它、對首屏以下圖片使用 lazy-load，並使用響應式圖片語法。

修正其中一項後，重新執行 Lighthouse。你經常會看到分數跳升 20–30 分。接著再處理下一項。

Lab data vs. field data：現實檢查

Lighthouse 在實驗室中執行。它會模擬較慢的連線與較慢的裝置，但無法模擬真實使用者行為——人們如何捲動、點擊什麼、是否使用不穩定的 Wi-Fi。

若要做現實檢查，請將 Lighthouse 結果與 Chrome User Experience Report (CrUX) 的 field data 比較。CrUX 會顯示過去 28 天真實 Chrome 使用者如何體驗你的網站。如果 Lighthouse 顯示你的 LCP 是 4 秒，但 CrUX 顯示 2 秒，請相信 CrUX。如果兩者都很差，那你就有真正的問題。

你可以在 PageSpeed Insights（Lighthouse 的網頁版）或 Google Search Console 的「Core Web Vitals」底下找到 CrUX 資料。如果結果不一致，就調查原因。也許你的真實使用者使用較快的網路。也許 Lighthouse 正在測試一個未最佳化的開發版本。

何時重新執行 Lighthouse

Lighthouse 有雜訊。連續執行三次，你會得到三個不同分數，即使是在同一個頁面上。這是因為效能本來就會變動——背景程序、網路抖動與瀏覽器啟發式規則都會影響結果。

若要取得穩定的基準，請在停用所有擴充功能的 incognito mode 中執行 Lighthouse，或使用 CLI 搭配 --preset=desktop flag 取得更一致的結果。執行三次並取平均分數。如果你看到大幅波動（超過 10 分），表示還有其他問題——也許伺服器很慢，或頁面每次都載入不同資源。

每次做出重大變更後，都重新執行 Lighthouse。部署新的字型策略？檢查 LCP。對圖片使用 lazy-load？檢查 CLS。加入第三方 script？檢查 INP。效能不是一次性的修正；它是一個你需要守住的預算。

幫助你處理 Lighthouse 發現的工具

Lighthouse 會告訴你什麼很慢。它不一定會告訴你如何修正。為此，你需要額外工具：

  • WebPageTest 提供頁面載入的 filmstrip 檢視，一格一格呈現。這對診斷 LCP 與 CLS 問題很關鍵。
  • Chrome DevTools Performance panel 會精確顯示是哪段 JavaScript 阻塞了主執行緒。用它找出 INP 分數不佳的來源。
  • 圖片壓縮工具 讓你直接在瀏覽器中最佳化圖片，比上傳到第三方服務更快也更私密。Client-side image processing 是隱私上的優勢，因為你的圖片永遠不會離開你的電腦。

Lighthouse 是起點。這些工具幫助你完成剩下的工作。

重點整理

  • 你的 Lighthouse 分數是實驗室基準，不是真實世界使用者體驗的衡量。在慌張之前，先把它與 CrUX 的 field data 比較。
  • 先專注於 Core Web Vitals (LCP, CLS, INP)。這些是與使用者挫折感和 SEO 影響相關的指標。
  • 依預估可節省時間來排序 Opportunities。忽略那些與你實際效能問題不一致的 Diagnostics。
  • 有些稽核——例如 passive listeners 或次世代圖片格式——屬於微幅最佳化。先修正大的問題。
  • 執行 Lighthouse 三次並取平均結果。效能會變動，單次執行可能具有誤導性。

FAQ

Q: 為什麼每次執行 Lighthouse，我的分數都會變？
A: Lighthouse 會在可變條件下衡量效能——網路速度、CPU 負載與瀏覽器啟發式規則都會影響結果。請在 incognito mode 中執行三次，並取平均分數，以取得更穩定的基準。

Q: 我應該先最佳化 mobile 還是 desktop？
A: Mobile。Lighthouse 預設使用 mobile 模擬，因為大多數網路流量來自 mobile，而且 mobile devices 較慢。如果你的 mobile 分數很好，desktop 分數通常也會沒問題。

Q: 我的 Lighthouse 分數是 95，但網站感覺仍然很慢。哪裡出問題了？
A: Lighthouse 衡量的是頁面載入，而不是載入後的互動性。檢查你的 INP 分數，並使用 Chrome DevTools Performance panel 分析使用者點擊或捲動時發生了什麼。你可能有 Lighthouse 沒有捕捉到的 JavaScript 問題。

Q: 我需要完美的 100 分嗎？
A: 不需要。90+ 分已經很優秀。追求 100 分通常意味著最佳化一些對使用者不重要的事。專注於真實指標——LCP、CLS、INP——並忽略分數。

Q: 如果我使用很多第三方 scripts，可以相信 Lighthouse 嗎？
A: Lighthouse 會將第三方 scripts 標記為問題，但它不一定能分辨哪些是必要、哪些是不必要的。使用「避免過大的網路酬載」與「減少 JavaScript 執行時間」稽核找出最嚴重的來源，然後再決定是否值得保留。

Sources

Flowchart for reading a Lighthouse report: ignore score first, check LCP CLS INP, review Opportunities by time savings, then use Diagnostics as context
InfographicHow to triage a Lighthouse report — A simple order of operations turns a scary report into a short prioritized checklist
Two-column comparison of Lighthouse items to prioritize versus warnings that can often wait, with examples and numeric thresholds
InfographicLighthouse signals: fix now vs usually ignore — Not every red warning deserves engineering time
Side-by-side diagram comparing Lighthouse lab data and CrUX field data, including 28-day real-user window and example LCP mismatch
InfographicLab data vs field data at a glance — Use lab data to diagnose and field data to confirm what users really feel

常見問題

為什麼每次執行 Lighthouse，我的分數都會變？
Lighthouse 會在可變條件下衡量效能——網路速度、CPU 負載與瀏覽器啟發式規則都會影響結果。請在 incognito mode 中執行三次，並取平均分數，以取得更穩定的基準。
我應該先最佳化 mobile 還是 desktop？
Mobile。Lighthouse 預設使用 mobile 模擬，因為大多數網路流量來自 mobile，而且 mobile devices 較慢。如果你的 mobile 分數很好，desktop 分數通常也會沒問題。
我的 Lighthouse 分數是 95，但網站感覺仍然很慢。哪裡出問題了？
Lighthouse 衡量的是頁面載入，而不是載入後的互動性。檢查你的 INP 分數，並使用 Chrome DevTools Performance panel 分析使用者點擊或捲動時發生了什麼。你可能有 Lighthouse 沒有捕捉到的 JavaScript 問題。
我需要完美的 100 分嗎？
不需要。90+ 分已經很優秀。追求 100 分通常意味著最佳化一些對使用者不重要的事。專注於真實指標——LCP、CLS、INP——並忽略分數。
如果我使用很多第三方 scripts，可以相信 Lighthouse 嗎？
Lighthouse 會將第三方 scripts 標記為問題，但它不一定能分辨哪些是必要、哪些是不必要的。使用「避免過大的網路酬載」與「減少 JavaScript 執行時間」稽核找出最嚴重的來源，然後再決定是否值得保留。

來源與進一步閱讀

  1. Lighthouse performance scoring — Google Developers
  2. Core Web Vitals — web.dev
  3. Chrome User Experience Report — Google Developers
  4. WebPageTest Documentation — WebPageTest.org
#lighthouse #core-web-vitals #beginners #performance #web-performance
關於作者
The Wux Webtools Team

最後更新:

繼續閱讀