PageSpeed Insights 怎麼看？從分數、Core Web Vitals 到修復順序的完整讀法

PageSpeed Insights 是什麼？先把它當成診斷入口，不是速度真相

PageSpeed Insights 是 Google 的網頁效能診斷工具，它會把真實使用者資料、Lighthouse 實驗室測試、Core Web Vitals 指標和改善建議放在同一份報表裡。它很好用，但不要把 PSI 分數直接翻譯成「網站真實速度」。我通常把它當作第一個診斷入口，先找方向，再用其他工具驗證瓶頸。

這個工具最容易被誤用的地方，是大家一打開就盯著 0 到 100 分。分數確實有參考價值，但它只是 Lighthouse 在固定條件下跑出來的 lab score。真正牽涉使用者體驗與 Google Core Web Vitals 判斷的，是報表上方的 field data，也就是 Chrome UX Report 裡的真實使用者資料。

如果你還沒熟悉三大指標，可以先看 Core Web Vitals 完全指南。如果你的問題是「為什麼同一頁每次跑分都不一樣」，那篇 PageSpeed Insights 分數差異會比本文更對題。這篇專注在跑完 PSI 之後，工程師應該照什麼順序讀報表。

Google 自己對 PSI 的定位也不是單純測速器，而是結合 Lighthouse 與 Chrome 使用者體驗資料的分析入口。你可以對照 PageSpeed Insights 官方工具，先記住一件事：工具給的是線索，不是結論。

跑完 PSI 後先看哪裡？我的順序是 field data 先於分數

跑完 PSI 後，我會照這個順序看：先確認 field data 是否存在，再看 Core Web Vitals 是否通過，接著才看 lab score，最後用 Opportunities 和 Diagnostics 找修復線索。這個順序可以避免你被紅色分數嚇到，結果先修了對真實使用者影響很小的項目。

我常用的順序是五步：

1. 先看這個 URL 有沒有 field data，沒有就看 Origin Summary。
2. 看 LCP、INP、CLS 哪一個沒有通過。
3. 看 lab data 裡哪個指標對應到同一個瓶頸。
4. 把 Opportunities 當成候選線索，不要照清單順序全修。
5. 改一個變因，重跑三次，記錄中位數。

這個流程的好處是，每一步都有明確目的。field data 回答「真實使用者有沒有痛」，Core Web Vitals 回答「痛在哪個指標」，lab data 回答「這次模擬看起來哪裡卡住」，Diagnostics 回答「下一步該打開哪個工具」。

讀報表順序	要回答的問題	下一步
Field data	真實使用者是否遇到效能問題	確認 URL data 或 Origin Summary
Core Web Vitals	LCP、INP、CLS 哪個沒過	把問題歸到載入、互動或版面位移
Lab data	這次模擬測試卡在哪裡	對照 Lighthouse trace 或 DevTools
Opportunities	哪些項目可能改善載入時間	挑會影響主要瓶頸的項目
Diagnostics	還有哪些除錯線索	用瀑布圖、Performance 面板或 RUM 驗證

Field data、Lab data 差在哪？一個看真實使用者，一個看模擬測試

Field data 來自真實 Chrome 使用者的體驗資料，lab data 則是 Lighthouse 在模擬環境中跑出的單次測試。前者適合判斷使用者實際感受，後者適合除錯；兩者不是互相取代，而是回答不同問題。

PSI 的 field data 主要來自 Chrome UX Report。它會用過去一段時間的真實使用者資料，顯示 LCP、INP、CLS 等指標的百分位狀態。Google 對 CrUX 的說明可以看 Chrome UX Report 官方文件，重點是它不是你剛剛按下分析按鈕才跑出來的資料。

Lab data 則比較像「在一台固定規格的測試機上重現一次」。它的優點是可重跑、可比較、可追問題。缺點是它不代表你所有使用者的裝置、網路和瀏覽器狀態。我的判斷很簡單：要判斷真實體驗，先看 field data；要找工程瓶頸，再看 lab data。

資料類型	來源	適合回答	限制
Field data	Chrome UX Report	真實使用者是否達標	低流量 URL 可能沒有資料
Lab data	Lighthouse 模擬測試	這次測試瓶頸在哪	受模擬條件與當下環境影響
Origin Summary	整個網域的 CrUX 資料	URL 資料不足時補判斷	會稀釋單頁問題

