PageSpeed Insights 教學：Google 工具分工與分數判讀

PageSpeed Insights 是 Google 的網頁效能檢測工具。輸入網址可取得 Lighthouse 模擬測試；樣本足夠時，也能查看真實訪客的使用體驗。兩種資料放在同一份報告裡，回答不同的問題：訪客用得順不順，以及目前有哪些改善線索。

對網站主和 SEO 人員來說，最有用的做法是先看資料範圍與使用體驗，再看分數和建議。單次測到綠燈，仍可能有訪客覺得慢；沒有真實訪客資料，也不表示網站已經通過檢查。

這篇會先整理 Google 相關工具的分工，再帶你依序讀報告、判斷分數，最後用一個假設案例說明，如何把結果變成能交給工程師處理的問題。

PageSpeed Insights 與 Google 效能工具，怎麼分工？

新手不需要一次學會所有工具。先看你現在想解決什麼：快速檢查一頁、找出一批有問題的頁面，還是追查哪段操作造成卡頓，再選擇入口。

例如，Search Console 顯示許多商品頁有相同問題，就先挑代表頁檢查，再請工程師追查共用版型。不熟悉這個監測入口，可以先看Google Search Console 介紹。

報告裡的真實訪客資料，主要來自 Chrome 使用者體驗報告（Chrome UX Report，簡稱 CrUX）。需要看較長時間的變化時，可以再用 CrUX Vis 查看歷史趨勢；剛開始檢查一頁，先用本文的報告讀法就夠了。

PageSpeed Insights 報告，照這 3 步讀

報告不必從最大的圓形分數開始看。照「測試條件 → 真實訪客 → 模擬診斷」的順序，會更容易知道每個數字在說什麼。

1. 輸入實際網址，分開看手機與電腦

打開 PageSpeed Insights，貼上想檢查的完整頁面網址並開始分析。完成後分別查看手機與電腦結果，確認報告中的網址就是你要處理的頁面，不要只測首頁就推論整個網站。

手機與電腦使用不同測試條件，真實訪客資料也分裝置。若主要客戶用手機逛網站，應優先閱讀手機報告；電腦分數很高，不能抵銷手機上的問題。

2. 先看真實訪客，也確認是這一頁還是整個來源

PageSpeed Insights 的真實訪客區塊使用 CrUX 過去 28 天的彙總資料。先看畫面標示的是這個網址，還是來源（origin）：後者通常指相同通訊協定、主機名稱與連接埠下的頁面集合，不能當作這一頁的專屬成績。

新頁面或樣本不足時，工具可能改顯示來源層級資料；來源也沒有足夠資料，就無法提供這一區的結果。沒有資料只代表無法據此判定，並不等於良好或通過。這些資料範圍與限制可見 Google 的報告說明。

接著看 Core Web Vitals，也就是 Google 用來觀察載入、互動與畫面穩定度的三項核心指標。良好門檻如下，三項都以越低越好為方向：

• LCP（最大內容繪製）≤ 2.5 秒：主要可見內容出現得夠不夠快。
• INP（互動至下次繪製）≤ 200 毫秒：點擊、輕觸或鍵盤操作後，畫面回應是否及時。
• CLS（累計版面配置位移）≤ 0.1：閱讀和操作時，內容是否意外移動；這是分數，沒有秒數單位。

這裡顯示的是第 75 百分位，不是平均值。例如 LCP 是 2 秒，代表約 75％ 的觀測值不超過 2 秒，仍有較慢的體驗。當三項資料都足夠時，三項都達良好門檻才會通過評估。

若只有 INP 資料不足，工具可依 LCP、CLS 判定；若 LCP 或 CLS 資料不足，就無法評估。看到通過時，仍要確認資料層級和缺漏，不能自行推成每位訪客、每種操作都沒有問題。

3. 再看 PageSpeed Insights 模擬測試，找改善線索

往下看 Lighthouse 的模擬測試。PageSpeed Insights 這一區會提供效能、無障礙、最佳做法與 SEO 等檢查，幫助你定位目前這次載入可能遇到的問題。

除了 LCP、CLS，也會看到 FCP（第一批內容何時出現）、Speed Index（載入時內容顯示的速度）和 TBT（總阻塞時間）。真實訪客區塊的 TTFB 則可協助觀察伺服器回應。這些數字用來補充診斷，不必都當作新的核心指標。

尤其要注意，TBT 不能直接換算成 INP。一般載入測試沒有完整重現訪客的互動；TBT 可以提供程式阻塞的線索，卻可能漏掉點擊後才發生的問題。Google 的 TBT 說明也明確區分兩者。

把 PageSpeed Insights 的建議當成待確認的原因，例如圖片太大、資源阻擋顯示或程式執行太久。先問它是否對應前面發現的使用問題，再請工程師驗證；清單排在前面，不代表一定是你最該做的工作。

PageSpeed Insights 分數多少才好？要追求 100 分嗎？

PageSpeed Insights 的 Lighthouse 分數中，90～100 分代表良好，50～89 分代表需要改善，0～49 分代表不佳。效能分數是多項測量結果加權後的表現，不能讀成「網站有幾成快」，也不能把 50 分當作及格線。

