PageSpeed Insights 怎麼用？讀懂分數、指標與優化方向
PageSpeed Insights 不只是一個分數，它同時結合了 CrUX 真實用戶數據和 Lighthouse 實驗測試，兩套數據各有意義。這篇從三大 Core Web Vitals 指標的判讀、報告三區塊的解讀方法，到 PSI 搭配 Google Search Console 的整合診斷流程，讓你不只是看到數字，而是知道下一步該做什麼。
PageSpeed Insights 是什麼？不只是測速工具
PageSpeed Insights（PSI）是 Google 官方提供的網頁效能分析工具，輸入任一 URL 就能取得行動裝置與電腦版的效能評分，以及具體的優化建議。工具網址：pagespeed.web.dev。
多數人把 PSI 當純粹的測速計分板，但它實際做的事比這複雜。它同時整合了兩套完全不同的數據來源，而這正是很多人搞不清楚「為什麼同一個網站今天 72 分、明天 68 分」的根本原因。
PSI 怎麼收集數據：CrUX 真實數據 vs Lighthouse 實驗數據
PSI 的報告上半部（「瞭解實際使用者體驗」）來自 Chrome User Experience Report（CrUX），這是 Chrome 瀏覽器從真實用戶收集、彙整的過去 28 天實際使用數據。你網站現在所有造訪者的載入速度，都會被統計進去。
報告下半部（「診斷效能問題」）則是 Lighthouse 在受控網路環境中做模擬測試的結果，模擬標準是 4G 行動網速、中階 Android 裝置。這個數字相對穩定，但不代表你所有用戶的真實體驗。
如果你網站的 CrUX 數據顯示「良好」，但 Lighthouse 分數偏低，代表真實用戶體驗其實不差，只是受控環境的模擬拉低了分數。反過來，如果 Lighthouse 分數很高但 CrUX 顯示「需要改善」，代表用戶的實際體驗比實驗環境差，可能是伺服器回應時間或第三方資源拖累了真實效能。
新網站或流量不夠高的頁面，會因為 CrUX 資料不足而只顯示 Lighthouse 數據。這種情況在剛上線的網站很常見，不用擔心。
PSI 效能分數怎麼算
Lighthouse 給的 0-100 效能分數是六項指標的加權平均：LCP（25%）、TBT 總封鎖時間（30%）、FCP 首次內容繪製（10%）、Speed Index（10%）、TTI 可互動時間（10%）、CLS（15%）。90 分以上算良好，50-89 待改善，49 分以下需要重點處理。TBT 佔比最高，意味著 JavaScript 執行效率是拉低分數最常見的原因之一。
三大 Core Web Vitals 指標怎麼看
Google 從眾多效能指標中挑了三個作為 Core Web Vitals，這三個會直接反映在 Google Search Console 的網站體驗報告裡，也是 Page Experience 排名信號的核心依據。
LCP（最大內容繪製）— 主視覺多快出現
LCP 測量頁面可視範圍內最大元素（通常是首圖或 H1 文字）完成渲染的時間，反映的是「主要內容多快出現在用戶眼前」。標準：2.5 秒以內算良好，2.5 至 4 秒需改善，超過 4 秒屬於不良。
對大多數台灣網站來說，LCP 元素通常是首頁的 hero 圖片或文章頁的大標題。如果你的 hero 圖片沒有預載（preload）、沒有壓縮，LCP 就很容易超標。延伸閱讀：LCP 官方說明文件。
INP（與下一個顯示的內容互動）— 整體互動反應速度
INP 在 2024 年 3 月正式取代了舊指標 FID（首次輸入延遲）。兩者的差別在於：FID 只測用戶的第一次互動延遲，而 INP 測量整個頁面生命週期中所有點擊、鍵盤操作、觸控的最長延遲。這讓 INP 能更全面反映用戶在整個使用過程中的互動體驗，而不只是第一次點擊。
INP 標準：200 毫秒以下算良好，200 至 500 毫秒需改善，500 毫秒以上屬不良。對 React、Vue 等前端框架搭建的 SPA 網站，INP 不達標比較常見，因為 JavaScript 執行量大容易阻塞主執行緒。延伸閱讀：INP 官方說明文件。
CLS（累計版面配置位移）— 頁面穩不穩
CLS 測量頁面在載入過程中元素意外移動的程度。你點了一個連結，結果廣告突然插入，你按到了另一個按鈕，這就是 CLS 製造的問題。標準：0.1 以下算良好，0.1 至 0.25 需改善，超過 0.25 屬不良。
最常見的 CLS 問題來源：圖片沒有設定 width 和 height 屬性（瀏覽器不預留空間）、字體替換時造成文字跳位、動態插入的廣告或嵌入內容。
| 指標 | 衡量對象 | 良好 | 需改善 | 不良 |
|---|---|---|---|---|
| LCP | 主視覺載入速度 | ≤2.5 秒 | 2.5–4 秒 | >4 秒 |
| INP | 整體互動反應 | ≤200 毫秒 | 200–500 毫秒 | >500 毫秒 |
| CLS | 版面穩定性 | ≤0.1 | 0.1–0.25 | >0.25 |
三大 Core Web Vitals 指標的評分標準：LCP、INP、CLS（2026 年現行標準）
PageSpeed Insights 操作教學：3 分鐘讀懂報告
用 PSI 分析一個頁面只需要幾個步驟，但報告出來之後大部分人盯著數字不知道從哪裡開始。這裡說明的是怎麼有效率地讀報告，而不只是「把網址貼進去」。
基本操作
- 前往 pagespeed.web.dev，在輸入框貼上你要測試的頁面 URL
- 點擊分析，等待約 10–30 秒
- 報告預設顯示行動裝置版本。Google 的排名是以手機版為主（Mobile-first），所以優先看行動裝置那份報告
- 電腦版分數通常明顯高於行動版，這很正常；優化時先以手機版為主
PSI 報告三區塊解讀：機會（紅色，有節省時間預估）、診斷（橘色，技術診斷）、已通過（綠色，已達標）
報告三區塊：機會、診斷、已通過
分數下方有三個區塊，很多人只看分數忽略了這裡，但這才是最有價值的部分。
- 機會（Opportunities）：每一項都附有「預估可節省的時間」，例如「移除未使用的 JavaScript — 節省 1.2 秒」。這些是投資報酬率最高的優化項目，應該優先處理
- 診斷（Diagnostics）：技術診斷，不一定有時間節省的預估值，但影響用戶體驗。例如「DOM 元素數量過多」會讓頁面渲染變慢，但 Lighthouse 分數可能沒有直接反映
- 已通過的稽核（Passed Audits）：已達標的項目，不需要再動。可以展開確認一下，但不用花時間優化
在我診斷客戶網站時，最常見的誤區是花時間優化「診斷」區塊，卻忽略「機會」區塊裡有個未壓縮的 3MB 圖片。永遠從機會區塊、從預估節省時間最多的項目開始。
PSI 分數 90 分，排名就會好？先搞懂這件事
分數高有幫助，但不是直接關係。
Google 在 Page Experience 更新（2021 年）後，正式把 Core Web Vitals 納入排名信號。但官方說的是：當內容品質相當的情況下，頁面體驗較好的頁面排序會優先。換句話說，一篇內容深度和相關性都很高的文章，即使 PSI 分數 60 分，也可能排在一篇 PSI 分數 95 分但內容薄弱的頁面前面。PSI 分數是排名的輔助因素，不是主因。內容品質和語意相關性才是。我們網站的 SEO 排名因素完整解析有詳細拆解這個層級關係。
第二個常見誤解：「優化了，但分數沒有動」。這是因為 PSI 報告上半部的 CrUX 數據每 28 天才更新一次。你今天把圖片全部轉成 WebP，PSI 的 CrUX 區塊要等到下個月才會反映這個改變。Lighthouse 分數（實驗數據）會立刻變，但 CrUX 不會。
所以實務上，不需要追求把分數從 88 拉到 98。把「不良」項目修到「良好」的效果，遠比把「良好」繼續推高明顯。分數在 75 以下，優化有明顯效果；超過 85，繼續投資的邊際效益就很低了。
看懂低分建議後，你能實際做哪些優化
技術 SEO 診斷不一定要工程師全程參與。以下幾個最常見的問題，很多可以由網站管理員或用外掛解決。
- 圖片未優化（影響 LCP）：把 JPG/PNG 轉成 WebP 格式可減少 30–50% 檔案大小；所有圖片加上 width 和 height 屬性避免 CLS；非首屏圖片加
loading="lazy"。WordPress 可用 Imagify 或 ShortPixel 自動轉換 - 未使用的 JavaScript（影響 TBT / INP）：用 PSI 的「機會」區塊確認哪個 JS 檔案最重。如果是 WordPress 的外掛，可以用 Asset CleanUp 停用特定頁面不需要的外掛 JS
- 阻塞渲染的資源（影響 FCP）：CSS 放
<head>、非必要 JS 加defer或async。WordPress 用 WP Rocket 可以一鍵設定 - 伺服器回應時間（TTFB）過長：這通常需要換更快的主機、啟用快取（WP Rocket / LiteSpeed Cache）、或使用 CDN（Cloudflare 有免費方案）。如果 TTFB 超過 600ms，光是優化前端能改善的程度很有限，要從伺服器端下手
什麼情況一定要找工程師：PSI 診斷裡出現「縮短主要執行緒工作」、「減少 JavaScript 執行時間」但沒有明顯的未使用 JS，通常代表程式碼本身需要重構。這不是外掛能解決的問題。
更多工具和技術 SEO 的診斷方法，可以參考我們整理的 SEO 工具推薦比較。
PSI + Google Search Console 整合診斷：AK PSI 診斷三步驟
PSI 只能逐頁測試，但一個網站可能有幾十甚至幾千個頁面。只用 PSI 掃幾個頁面，很難知道是不是整站都有問題。這裡分享一個把 PSI 和 Google Search Console 結合的工作流程。
多數競品文章只教怎麼用 PSI 這一個工具，但在實際診斷中，PSI 和 GSC 要搭配才能有效率。以下是我們對客戶執行技術診斷時固定用的 AK PSI 診斷三步驟框架：
- 掃描（PSI）：測試你的核心頁面，包含首頁、流量最高的幾篇文章、服務頁。記下行動裝置效能分數和三大 Core Web Vitals 的狀態（良好 / 需改善 / 不良）
- 驗證（GSC）：前往 Google Search Console，在左側選單找「體驗」下的「網站使用體驗核心指標」。這裡會列出整站被 CrUX 標記為「不良」的 URL 群組，讓你知道問題是個別頁面還是全站性的。搭配 GA4 數據也可以交叉確認哪些頁面跳出率異常高，很可能就是速度問題造成
- 驗收（PSI）：修改後立刻用 PSI 確認 Lighthouse 分數改善；真實 CrUX 數據需等約 28 天後在 GSC 的核心指標報告裡驗證
這個流程的關鍵是「PSI 負責診斷單頁，GSC 負責驗證覆蓋率」。不同工具各有專長，不要期待用 PSI 掃完三個頁面就宣告整站沒問題。
依照 PSI 診斷結果的對應優化方向，從最影響分數的項目開始處理
網站速度問題找不到根本原因？從單頁 PSI 診斷到整站技術架構審查，我們的方法是先看 GSC 數據，再定位問題所在，而不是逐頁掃描。了解我們的技術 SEO 顧問服務，確認是否符合你目前的需求。
常見問題
PageSpeed Insights 分數多少算好？
Lighthouse 效能分數 90 分以上算良好，50–89 需改善，49 以下需要重點處理。實務上，把分數從「不良區間」提升到「良好區間」的效益最明顯；超過 85 分後繼續拉高的邊際效益很低，把精力放在內容品質上更有效。
行動裝置和電腦的分數為什麼差很多？
Lighthouse 模擬行動裝置時使用的是較慢的網速（4G）和中階裝置，所以分數通常低於電腦版。這是正常現象。優化時以行動裝置版為主，因為 Google 以手機版內容作為排名基礎（Mobile-first indexing）。
PSI 分數和 Google 搜尋排名直接相關嗎？
Core Web Vitals 是 Google 排名因素之一，但不是主因。Google 說的是「內容品質相當時，頁面體驗好的優先」。一篇優質、深度的內容在 PSI 分數 60 分時，仍有機會排在分數 95 分但內容薄弱的頁面前面。分數達到「良好」門檻是目標，不需要追求滿分。
優化後分數為什麼沒有立刻提升？
PSI 報告分兩部分：Lighthouse 實驗數據和 CrUX 真實用戶數據。Lighthouse 分數在優化後立刻會反映；但 CrUX 使用的是 Chrome 收集的過去 28 天真實用戶數據，每 28 天更新一次。所以 CrUX 顯示的 Core Web Vitals 狀態，要等一個月左右才會更新。
INP 是什麼，和 FID 有什麼不同？
INP（Interaction to Next Paint）在 2024 年 3 月取代了 FID（First Input Delay）。FID 只測用戶的第一次互動延遲；INP 測量整個頁面生命週期中所有互動（點擊、鍵盤、觸控）的最長延遲，提供更完整的互動體驗評估。INP 達標標準：200 毫秒以下算良好。
沒有工程師也能提升 PSI 分數嗎？
可以，但取決於問題類型。圖片壓縮、WebP 轉換、加 loading="lazy" 這類優化，用外掛（WordPress 上如 WP Rocket、Imagify）就能完成。但如果問題是 JavaScript 執行效率（TBT/INP 偏高）或伺服器回應時間（TTFB 過長），通常需要工程師介入。PSI 的「機會」區塊都有預估節省時間，優先從時間最長的項目開始處理。
PageSpeed Insights 和 GTmetrix 有什麼差別？
PSI 使用 Google 官方的 Lighthouse 引擎，結合 CrUX 真實用戶數據，分數直接反映 Google 的評估標準，是優化 SEO 效能的首選工具。GTmetrix 整合了 Lighthouse 和 WebPageTest，提供更多測試地點選擇和瀑布圖分析，適合進階診斷用。做 SEO 優先用 PSI，做前端效能調試可以搭配 GTmetrix。
網站圖片很多，LCP 一直不達標，最有效的做法是什麼？
先確認 PSI 報告裡「最大內容繪製」指向的是哪個元素（通常是首屏圖片）。對這張圖片：1) 轉成 WebP 格式縮小檔案；2) 在 HTML 的 <head> 加上 <link rel="preload"> 讓瀏覽器優先載入這張圖；3) 確認圖片由與頁面同網域的伺服器或 CDN 提供，減少跨域請求延遲。其他圖片加 loading="lazy" 延遲載入，避免擠佔首屏資源。