LEARN · ARTICLE
Lighthouse 分數怎麼看：權重、跳動與該盯的數字
作者：Rock Lee 實測日期：2026-11-09（Asia/Taipei）
為什麼寫這篇
我們每次上線新頁面都會跑 Lighthouse。今天下午驗收時，同一個頁面連跑 3 次，分數是 93、94、80。如果只跑一次又剛好遇到 80，很可能會以為頁面出了問題，開始亂改。
這篇用我們剛上線的教學頁實測，把報告上幾個最常被問的問題講清楚：效能分數怎麼算、為什麼會浮動、哪些數字才值得花時間處理。怎麼部署預覽站和跑 Lighthouse，可以先看本系列 Vercel 預覽那篇；這篇專講「怎麼看懂結果」。
實測環境
| 項目 | 內容 |
|---|---|
| 受測頁面 | https://rocki.org/tw/learn/llms-txt-agent-block（正式站） |
| 工具 | Lighthouse 13.6.0（npx 執行），Headless Chrome |
| 次數 | 手機 3 次、桌機 1 次，2026-11-09 18:20–18:21（UTC+8） |
| 手機模擬 | 畫面 412×823、往返延遲 150 ms、下載 1638.4 Kbps、CPU 減速 4 倍、模擬節流（simulate） |
| 對照 | 同頁在預覽站 17:23 的 3 次紀錄 |
步驟
1. 先看四個圓圈：只有「效能」會常常跳
報告最上面四個圓圈：效能、無障礙、最佳做法、SEO。今天手機第一次跑出 94、96、100、100。
顏色的意思來自官方說明：0–49 紅色、50–89 橘色、90–100 綠色。
手機 3 次的效能分數是 94、93、93，另外三項 3 次都一樣（96、100、100）。後三項是「有沒有做到某件事」的檢查，跑幾次結果都差不多；效能是計時，網路和電腦一忙就會變。
2. 往下看五個指標，分數就是它們的加權平均
效能分數不是單一數字量出來的，而是五個指標各自換算成 0–100 分，再加權平均。
| 指標 | 白話 | 實測值 | 該項分數 | 權重 |
|---|---|---|---|---|
| FCP 首次內容繪製 | 第一個字或圖出現 | 1.8 秒 | 89 | 10% |
| LCP 最大內容繪製 | 最大那塊內容出現 | 3.0 秒 | 79 | 25% |
| TBT 總阻塞時間 | 主執行緒被卡住多久 | 0 毫秒 | 100 | 30% |
| CLS 累計版面位移 | 畫面有沒有跳動 | 0 | 100 | 25% |
| SI 速度指數 | 畫面多快填滿 | 1.8 秒 | 100 | 10% |
自己算一次：89×0.10 + 79×0.25 + 100×0.30 + 100×0.25 + 100×0.10 = 93.65，四捨五入是 94，和報告一致。
從這張表可以看出：這頁扣分幾乎都在 LCP。TBT 和 CLS 已經滿分，再去拆 JavaScript 或調版面，分數也不會再高。
3. 找出 LCP 是哪個元素
報告的 LCP 項目會指出「最大內容」是哪個元素。這頁是文章頂端的封面圖。
報告也列出三項檢查都通過：圖片有設定 fetchpriority=high、在 HTML 裡一開始就找得到、沒有用 loading=lazy。
這三項都做了，手機模擬仍是 3.0 秒，主要是因為模擬的是慢速手機網路（每秒約 1.6 Mbps）。若還要再壓，可以試的方向是讓封面圖檔案更小（見本系列 WebP 那篇），載入設定已經沒有可改的了。
4. 同一頁跑 3 次，取中位數
今天正式站手機 3 次：94、93、93，每次大約 10–11 秒跑完。
下午在預覽站跑同一頁，則出現一次 80：
| 次數 | 效能 | FCP | LCP | SI |
|---|---|---|---|---|
| 1 | 93 | 1.8 秒 | 3.1 秒 | 1.8 秒 |
| 2 | 94 | 1.8 秒 | 3.0 秒 | 1.8 秒 |
| 3 | 80 | 3.1 秒 | 4.1 秒 | 3.6 秒 |
第 3 次是 FCP、LCP、SI 三個「跟時間有關」的指標同時變慢，頁面本身沒改。官方列出的浮動原因包括：A/B 測試或廣告變動、網路路由、不同裝置、瀏覽器擴充功能、防毒軟體。我們無法確定那次是哪一個，但三個指標一起慢，比較像當下網路或機器的狀況。
我們的做法是跑 3 次、取中位數（80、93、94 取 93）。單次的低分先別急著改。
5. 手機和桌機分開看
桌機跑一次是 99 分，FCP 0.6 秒、LCP 0.9 秒。
官方文件說明，從第 6 版開始桌機有自己的計分曲線，所以手機和桌機的分數不能直接比。手機是在模擬慢網路和慢 CPU 下量的，這頁手機 93、桌機 99；要改善時我們以手機為主。
6. 別只看效能：無障礙那 4 分在哪
無障礙 96 分，報告點出的是「文字和背景顏色對比不足」，共 20 個元素，主要是文章上方的小標籤和發布、更新日期。
這類項目和效能不同，不會因為重跑而改變；改一次顏色就能解決，反而比較值得排進待辦。
結果
- 這頁正式站手機效能 94／93／93（中位數 93），桌機 99；無障礙 96、最佳做法 100、SEO 100。
- 手機扣分幾乎都在 LCP（3.0 秒，該項 79 分）。LCP 元素是封面圖，三項載入設定都已通過。
- 預覽站曾出現一次 80，三個時間指標同時變慢；取 3 次中位數就不會被它誤導。
- 下一步值得做的是修顏色對比（固定扣分），而不是追那幾分浮動。
另外要知道：Lighthouse 是「實驗室數據」。官方 web.dev 寫得很清楚，Core Web Vitals 的標準（LCP 2.5 秒、INP 200 毫秒、CLS 0.1）是看真實使用者的第 75 百分位；Lighthouse 沒有使用者互動，量不到 INP，只能用 TBT 替代。實驗室分數好，不等於真實使用者體驗一定好。
踩坑紀錄
- PageSpeed Insights API 不帶金鑰會被擋。 我們想用 API 抓真實使用者數據，不帶金鑰直接呼叫，18:27 回了 HTTP 429「RESOURCE_EXHAUSTED」，訊息說超過每日查詢配額。要穩定使用得自己申請 API 金鑰。
- 網頁版的 PageSpeed Insights 用無頭瀏覽器開，結果顯示無法解析。 所以這篇沒有放真實使用者數據，只談實驗室分數。
- 高分區每一分都很難拿。 官方說明 99 到 100 需要的改善幅度，大約等於 90 到 94。已經 90 以上時，與其追分數，不如先處理會固定扣分的項目。
常見問題
Q1：分數多少才算及格？ 官方的顏色分級是 90 以上綠色、50–89 橘色、49 以下紅色。但這是實驗室分數，Google 看真實使用者體驗時用的是 Core Web Vitals 的第 75 百分位。
Q2：為什麼我在自己電腦跑的分數和別人不一樣？ 官方列出的浮動原因包括裝置、網路路由、瀏覽器擴充功能、防毒軟體、頁面上的廣告或 A/B 測試。我們的做法是同一台機器固定跑 3 次、取中位數，只和自己的歷史比。
Q3：「機會」和「診斷」裡的建議要全部照做嗎？ 不用。官方說明這兩區的建議不直接計入分數，分數只看五個指標。先看哪個指標扣分最多，再挑相關的建議做。
Q4：Lighthouse 會影響 Google 排名嗎？ 這篇引用的兩份官方文件（Lighthouse 計分說明、web.dev 的 Web Vitals）都沒有談排名。web.dev 說明的是 Core Web Vitals 用真實使用者數據判斷，Lighthouse 屬於實驗室工具，適合在上線前抓問題。
看實作成果
對應示範：麥窗烘焙坊速度優化（虛構或自製，非客戶案件）。
複製這段給你的 AI agent
目標：幫我用 Lighthouse 量測一個網頁，並用白話解釋分數，不要修改任何網站檔案。 前提與禁止事項： - 只量我給的網址。用 npx 執行 Lighthouse（記下版本號），不要全域安裝、不要部署、不要改程式碼。 - 不要申請或要求任何 API 金鑰；PageSpeed Insights API 若回 429，記錄下來即可，不要重試轟炸。 - 報告裡不要貼出任何金鑰、帳號或專案編號。 步驟： 1. 手機模式連跑 3 次、桌機 1 次，輸出 JSON 和 HTML，記錄每次的時間。 2. 列出每次的四項分數，以及 FCP、LCP、TBT、CLS、SI 的數值和各自分數。 3. 從 JSON 讀出五個指標的權重，用第 1 次的分數手算加權平均，確認和報告一致。 4. 指出 LCP 元素是什麼，以及報告對它的載入檢查結果。 5. 若 3 次分數差 5 分以上，列出是哪幾個指標造成的，並說明以中位數為準。 6. 列出無障礙、最佳做法、SEO 沒拿滿分的項目與受影響元素數量。 驗收：一張表列出 4 次結果；手算分數與報告差不超過 1；結論只建議 1～3 件最值得做的事，每件都對應到報告裡的具體項目。