分數適合追蹤同一頁在相近條件下有沒有改善。廣告內容、網路與測試環境都會帶來波動，因此比較前後版本時，應保留同一網址、裝置模式與測試條件，多跑幾次看整體走勢，不要挑最高的一次當成果。這也符合 Lighthouse 對分數變動的說明。

PageSpeed Insights 的 SEO 分數，則是這套工具能自動檢查的項目結果。它不代表 Google 已收錄，也不保證排名；符合搜尋技術要求仍不保證收錄，更不能把一個工具的分數當作搜尋引擎的最終判斷。

Google 也說明，Core Web Vitals 會用於排名系統，但良好結果不保證名列前茅。網站已經好讀、好操作時，為了 SEO 把 98 分磨到 100 分，未必比改善內容或處理關鍵頁更值得。

工商時間

如果你想要更系統化、更輕鬆的學好 SEO 與 AI SEO，歡迎參考我與知識衛星合作的 SEO 線上課程：《SEO 排名攻略學》、《AI SEO 流量變革》。

透過《SEO 排名攻略學》獲得穩定的 SEO 流量與實戰經驗。
再搭配《AI SEO 流量變革》看懂 AI 搜尋趨勢，搶佔 AI 搜尋紅利。

假設報告：效能 95 分，INP 卻需要改善，怎麼辦？

假設某商品頁的手機 PageSpeed Insights 報告顯示：Lighthouse 效能 95 分；而這個網址過去 28 天的真實訪客資料是 LCP 2.2 秒、INP 320 毫秒、CLS 0.04，三項樣本都足夠。以下是教學假設，不是本站或任何品牌的實測。

這份 PageSpeed Insights 報告表示：這次模擬載入表現良好，但真實訪客的 INP 尚未達到良好門檻，因此核心指標評估不會通過。95 分與 INP 需要改善可以同時成立，因為資料來源、觀測期間與測試內容不同。

接下來應針對操作找原因。請工程師重現打開商品選單、切換規格、加入購物車等流程，觀察是哪個互動延遲，再追查相關程式。光憑 INP 數字，還不能斷定是某個外掛，也不能直接決定換主機。

反過來，若真實訪客指標良好，但某次模擬分數偏低，也應先重跑與檢查條件，確認是否有穩定可重現的瓶頸。實驗室與真實訪客資料不一致，是追查差異的起點。

看完 PageSpeed Insights，如何安排改善與驗收？

先排影響範圍，再交辦具體問題

PageSpeed Insights 的改善清單不必照單全收。網站主可以先用三個問題排序：是否妨礙閱讀或操作、是否影響重要頁面或許多同版型頁面，以及工程師能不能重現並驗證原因。

例如，商品首圖很晚出現、結帳按鈕點了沒反應，比不影響使用的小幅分數波動更值得優先處理。同樣嚴重時，再看流量、商業重要性和共用版型；不要只因某項標示的預估節省時間最大，就認定它最有價值。

交辦時附上網址、手機或電腦、資料層級、出問題的指標、報告，以及能重現的操作。像「手機商品頁切換規格後明顯延遲，請檢查相關互動與程式」，就比「請把分數改到 100」更容易確認完成狀態。

需要理解工程師追查的畫面，可以看Chrome 網頁開發者工具介紹；若要延伸了解壓縮圖片、快取等一般方向，再讀網站速度優化介紹。

修完立即驗證，再持續追蹤訪客資料

修完後先重跑 PageSpeed Insights，使用相近條件比較前後結果，並實際操作原本卡頓的流程。確認問題改善時，也要檢查圖片、表單與追蹤功能是否仍正常，不能只驗分數上升。

真實訪客資料是滾動的 28 天視窗，而且每日更新。新版資料會逐步進入、舊版資料逐步移出，所以不會在部署後立刻全部換新。可以持續觀察趨勢；若網站有自行收集的真實使用監測，也能搭配確認，不必等滿 28 天才開始看。

有成批頁面問題時，再回 Search Console 追蹤相關群組。這樣驗收會同時回答兩件事：改動是否解決可重現的問題，以及後續訪客體驗是否朝預期方向改善。

工商時間

如果你想要更系統化、更輕鬆的學好 SEO 與 AI SEO，歡迎參考我與知識衛星合作的 SEO 線上課程：《SEO 排名攻略學》、《AI SEO 流量變革》。

透過《SEO 排名攻略學》獲得穩定的 SEO 流量與實戰經驗。
再搭配《AI SEO 流量變革》看懂 AI 搜尋趨勢，搶佔 AI 搜尋紅利。

結語：讓報告幫你決定下一步

PageSpeed Insights 最有價值的地方，是把訪客經驗與測試線索放在同一個入口。先確認網址、裝置與資料範圍，再看核心指標，最後用模擬報告找原因，就能少掉許多看錯分數的困擾。

網站主不用自己修完每一段程式，但要能說清楚哪個頁面、哪種使用情境出了問題，並要求可驗證的改善。把這件事做好，比每次重測都期待出現 100 分，更能幫助網站持續變好。