如果你需要查更細的 CrUX 資料，可以接著看 CrUX 數據查詢的五個入口。PSI 很適合起手，但當你要確認單頁、模板或流量分群時，CrUX API 或 BigQuery 會更精準。

PSI 分數代表什麼？0 到 100 分只能用來追蹤 lab 改動

PSI 的 0 到 100 分是 Lighthouse performance category 的加權結果，適合用來比較同一頁面在相近條件下的實驗室改動，不適合單獨判斷 SEO 成效或真實使用者體驗。把分數當方向可以，把分數當 KPI 會很痛。

Lighthouse performance score 會把多個 lab metric 加權，例如 LCP、CLS、Speed Index、TBT、FCP。權重會隨 Lighthouse 版本調整，所以你不能只記一套永久不變的公式。官方的計分說明在 Lighthouse performance scoring 文件，裡面也提醒分數會因環境因素波動。

我的使用方式是把分數當成 lab baseline。假設首頁 mobile PSI 是 54 分，做完 hero image preload 和 unused JS 拆分後變成 68 分，這代表 lab 條件下的瓶頸有改善。但如果 field data 的 LCP 仍然是 3.6s，代表真實使用者那邊還沒過關，不能只因為分數上升就收工。

Core Web Vitals 區塊怎麼讀？先看 LCP、INP、CLS 哪個沒過

Core Web Vitals 區塊要先看 LCP、INP、CLS 三個指標哪個沒有通過。LCP 多半指向載入瓶頸，INP 指向互動延遲，CLS 指向版面位移；先把指標對應到瓶頸類型，修復順序才不會亂掉。

Google 對 Core Web Vitals 的三大指標有明確門檻，LCP 通常要壓在 2.5 秒以下，INP 要壓在 200ms 以下，CLS 要低於 0.1。門檻本身可以對照 web.dev Core Web Vitals 說明，但實作時不要只背數字，要把數字對回頁面的瓶頸。

指標	代表問題	常見瓶頸	先查哪裡
LCP	最大內容元素太慢出現	TTFB、hero image、render blocking CSS、字體	LCP 元素、瀑布圖、preload
INP	互動回應太慢	Long task、事件處理器、第三方腳本、hydration	Performance 面板、main thread、long task
CLS	版面位移太大	圖片尺寸、廣告插入、字體置換、動態內容	Layout shift track、元素尺寸保留

如果 LCP 沒過，優先看 LCP 優化實戰。如果 INP 沒過，接著看 INP 優化指南。如果 CLS 沒過，先回到 CLS 意思與計算方式確認你看到的位移是不是使用者觸發造成的。

Opportunities 怎麼排優先順序？先修影響 LCP 和 INP 的項目

Opportunities 不是逐條完成的待辦清單，而是 Lighthouse 推測可能改善效能的候選線索。優先順序要看它是否影響 LCP、INP、CLS 或你的主要轉換頁，不要只看「可節省秒數」最大的那一列。

舉例來說，報表同時出現「Serve images in next-gen formats」和「Reduce unused JavaScript」。如果這頁的 LCP 元素是 hero image，而且圖片是 480KB JPEG，我會先處理圖片。如果這頁 INP 爆到 380ms，而且 unused JS 來自首頁互動前就執行的 bundle，我會先拆 JS。

PSI 建議	最可能影響	優先級判斷
Properly size images	LCP、總下載量	LCP 圖片命中時優先
Eliminate render-blocking resources	LCP、FCP	首屏 CSS 或同步 JS 阻塞時優先
Reduce unused JavaScript	INP、TBT	互動延遲或主執行緒過重時優先
Reduce initial server response time	TTFB、LCP	所有資源都被伺服器回應拖慢時優先

Diagnostics 怎麼讀？它通常不是答案，是找瓶頸的路標

Diagnostics 區塊提供的是除錯線索，例如主執行緒工作過重、DOM 太大、第三方程式碼拖慢互動或圖片缺少尺寸。它通常不是最後答案，而是提醒你下一步該打開 DevTools、瀑布圖或 RUM 數據去驗證。

我會把 Diagnostics 分成三類。第一類是可以直接修的，例如圖片沒有 width 和 height。第二類是需要 trace 的，例如 main-thread work 太高。第三類是需要商業判斷的，例如第三方腳本太重，因為那可能是廣告、客服或分析工具。

