- 登入
- 註冊
PageSpeed Insights 怎麼看？Core Web Vitals 分數與網站速度改善順序
內容目錄
顯示
PageSpeed Insights 報告先分清真實使用者資料與實驗室診斷。上方 Core Web Vitals 區塊彙整符合 CrUX 條件的 Chrome 使用者在過去 28 天的體驗，可能是 URL 或 origin 層級；下方 Lighthouse 分數則來自這次模擬載入。確認資料是否足夠、指標與層級，再用 lab 資料找候選原因。
兩者用途不同。真實使用者資料可以回答「多數使用者最近的體驗如何」，實驗室資料適合回答「在這組測試條件下，可能是哪個資源或程式工作造成問題」。手機版出現紅色分數，不代表 Google 已經替網站算出一個固定的 SEO 排名分數，也不能只靠把 Lighthouse 衝到 100 分保證排名上升。
來源：Google About PageSpeed Insights、Google web.dev Web Vitals與Chrome Lighthouse performance scoring（查證 2026-10-10）。官方文件用來確認 PSI 的 field data 與 lab data 來源、Core Web Vitals 判定方式，以及 Lighthouse 分數的加權與波動。本文不把單次效能分數寫成 SEO 排名分數。
PageSpeed Insights 是什麼？
PageSpeed Insights，常縮寫為 PSI，是 Google 提供的網頁效能分析工具。輸入公開網址後，PSI 會分別呈現行動裝置與電腦環境的資料，並把真實使用者體驗與模擬載入診斷放在同一份報告。
PSI 是報告入口，不是資料全部由 PSI 自己產生
PSI 把兩套主要資料來源放進同一頁：
- Chrome User Experience Report：常縮寫為 CrUX，提供符合資料條件的 Chrome 真實使用者體驗。
- Lighthouse：在模擬環境中載入指定網址，產生效能指標、分數與診斷建議。
CrUX 提供真實使用者資料
PSI 的真實使用者資料來自 CrUX。Google 官方目前說明，PSI 會呈現前 28 天收集期間的 FCP、LCP、CLS 與 INP，並可能顯示實驗性 TTFB 指標。
Lighthouse 提供可重跑的實驗室診斷
PSI 的 lab data 由 Lighthouse 產生。它會在模擬裝置與網路條件下載入這個網址，計算效能指標，再產生 Performance、Accessibility、Best Practices 及 SEO 等類別分數與診斷。
PageSpeed Insights 不會自動替網站排好修復順序
報告中的 Opportunities 與 Diagnostics 會列出可能改善項目，也可能估算節省時間或傳輸量。這些結果是技術候選清單，不等於商業優先級。
- 問題影響哪些頁面範本。
- 是否阻擋主要內容或互動。
- 行動版與電腦版是否都受影響。
- 真實使用者資料是否也呈現相同訊號。
- 修正成本與回歸風險。
- 是否由第三方腳本或外部服務造成。
來源：Google About PageSpeed Insights與Chrome Lighthouse performance scoring（查證 2026-10-10）。Google 文件說明 PSI 的真實資料來自 CrUX，涵蓋前 28 天，資料不足時可能回退到 origin 或完全無法顯示；lab data 則由 Lighthouse 在模擬環境產生。本文的商業優先級欄位是診斷方法，不是 PSI 內建排序。
Field data、lab data、Core Web Vitals 與 Performance score 差在哪裡？
這四個名詞需要分清，不能混成同一個「速度分數」。Field data 與 lab data 是資料取得方式；Core Web Vitals 是一組真實體驗核心指標；Performance score 則是 Lighthouse 實驗室指標經加權後的總分。
| 項目 | 資料來源 | 代表對象 | 時間範圍 | 主要用途 | 主要限制 |
|---|---|---|---|---|---|
| URL field data | CrUX 真實 Chrome 使用者 | 指定網址的合格樣本 | 過去 28 天移動期間 | 判斷該頁真實體驗 | 需要足夠樣本，無法逐筆重現 |
| Origin field data | CrUX 真實 Chrome 使用者 | 同一來源網站的合格頁面 | 過去 28 天移動期間 | URL 資料不足時提供較廣訊號 | 不能直接代表指定頁面 |
| Lab data | Lighthouse 模擬載入 | 這次測試條件下的單次執行 | 當次測試 | 重現問題與找候選原因 | 不是多數真實使用者分布 |
| Performance score | Lighthouse 多項 lab 指標 | 當次模擬執行 | 當次測試 | 快速摘要與同條件比較 | 權重會更新，總分會波動 |
Field data 回答「真實使用者最近遇到什麼」
Field data 是現場資料的常見翻譯。PSI 不是追蹤某一位使用者，而是呈現符合 CrUX 條件的匿名彙整資料。下列是三項 Core Web Vitals 的良好門檻，須按報告層級與第 75 百分位判讀。
- LCP 不超過 2.5 秒。
- INP 不超過 200 毫秒。
- CLS 不超過 0.1。
Lab data 回答「這次模擬為什麼可能變慢」
Lab data 來自單次模擬測試，能提供效能時間軸、網路請求、主執行緒工作與改善建議。它的優勢是可重跑：團隊可以在修改前後用相似條件測同一網址，觀察候選原因是否改變。以下分數是教學假設，示範保留三次結果與範圍，不是任何網站實測。
- 第一次：58 分。
- 第二次：72 分。
- 第三次：64 分。
- 最低值：58 分。
- 最高值：72 分。
- 範圍：72 － 58 ＝ 14 分。
- 簡單平均：（58 ＋ 72 ＋ 64）÷ 3 ＝ 64.7 分。
Core Web Vitals 不是 Performance score 的三個子分數
Core Web Vitals 目前由 LCP、INP 與 CLS 組成，分別關注載入、互動回應與視覺穩定。PSI 的真實體驗區塊會用 CrUX 資料評估這三項。
- Field data 的 Core Web Vitals 通過，但這次 lab score 偏低。
- Field data 未通過，但新版本單次 lab score 已改善。
- 指定 URL 沒有 field data，只能看到 origin 資料與 lab 診斷。
- 手機 lab score 低於電腦版，但真實使用者差距要另外看 field data。
Performance score 是診斷摘要，不是 SEO 分數
Lighthouse Performance score 是多項指標分數的加權平均。不同指標權重不一樣，而且 Lighthouse 團隊可能隨研究與版本更新調整權重。這個總分不能回答以下問題：
- 網站會排在 Google 第幾名。
- 真實使用者是否都覺得快。
- 全站每一種頁型是否相同。
- 轉換率一定會增加多少。
- 哪個技術問題必須第一個修。
LCP、INP、CLS 怎麼讀？
Core Web Vitals 目前是 LCP、INP、CLS，分別觀察主要內容呈現、互動到下一次畫面的延遲及非預期位移。依手機與電腦分開看第 75 百分位；三項樣本充足時須全部達到良好門檻。PSI 若只有 INP 樣本不足，仍可依 LCP 與 CLS 判定；任何一項 LCP 或 CLS 資料不足時就不能評估，不能把「無資料」當成通過。
| 指標 | 英文全名 | 衡量內容 | 良好 | 需要改善 | 不良 | 常見頁面例子 |
|---|---|---|---|---|---|---|
| LCP | Largest Contentful Paint | 可視區域最大內容元素的呈現時間 | 不超過 2.5 秒 | 超過 2.5 秒至 4 秒 | 超過 4 秒 | 主視覺圖片、大型文字區塊或影片預覽圖出現太慢 |
| INP | Interaction to Next Paint | 點擊、輕觸或鍵盤操作到下一次畫面更新的延遲 | 不超過 200 毫秒 | 超過 200 毫秒至 500 毫秒 | 超過 500 毫秒 | 選單點了才開，加入購物車後很久才顯示結果 |
| CLS | Cumulative Layout Shift | 頁面生命週期內，非預期位移最大片段的累積分數 | 不超過 0.1 | 超過 0.1 至 0.25 | 超過 0.25 | 圖片載入後把文字推開，橫幅突然插入內容上方 |
LCP 看主要內容何時真正出現
LCP 的完整名稱是 Largest Contentful Paint。它測量使用者開始前往頁面後，可視區域內最大圖片、文字區塊或影片元素完成呈現所需的時間。
- 初始文件與伺服器回應是否太慢。
- LCP 資源是否太晚才被瀏覽器發現。
- 圖片或字型等資源下載是否太久。
- 資源下載完成後，元素是否仍被 CSS 或 JavaScript 延後呈現。
INP 看操作後多久出現下一個畫面
INP 觀察造訪期間的滑鼠點擊、螢幕輕觸與實體或螢幕鍵盤操作，計入輸入延遲、事件處理及下一畫面呈現延遲。多數頁面取最慢互動；互動量較多時會排除特定極端值。單純滑動、懸停或縮放本身不納入 INP；表單鍵盤輸入則可能納入。
- 點選導覽選單後，選單很久才出現。
- 按下加入購物車後，數量或提示遲遲沒有更新。
- 輸入表單內容時，介面明顯卡住。
- 切換頁籤或篩選器後，結果很晚才顯示。
CLS 看內容是否在沒有預期時突然移動
CLS 衡量非預期版面位移的影響，單次分數由影響範圍與移動距離計算。現行指標取整個造訪期間最高分的 session window：相鄰位移間隔少於 1 秒，單一視窗最長 5 秒。它不是把整個生命週期每次位移無限加總；分數沒有秒或毫秒單位。
- 圖片沒有預留寬高比例，載入後才撐開空間。
- 廣告、嵌入內容或 iframe 沒有預留位置。
- 網頁載入後才把橫幅或提示插入既有內容上方。
- 網頁字型切換時改變文字尺寸與換行。
有資料的指標逐項判定，不能取平均
假設同一組行動版 field data 顯示：
- LCP：2.3 秒，良好。
- INP：240 毫秒，需要改善。
- CLS：0.08，良好。
來源：Google web.dev Web Vitals、Largest Contentful Paint、Interaction to Next Paint、Cumulative Layout Shift與Optimize Cumulative Layout Shift（查證 2026-10-10）。官方文件用來確認三項指標定義、良好與不良門檻、第 75 百分位判定及常見 CLS 原因。頁面例子與改善優先順序為本文依官方定義整理的診斷框架。
哪些 PageSpeed Insights 報告狀態要先處理？
先處理哪一項，不能只看哪個顏色最紅。正確順序要同時考慮資料層級、影響頁數、主要任務與證據可信度。
| 報告狀態 | 代表意思 | 第一個檢查 | 常見誤讀 | 建議優先級 |
|---|---|---|---|---|
| URL field data 未通過 | 指定網址的真實使用者資料至少一項核心指標未達良好門檻 | 哪項指標失敗，是否影響主要任務 | 把 Lighthouse 每個建議都當成已確認原因 | 關鍵頁或共用範本通常優先 |
| 只有 origin field data | 指定網址樣本不足，報告改顯示整個來源網站資料 | 報告標籤是否為 Origin | 把全站訊號直接當成這一頁的實測 | 先找受影響頁型與 URL 證據 |
| 沒有 field data | URL 與 origin 都沒有足夠 CrUX 樣本 | 網址是否正確及是否可公開存取，再看 lab 診斷 | 當成通過、失敗或流量為零 | 診斷但不宣稱 field data 結論 |
| 行動與電腦落差大 | 裝置、網路、資源或使用者組成可能不同 | 是否比較相同資料層級與時間範圍 | 用手機 lab score 對照電腦 field data | 依主要流量與轉換裝置排序 |
| 單一頁面異常 | 特定 URL 或頁型可能有獨有資源與元件 | 與健康對照頁比較可核對的差異 | 直接把單頁問題擴大成全站問題 | 依該頁商業重要性排序 |
真實使用者未通過，而且影響關鍵流程
如果 field data 未通過，且問題出現在首頁、主要服務頁、商品頁或結帳流程，通常應先列入改善。這代表最近 28 天的真實體驗已出現訊號，不只是一次模擬測試偏慢。
沒有 field data 不是自動通過
新網站、低樣本頁面或不符合 CrUX 資料條件的網址，可能完全沒有 field data。PSI 會先嘗試由指定 URL 回退到 origin；如果 origin 也沒有足夠資料，就只剩實驗室診斷。
行動版落後時，先確認比較基準
行動版常比電腦版更容易出現低分，但差異可能來自模擬條件，也可能是真實體驗。第一步不是宣告「手機網站壞了」，而是核對：
- 兩邊都是 URL field data，還是其中一邊為 origin data。
- 兩邊都是 field data，還是拿 field data 與 lab data 混比。
- 行動版的圖片等資源是否不同，或是否另外載入選單與第三方元件。
- 主要訪客與轉換是否集中在行動裝置。
單頁異常要先找健康對照頁
同一網站中，首頁不良但文章頁良好，或只有某一個商品頁 CLS 過高，適合用對照組找差異。選一個功能與版型相近的健康頁面，逐項比較：
- 是否多了一支第三方腳本。
- 是否使用不同的主視覺圖片。
- 是否插入廣告、影片或外部表單。
- 是否套用不同頁面範本。
- 是否在載入後注入公告或促銷區塊。
PageSpeed Insights 測試前要準備什麼？
沒有先固定頁面與測試條件，PSI 很容易變成反覆截分數，卻無法比較。測試前要先回答三件事：這次代表哪一種頁面，要驗證哪一個使用者任務，以及修改前後要用什麼證據判定改善。
先選頁型，不要只測首頁
首頁的資源與流程不一定代表文章、商品與結帳頁。不同頁型可能使用不同範本、圖片及第三方元件，只測首頁無法推論全站。
- 首頁：觀察主視覺、導覽與全站共用資源。
- 主要服務頁：觀察詢價入口及長版內容。
- 一篇典型文章：觀察首圖、目錄及嵌入內容。
- 一個典型商品頁：觀察商品圖、規格與加入購物車互動。
- 轉換頁面：觀察表單、購物車或結帳流程。
URL、裝置與資料層級要先記錄
PSI 會分開呈現行動與電腦結果，field data 又可能顯示 URL 或 origin 層級。測試紀錄若只寫「首頁 62 分」，日後很難確認這個數字來自哪個環境。
| 欄位 | 紀錄內容 | 原因 |
|---|---|---|
| 測試網址 | 完整 canonical URL | 避免測到重新導向或不同參數版本 |
| 頁型 | 首頁、文章、商品或轉換頁 | 判斷能否推廣到同範本 |
| 裝置 | 行動或電腦 | 兩種模擬及真實分布不同 |
| Field data 層級 | URL、Origin 或無資料 | 避免把全站訊號當成單頁結果 |
| 測試日期與時間 | 年月日與時段 | 對照版本、活動與服務狀態 |
| Lighthouse 版本 | 報告 Environment 顯示內容 | 工具版本與條件可能更新 |
| 頁面版本 | 修改前、修改後或部署識別 | 避免比較到不同程式狀態 |
公開頁面與登入狀態要分開處理
PSI 適合分析可由 Google 測試環境存取的公開網址。會員後台、登入後購物車或需要特定 Cookie 才出現的畫面，不能直接把公開 PSI 結果當成完整使用流程證據。
- 公開入口頁仍用 PSI 查看 field data 與 Lighthouse 診斷。
- 登入後流程搭配 Chrome DevTools 和測試帳號，以真機操作記錄效能。
以三次重測起步，保留每次結果與差異
Lighthouse 分數可能受到網路路由、廣告、A/B 測試及環境變化影響。本文建議先測三次，保留全部結果；這是診斷起點，不是 Google 規定的最低次數，也不能用三次就證明穩定。波動較大或來源未明時，增加採樣並檢查底層指標。以下以教學假設的 61／68／64 分示範計算，不是實測結果。
- 輸入值：61 分、68 分、64 分。
- 最低值：61 分。
- 最高值：68 分。
- 範圍：68 － 61 ＝ 7 分。
- 簡單平均：（61 ＋ 68 ＋ 64）÷ 3 ＝ 64.3 分。
怎麼把 PageSpeed Insights 報告變成改善待辦？
一份可執行的效能待辦，不是把 PSI 的 Opportunities 全部複製給工程師。它要把「哪一群使用者遇到什麼問題」連到「哪個假設值得驗證」，並定義修改範圍與驗收方式。
先確認結論來自 field data 還是 lab data
同一個數值若來源不同，能支持的結論也不同：
- Field data 可以支持「最近 28 天的真實使用者體驗出現這個訊號」。
- Lab data 可以支持「在這次模擬條件下重現這個現象」。
- Opportunities 與 Diagnostics 可以支持「這是值得檢查的候選原因」。
把指標翻成具體使用者問題
技術指標只有連到任務，才容易判斷優先級：
| 指標訊號 | 使用者可能感受到的問題 | 第一批證據 | 待辦方向 |
|---|---|---|---|
| LCP 不良 | 進入頁面後，主要內容很久才出現 | LCP 元素、資源瀑布與 TTFB | 縮短主要內容的發現時間與下載時間，並減少呈現延遲 |
| INP 不良 | 點擊後介面沒有立即回應 | 受影響互動、長工作與第三方程式 | 縮短主執行緒阻塞及事件處理 |
| CLS 不良 | 閱讀或點擊時內容突然移動 | 位移元素與觸發來源 | 預留尺寸並避免非預期內容插入 |
| Lab score 波動大 | 同一頁有時快，有時慢 | 三次分布與環境備註 | 找出快取、網路或第三方變數 |
用健康頁與異常頁建立對照
找出一個合理原因前，至少列出兩到三個競爭假設，再用證據淘汰。假設某商品頁 LCP 不良，可以先提出：
- 主圖檔案過大，下載時間偏長。
- 主圖被延遲載入，瀏覽器太晚才發現。
- 初始文件回應過慢，所有主要資源都延後。
排序要同時納入影響範圍與任務重要性，並評估修正成本
PSI 不知道哪個頁面帶來詢價，也不知道哪支腳本是法規同意管理所必需。專案排序可以使用五個欄位：
| 評估欄位 | 低 | 中 | 高 |
|---|---|---|---|
| 影響頁數 | 單一低流量頁 | 一個重要頁型 | 全站共用範本 |
| 任務影響 | 裝飾性效果 | 閱讀與導覽 | 購買、預約或送出表單 |
| Field 證據 | 無資料 | 需要改善 | 不良且樣本充足 |
| 重現程度 | 單次出現 | 多次但波動 | 相同條件穩定重現 |
| 修正風險 | 局部且可回復 | 需跨元件測試 | 影響核心功能或第三方合規 |
看 PageSpeed Insights 要避開哪些判讀錯誤？
PSI 判讀需要注意的地方，不是指標太多，而是把不同層級的證據壓成一個分數。以下錯誤會讓團隊忙著「優化」，卻無法證明使用者體驗是否改善。
把 Lighthouse 100 分當成專案目標
Lighthouse 的 Performance score 是加權後的 lab 摘要，不是真實使用者體驗保證，也不是 SEO 排名分數。Chrome 官方指出，從 99 分提升到 100 分所需的指標改善，可能和從 90 分提升到 94 分相近；追逐最後一分的成本未必符合網站任務。
- 關鍵頁的 field data 是否達到良好門檻。
- 主要內容與互動是否不再阻擋使用者。
- 修改後底層指標是否穩定改善。
- 功能、版面及追蹤是否沒有回歸。
只測首頁或只保留一次最好成績
首頁良好不能代表文章頁、商品頁與結帳頁都良好。只測首頁是第一個取樣錯誤；測了三次卻只截最高分，則是第二個取樣錯誤。
- 輸入值：45 分、79 分、52 分。
- 最低值：45 分。
- 最高值：79 分。
- 範圍：79 － 45 ＝ 34 分。
混用 field、lab、URL 與 origin 資料
常見的第三個錯誤，是拿手機 lab score 與電腦 field data 比較；第四個錯誤，是把 origin 資料當成指定 URL 的實測；第五個錯誤，則是把沒有 field data 寫成 0 分或自動通過。
- 裝置是否相同。
- 資料是 field 還是 lab。
- Field data 是 URL 還是 Origin。
- 報告是否真的有足夠資料完成評估。
- 比較期間與頁面版本是否一致。
同時修改太多項目或忽略第三方腳本
第六個錯誤，是一次更換主機，壓縮圖片，合併程式又改快取；第七個錯誤，是把客服、廣告與分析程式視為不可檢查的外部因素。
來源：Chrome Lighthouse performance scoring、Google About PageSpeed Insights與Why lab and field data can be different（查證 2026-10-10）。官方文件用來確認 Lighthouse 分數加權與波動、field data 層級及 lab 與 field 的環境差異。七項常見錯誤與 45／79／52 分算式為本文的診斷示例。
首頁與內容頁各測三次，要怎麼判讀？
以下數字是教學用的假設資料，不是 site-now.app 或客戶網站實測。目的在示範如何保存中間值，區分穩定問題與單次波動，再轉成可驗收待辦。表中的 TBT 是 Total Blocking Time（總阻塞時間），屬於 lab 診斷線索，不能代替 field INP；三次樣本也只能提供起始線索。
首頁三次測試顯示穩定的 LCP 問題
假設首頁結果如下：
| 次數 | Performance score | LCP | TBT | CLS | 當次 LCP 元素 |
|---|---|---|---|---|---|
| 1 | 48 | 4.3 秒 | 320 毫秒 | 0.04 | 首頁主視覺 |
| 2 | 54 | 3.9 秒 | 280 毫秒 | 0.03 | 首頁主視覺 |
| 3 | 51 | 4.1 秒 | 300 毫秒 | 0.05 | 首頁主視覺 |
- 輸入值：48 分、54 分、51 分。
- 最低值：48 分。
- 最高值：54 分。
- 範圍：54 － 48 ＝ 6 分。
- 簡單平均：（48 ＋ 54 ＋ 51）÷ 3 ＝ 51 分。
- 輸入值：4.3 秒、3.9 秒、4.1 秒。
- 最低值：3.9 秒。
- 最高值：4.3 秒。
- 範圍：4.3 － 3.9 ＝ 0.4 秒。
- 簡單平均：（4.3 ＋ 3.9 ＋ 4.1）÷ 3 ＝ 4.1 秒。
- 輸入值：320 毫秒、280 毫秒、300 毫秒。
- 最低值：280 毫秒。
- 最高值：320 毫秒。
- 範圍：320 － 280 ＝ 40 毫秒。
- 簡單平均：（320 ＋ 280 ＋ 300）÷ 3 ＝ 300 毫秒。
- 輸入值：0.04、0.03、0.05。
- 最低值：0.03。
- 最高值：0.05。
- 範圍：0.05 － 0.03 ＝ 0.02。
- 簡單平均：（0.04 ＋ 0.03 ＋ 0.05）÷ 3 ＝ 0.04。
內容頁三次測試顯示一次明顯波動
假設內容頁結果如下：
| 次數 | Performance score | LCP | TBT | CLS | 環境備註 |
|---|---|---|---|---|---|
| 1 | 72 | 2.7 秒 | 110 毫秒 | 0.07 | 無特殊狀況 |
| 2 | 60 | 3.4 秒 | 420 毫秒 | 0.08 | 一支第三方請求延遲 |
| 3 | 70 | 2.8 秒 | 130 毫秒 | 0.06 | 無特殊狀況 |
- 輸入值：72 分、60 分、70 分。
- 最低值：60 分。
- 最高值：72 分。
- 範圍：72 － 60 ＝ 12 分。
- 簡單平均：（72 ＋ 60 ＋ 70）÷ 3 ＝ 67.3 分。
- 輸入值：2.7 秒、3.4 秒、2.8 秒。
- 最低值：2.7 秒。
- 最高值：3.4 秒。
- 範圍：3.4 － 2.7 ＝ 0.7 秒。
- 簡單平均：（2.7 ＋ 3.4 ＋ 2.8）÷ 3 ＝ 2.97 秒。
- 輸入值：110 毫秒、420 毫秒、130 毫秒。
- 最低值：110 毫秒。
- 最高值：420 毫秒。
- 範圍：420 － 110 ＝ 310 毫秒。
- 簡單平均：（110 ＋ 420 ＋ 130）÷ 3 ＝ 220 毫秒。
- 輸入值：0.07、0.08、0.06。
- 最低值：0.06。
- 最高值：0.08。
- 範圍：0.08 － 0.06 ＝ 0.02。
- 簡單平均：（0.07 ＋ 0.08 ＋ 0.06）÷ 3 ＝ 0.07。
兩個頁面應先處理哪一個？
若首頁承接主要導覽，而且 field LCP 同樣不良，首頁三次都穩定辨識同一個 LCP 元素，應優先建立主視覺 LCP 待辦。理由是證據方向一致，影響範圍較大，也連到主要入口體驗。
- 內容頁 LCP 在三次 lab 測試皆超過良好門檻，檢查共用文章範本與首圖。
- 第二次 TBT 明顯升高，驗證第三方請求是否能穩定重現。
來源：Chrome Lighthouse performance scoring、Google About PageSpeed Insights與Google web.dev Web Vitals（查證 2026-10-10）。官方文件用來確認 Lighthouse 分數波動、LCP 良好門檻、lab 與 field data 的用途及限制。兩張表中的 URL、分數、指標與第三方請求均為教學假設，不代表秒站或任何客戶網站實測。
內文精華總結
- PageSpeed Insights 是什麼：PageSpeed Insights，常縮寫為 PSI，是 Google 提供的網頁效能分析工具。
- PSI 是報告入口，不是資料全部由 PSI 自己產生：白話來說，CrUX 比較像最近一段時間的實際體驗紀錄，Lighthouse 比較像在固定測試條件下重現一次頁面載入。
- CrUX 提供真實使用者資料：Google 官方目前說明，PSI 會呈現前 28 天收集期間的 FCP、LCP、CLS 與 INP，並可能顯示實驗性 TTFB 指標。
- Lighthouse 提供可重跑的實驗室診斷：PSI 的 lab data 由 Lighthouse 產生。
評估網站服務時，把效能驗收寫進需求
若正在選架站服務，可以把主要頁型、手機操作、表單與效能驗收寫進需求，先試操作再確認維護分工。採用秒站或其他平台都要以實際頁面及使用者資料驗證，不能由方案名稱保證固定 PSI 分數。
| 方案 | 首年費用 | 次年起年費 |
|---|---|---|
| 標準 | NT$24,000 | NT$12,000 |
| 專業 | NT$36,000 | NT$18,000 |
| 輕電商 | NT$48,000 | NT$24,000 |
以上依 秒站公開方案頁；網域、影片空間、金流手續費與加購模組等依需求另計。4 小時免費試用不必信用卡。匯入既有設計或外部程式前，先確認內容格式、權利、相依功能及實際服務範圍。
查看網站案例，比較與自己需求相關的內容與操作流程。
延伸閱讀
網站營運健檢系列文章
重點整理
PageSpeed Insights 是什麼？
PageSpeed Insights，常縮寫為 PSI，是 Google 提供的網頁效能分析工具。輸入公開網址後，PSI 會分別呈現行動裝置與電腦環境的資料，並把真實使用者體驗與模擬載入診斷放在同一份報告。它不是單純的「網站速度秒數測試」，也不是只看一個總分。完整報告至少要分成四層：真實使用者資料是否存在，Core Web Vitals 是否通過，這次 Lighthouse 執行呈現哪些效能指標，以及診斷項目指出哪些可能原因。
行動版與電腦版為什麼不同？
真實使用者採用的裝置與網路可能不同，處理器及視窗大小也會有差異，頁面還可能載入不同圖片或介面。Lighthouse 的行動與電腦測試同樣使用不同模擬條件。判讀時不要拿手機 lab score 直接減去電腦 field data，也不要用一邊的 URL 資料和另一邊的 origin 資料硬做比較。先確認報告標籤、資料層級與時間範圍相同，再談差異。
實際使用者資料與實驗室資料差在哪裡？
PSI 的真實使用者資料來自 CrUX。Google 官方目前說明，PSI 會呈現前 28 天收集期間的 FCP、LCP、CLS 與 INP，並可能顯示實驗性 TTFB 指標。這些資料不是今天早上改完圖片，下午就只剩新版本結果。28 天視窗會同時包含修改前後的真實體驗，而且資料每日更新時仍保留這段移動期間。因此，正式修改後要看趨勢，不能期待 field data 立刻跟單次 Lighthouse 一起翻轉。
為什麼沒有 Core Web Vitals 實際資料？
可能是指定URL與origin的CrUX樣本不足，或不符合資料呈現條件。先看報告層級與標籤。沒有field data不能證明快慢或零流量，仍可用Lighthouse及適用的真實使用者監測找線索。
LCP、INP、CLS 是什麼？
LCP衡量最大可視內容呈現，INP衡量點擊、輕觸與鍵盤互動到下一畫面的延遲，CLS取非預期位移分數最高的session window，無時間單位。三項樣本充足時第75百分位都須良好；PSI只缺INP時可依LCP與CLS判定，缺LCP或CLS則不能評估。
效能分數多少才算好？
Lighthouse 90–100 為綠色區間，但不應把單次分數當成上線或 SEO 保證。實務上先看 field Core Web Vitals 是否通過，再用 lab 分數及診斷項目找改善線索，並以多次測試和商業任務結果驗證。
為什麼每次測試分數不同？
測試裝置、網路、伺服器回應、快取、第三方資源及動態內容都可能造成波動。應在相近條件下測試多次，記錄中位數及主要差異，再判斷是穩定瓶頸或單次雜訊，不要只挑最高或最低的一次。
分數低會不會影響 SEO？
Google使用Core Web Vitals等頁面體驗訊號，但單次Lighthouse分數不是排名分數，良好分數也不保證排名。先處理可抓取性、內容相關性及真實使用者問題，再以同條件測試驗證修正。