如果看到 JavaScript 相關診斷，通常會接到 JavaScript 效能優化 這條線。別急著刪套件，先看它是不是首屏必要、是不是可延遲、是不是能用 facade pattern 改成互動後才載入。

Mobile 和 Desktop 分數差很多怎麼辦？先看你的流量裝置，再看 mobile 瓶頸

Mobile 和 desktop 分數差很多很常見，因為 PSI 的測試條件、裝置能力、網路模擬和 viewport 都不同。若你的使用者主要來自手機，mobile 報表通常要優先處理；若你的轉換集中在桌機，也要同時看 field data 的裝置分布。

我不會因為 mobile 分數比 desktop 低 35 分就立刻判定網站壞掉。先看 field data 是否也顯示 mobile LCP、INP 或 CLS 沒過。如果 lab mobile 紅，但 field data mobile 是綠，可能只是測試環境比你的真實使用者更嚴格。反過來，如果 lab 綠但 field data 紅，就代表你在實驗室沒重現真實瓶頸。

判斷順序可以簡化成三句話：使用者在哪裡，就先看哪裡；field data 有問題，就優先修真實問題；只有 lab 有問題，就把它當作預警和除錯入口。

修完後怎麼重測？Baseline、單一變因、三次 median

修完後不要只跑一次 PSI 就宣布成功。比較穩的做法是先記 baseline，每次只改一個變因，連跑至少三次取中位數，再等 field data 的資料窗逐步反映真實使用者變化。

我會用這張表記錄：

測試階段	LCP	INP 或 TBT	CLS	PSI 分數	備註
Baseline	3.8s	TBT 420ms	0.04	52	hero image 是 LCP
改 AVIF + preload	2.4s	TBT 410ms	0.04	66	LCP 改善明顯
拆分首頁 JS	2.3s	TBT 190ms	0.04	78	互動瓶頸下降

這種紀錄方式有一個好處：你知道哪個改動帶來哪個結果。省下的不是幾行報告文字，是下次排查少走很多冤枉路。

PSI 不能取代哪些工具？它負責起手，不負責全部答案

PSI 適合做第一輪診斷，但不能取代 DevTools Performance 面板、WebPageTest 瀑布圖、Search Console Core Web Vitals 報告、CrUX API 或你自己的 RUM。不同工具回答不同問題，拿錯工具會問不出答案。

工具	最適合回答	不適合回答
PageSpeed Insights	這個 URL 的真實資料和 lab 線索	每個資源的完整瀑布細節
DevTools Performance	主執行緒、long task、互動延遲	大規模 field data 趨勢
WebPageTest	瀑布圖、連線階段、首屏載入影片	Chrome 真實使用者分布
Search Console CWV	URL group 的整體達標狀態	單次改動是否立即有效
RUM	你的真實使用者與商業頁面體驗	沒有埋點前的歷史資料

如果你想深入操作 Lighthouse 報表，了解三種分析模式的差異與讓分數可重現的方法，可以參考 Lighthouse 使用方法完整說明。

最後給你一個實務判斷：不要追 100 分，先追可證明的瓶頸下降

PageSpeed Insights 的最佳用法不是追 100 分，而是用它找出下一個可證明的瓶頸。先看 field data，再看 Core Web Vitals，再用 lab data 找原因，最後用單一變因重測確認改動效果。這樣修下去，分數通常會上升，但你追的是使用者體驗，不是儀表板面子。

我自己的底線是：重要頁面先讓 LCP、INP、CLS 在 field data 達標，再處理 lab score 的細節。若分數 78 但真實使用者三指標都綠，我不會為了衝 95 分投入兩週。若分數 90 但 mobile field LCP 還是 3.5s，我會繼續追，因為使用者還在等。

PageSpeed Insights 分數多少才算好？

PSI performance score 90 分以上通常被視為綠色，但我會先看 field data 的 LCP、INP、CLS 是否達標。分數高但 field data 紅，仍然要修真實瓶頸。

PageSpeed Insights 沒有 field data 是壞事嗎？

不一定。這通常代表該 URL 的 Chrome 使用者樣本不足。可以改看 Origin Summary、Search Console URL group，或用 Lighthouse 和 WebPageTest 做 lab 診斷。

PSI 的 Opportunities 要全部修完嗎？

不用。Opportunities 是候選線索，不是完整待辦清單。先修會影響 LCP、INP、CLS 或主要商業頁面的項目，再回頭處理低影響項目。