PageSpeed Insights 怎麼用？2026 網站速度報告數據解讀

PageSpeed Insights 是什麼？可以幫網站檢查什麼

PageSpeed Insights 是 Google 提供的免費網頁效能檢測工具，可以檢查單一網址在行動版與桌機版的載入速度、Core Web Vitals、使用者體驗與改善建議。

PageSpeed Insights 是 Google 的免費網站效能檢測工具

使用 PageSpeed Insights 時，只要輸入網址，工具就會產生一份報告，顯示該頁面的真實使用者資料與 Lighthouse 實驗室測試結果。對網站經營者來說，它最有價值的地方不是給你一個漂亮分數，而是指出哪個環節正在拖慢網頁載入。

以網站建置與 SEO 實務來看，陳建宏會先把 PSI 當成「單頁診斷工具」使用。首頁、產品頁、文章頁、分類頁、廣告落地頁都應該分開測，因為每一種頁面的圖片、版型、追蹤碼和互動元件都不同。

它不只看速度，也會顯示 Accessibility、Best Practices、SEO

PSI 報告主要包含 Performance、Accessibility、Best Practices、SEO 等類別。Performance 是多數人最在意的網站速度分數，但其他類別也能提醒你是否有替代文字、連結可辨識性、安全性或基本 SEO 標記問題。

• Performance：檢查載入速度、互動延遲、版面穩定度。
• Accessibility：檢查無障礙與可讀性相關問題。
• Best Practices：檢查安全性、瀏覽器相容與常見網頁品質問題。
• SEO：檢查搜尋引擎能否理解頁面基本結構。

PSI 適合誰使用？

網站老闆可以用它判斷分數低是否需要處理，SEO 與行銷人可以用它和 Google Search Console 的 Core Web Vitals 報告對照，工程師或外包窗口則可以從報告中的診斷項目回推技術原因。官方說明可參考 Google PageSpeed Insights 說明。

PageSpeed Insights 怎麼用：從輸入網址到查看報告

使用 PageSpeed Insights 的流程是輸入網址、等待分析、切換行動版與桌機版，接著依序查看真實使用者資料、效能分數、Core Web Vitals 與改善建議。

輸入網址並執行分析

進入 PageSpeed Insights 後，把要檢查的完整網址貼上，例如首頁、文章頁或商品頁。按下分析後，系統會針對該頁面產生報告。不要只測首頁，這是台灣中小企業網站常見誤判來源，因為真正帶來排名與轉換的頁面，常常是文章頁、服務頁或商品頁。

先切換行動版，再看桌機版

台灣多數網站流量都會有大量手機使用者，因此行動版結果通常要優先看。桌機版分數漂亮，不代表手機使用者體驗良好。若你的主要流量來自廣告、社群或自然搜尋，手機版的 LCP、INP、CLS 更應該列為第一輪檢查重點。

報告主要分成哪些區塊？

PSI 報告可以先照這個順序看，不必一開始就鑽進每個技術細項。

1. 看 Core Web Vitals assessment 是否通過。
2. 看 Field Data 是否有真實使用者資料。
3. 看 Lab Data 中 LCP、TBT、CLS 哪個最差。
4. 看 Opportunities 與 Diagnostics 提出的改善方向。
5. 改完後用同一個網址重新測試，並和 GSC 長期資料對照。

PSI 報告中的 Field Data 和 Lab Data 差在哪

Field Data 是真實 Chrome 使用者過去一段時間的體驗資料，Lab Data 是 Lighthouse 在受控環境下的單次測試資料；前者看長期體驗，後者用來除錯。

Field Data：真實 Chrome 使用者資料

Field Data 來自 Chrome UX Report，也就是 CrUX。它反映真實使用者在手機或桌機上瀏覽頁面時的體驗，PSI 會呈現 FCP、LCP、INP、CLS 等指標，並以最近 28 天資料作為判讀基礎。若網站流量不足，某些網址可能不會顯示 CrUX 單頁資料。

Lab Data：Lighthouse 即時測試資料

Lab Data 來自 Lighthouse，它會在受控測試環境中模擬頁面載入，產出 Performance 分數、FCP、LCP、TBT、CLS、Speed Index 等數據。它很適合找出當下頁面是否有大圖、阻塞 CSS、過多 JavaScript 或第三方追蹤碼問題。

兩者衝突時該相信誰？

兩者衝突很常見。我的判斷是：要評估真實使用者體驗與 SEO 風險，先看 Field Data；要找修正方向與驗證修改，先看 Lab Data。

看長期使用者體驗時，優先看 Field Data

Field Data 較接近 Google Search Console 的 Core Web Vitals 判讀脈絡，適合用來看網站是否真的讓使用者感到慢、卡或跳動。

找技術原因與立即驗證時，優先看 Lab Data

Lab Data 可以在每次修改後立刻重測，適合工程師或網站維護者用來比對修正前後差異。

項目	Field Data	Lab Data
資料來源	CrUX 真實使用者資料	Lighthouse 實驗室測試
時間範圍	最近 28 天	單次測試
適合用途	判斷長期體驗與搜尋風險	找技術原因與立即驗證
常見限制	流量不足時可能沒有資料	每次測試可能受環境影響

2026 版 Core Web Vitals 怎麼看：LCP、INP、CLS

2026 年判讀 Core Web Vitals 時，核心指標是 LCP、INP、CLS；LCP 看主要內容出現速度，INP 看互動反應，CLS 看畫面穩定度。

LCP：主要內容多久出現

這代表什麼：LCP 衡量頁面主要內容區塊出現在畫面上的時間，常見對象是首屏大圖、主標題區或主要商品圖。依 web.dev 的 Core Web Vitals 建議，LCP 在 2.5 秒內屬於良好。

常見原因：圖片太大、伺服器回應慢、首屏 CSS 阻塞、首頁輪播或主視覺載入過重。

怎麼判斷：在 PSI 的 LCP 元素提示中，看被標記的元素是圖片、文字區塊還是背景圖，再決定要壓縮圖片、改載入順序或處理主機反應。

INP：互動反應是否延遲

這代表什麼：INP 衡量使用者點擊、輸入或操作後，頁面多久能完成下一次畫面更新。INP 在 200 毫秒內屬於良好。

常見原因：JavaScript 太多、第三方追蹤碼阻塞、表單或選單互動太重、前端框架初始化成本過高。

怎麼判斷：若使用者點選選單、篩選器、加入購物車或表單欄位時感到卡頓，就要把 INP 列為高優先項目。

CLS：畫面是否突然跳動

這代表什麼：CLS 衡量頁面載入過程中非預期版面位移，0.1 以下屬於良好。

常見原因：圖片沒有預留尺寸、廣告區塊後載、字型載入造成文字重排、動態元件插入頁面上方。

怎麼判斷：打開頁面時如果標題、按鈕、商品卡突然往下跳，或使用者準備點擊時位置改變，就可能是 CLS 問題。

為什麼現在要看 INP，不是 FID？

FID 已不是現行 Core Web Vitals 的核心判讀重點。INP 取代 FID 後，更能反映整個頁面生命週期中的互動反應，而不是只看第一次互動。官方 Core Web Vitals 指標可參考 web.dev Web Vitals。

指標	判讀重點	良好參考值	常見商業影響
LCP	主要內容出現速度	2.5 秒內	影響第一印象、跳出率、廣告落地頁體感
INP	互動反應速度	200 毫秒內	影響表單、購物流程、選單與篩選操作
CLS	版面穩定度	0.1 以下	影響誤點、信任感與閱讀流暢度

其他常見數據怎麼解讀：FCP、TTFB、TBT、Speed Index

FCP、TTFB、TBT、Speed Index 是輔助判讀指標，可以幫你分辨問題在伺服器、前端資源、JavaScript 阻塞，還是視覺載入速度。

指標	這代表什麼	常見原因	怎麼判斷
FCP	第一個文字或圖片內容出現時間	CSS 阻塞、字型載入慢、首批資源太大	頁面空白太久時優先檢查
TTFB	伺服器開始回應的時間	主機慢、後端查詢慢、快取未啟用	所有頁面都慢時先看它
TBT	主執行緒被阻塞多久	JavaScript 過重、第三方碼太多	Lab Data 中用來輔助判斷互動卡頓
Speed Index	畫面內容顯示速度	首屏資源載入順序不佳、圖片過重	視覺上慢慢浮出內容時檢查

分數低要先改什麼？用 PSI 判斷改善優先順序

PSI 分數低時，先處理影響真實使用者、Core Web Vitals、轉換流程與修正成本低的問題，不要直接把 100 分當成唯一目標。

很多網站分數低，真正該先處理的不是所有紅字，而是最靠近使用者痛點的位置。電商站先看商品頁與結帳流程，形象官網先看首頁與服務頁，內容站先看帶來自然搜尋流量的文章頁。

優先級	判斷條件	常見任務	適合誰處理
第一優先	影響 LCP、INP、CLS 且發生在主要流量頁	壓縮首屏圖片、修正版面位移、減少阻塞 JavaScript	網站維護者或工程師
第二優先	修正容易且會改善多數頁面	啟用快取、移除多餘外掛、整理第三方追蹤碼	站長、行銷、維護者
第三優先	需要較大改版或重構	重整前端架構、替換過重版型、調整後端查詢	工程團隊

指標、常見原因、修法與驗證方式對照表

PSI 最有用的做法，是把指標對應到原因、修法與驗證方式；這能讓報告從一堆數字變成可執行的修正清單。

LCP 問題常見原因

LCP 通常和首屏主要內容有關。台灣企業官網常見問題是首頁大圖未壓縮、輪播載入太多張圖、背景圖比實際顯示尺寸大很多。

INP 問題常見原因

INP 常見於外掛多、追蹤碼多、互動元件複雜的網站。WordPress 若同時裝了頁面編輯器、彈窗、聊天工具、熱圖和多組廣告追蹤碼，互動延遲很容易惡化。

CLS 問題常見原因

CLS 多半來自版面沒有預留空間。廣告、嵌入內容、圖片、字型和上方通知列，都可能讓使用者正在閱讀或點擊時畫面突然移動。

TTFB、FCP、TBT 如何輔助判斷

TTFB 偏高時先看主機與後端；FCP 偏慢時看首批資源；TBT 偏高時看 JavaScript；Speed Index 偏差時看首屏視覺載入順序。

指標	常見原因	修法方向	驗證方式
LCP	首屏圖片過大、主機回應慢、CSS 阻塞	改用 WebP 或 AVIF、壓縮圖片、預載主要圖片、啟用 CDN	重測 PSI，確認 LCP 元素與時間是否下降
INP	JavaScript 過重、第三方碼阻塞、互動元件複雜	延後非必要腳本、拆分任務、移除低價值外掛	觀察 Field Data，並用互動操作測試卡頓是否改善
CLS	圖片無尺寸、廣告後載、字型重排	設定圖片寬高、保留廣告空間、調整字型載入策略	重新整理頁面錄影，確認畫面是否仍跳動
FCP	空白畫面太久、CSS 與字型阻塞	精簡首批 CSS、優化字型、減少首屏非必要資源	看 FCP 與 Speed Index 是否同步改善
TTFB	主機慢、快取不足、資料庫查詢慢	啟用頁面快取、檢查主機資源、優化後端查詢	多測幾個頁面，確認是否整站都下降
TBT	主執行緒被 JavaScript 長時間占用	減少第三方碼、延後載入、拆分大型腳本	看 Lab Data 的 TBT 是否下降，並檢查 INP 走勢

非工程師可以先做的 10 件 PageSpeed 改善事項

非工程師也能先處理圖片、外掛、追蹤碼、快取、字型與主機這幾類問題，通常能先改善一批明顯的 PageSpeed 問題。

事項	怎麼做	主要影響
壓縮首屏圖片	把過大的主視覺與商品圖改成適當尺寸	LCP、Speed Index
改用 WebP 或 AVIF	在不影響清晰度下使用較小圖片格式	LCP、FCP
移除不用的 WordPress 外掛	刪掉重複、停用後無影響的外掛	INP、TBT
整理第三方追蹤碼	檢查 GTM、廣告、熱圖、聊天工具是否必要	INP、TBT
啟用快取	使用主機或網站快取功能	TTFB、FCP
檢查主機反應時間	若多頁 TTFB 都慢，評估主機資源	TTFB、LCP
減少首頁輪播	保留最重要的一張主視覺即可	LCP、CLS
避免上方插入式公告	公告列要預留高度，不要載入後才推動內容	CLS
控管字型數量	減少字重與外部字型載入	FCP、CLS
優先測重要頁面	首頁、核心服務頁、商品頁、流量文章分開測	決策品質

PageSpeed Insights 對 SEO、轉換率和使用者體驗有什麼影響

PageSpeed Insights 不會保證排名上升，但 Core Web Vitals、載入速度與互動體驗會影響搜尋表現、跳出率、廣告落地頁品質與轉換率。

SEO 上，PageSpeed Insights 應該和 Core Web Vitals、Google Search Console、實際排名與轉換資料一起看。若頁面內容薄弱、搜尋意圖不符，只把分數從 70 拉到 95，通常不會解決排名核心問題。

轉換率上，速度問題更直接。電商商品圖慢、加入購物車卡頓、結帳頁版面跳動，會讓使用者中斷操作。廣告落地頁如果首屏太慢，付費流量可能還沒看到主訊息就離開。

實務判斷上，我會把 PSI 當成體驗風險指標。它指出問題方向，但最後仍要回到使用者是否能順利閱讀、比較、填表、下單或聯絡。

PSI 分數一定要追到 100 嗎？哪些情況不用過度優化

PSI 分數不一定要追到 100；只要核心頁面通過主要體驗指標，且沒有明顯阻礙轉換或搜尋表現的問題，就不必為了分數犧牲功能。

盲目追 100 分常會讓團隊做錯事。例如把必要的客服工具、表單驗證、電商追蹤或 A/B 測試全部移除，分數可能提高，但商業判斷變差。分數是工具，不是網站經營目標。

以下情況可以不用過度優化：

• Field Data 已通過 Core Web Vitals，只有單次 Lab Data 波動。
• 差距來自必要第三方功能，例如付款、客服或廣告轉換追蹤。
• 修正成本很高，但頁面不是主要流量或轉換頁。
• 使用者實測流暢，排名與轉換也沒有速度相關異常。

真正該追的是穩定、可讀、可操作的體驗。尤其是電商與廣告落地頁，90 分且流程順暢，通常比 100 分但功能被砍得不完整更有價值。

PSI、Google Search Console 和持續監控怎麼搭配

PSI 適合診斷單一頁面，Google Search Console 適合追蹤整站 Core Web Vitals 狀態；兩者搭配才能建立持續改善流程。

Google Search Console 的 Core Web Vitals 報告會依行動版與桌機版呈現 URL 群組狀態，並使用真實使用者資料。官方說明提到修正驗證會進入 28 天監控期，可參考 Search Console Core Web Vitals 報告。

階段	使用工具	要看什麼	決策動作
發現問題	Google Search Console	哪些 URL 群組為 Poor 或 Needs Improvement	挑出主要流量頁與模板類型
單頁診斷	PageSpeed Insights	LCP、INP、CLS、TBT、TTFB	找出具體技術原因
修正驗證	PSI 與瀏覽器實測	Lab Data 是否改善，畫面是否仍跳動	確認可上線
長期回歸	Google Search Console	28 天資料是否逐步轉好	判斷修正是否真的反映到真實使用者

若網站剛改版，建議把首頁、主要服務頁、重要文章頁、商品頁與結帳頁列成固定檢查清單。和 CMS 選擇、主機架構、電商轉換設計 一起評估，會比單看分數更接近真實決策。

常見限制：為什麼同一頁每次測出來不一樣

同一頁每次 PSI 結果不同，通常是因為 Lab Data 是單次測試，會受測試環境、網路、伺服器狀態、第三方資源與快取狀態影響。

PSI 並不是壞掉。它同時呈現真實使用者資料與實驗室資料，而這兩種資料本來就會有差異。Field Data 反映一段期間的使用者體驗，Lab Data 反映當下測試環境。若你的網站有廣告、社群嵌入、外部字型、GTM 或聊天工具，波動更明顯。

常見原因包括：

• CrUX 樣本不足，單一網址沒有足夠真實使用者資料。
• PSI 顯示 page-level 或 origin-level 資料，判讀範圍不同。
• 單次 Lighthouse 測試遇到伺服器忙碌或第三方資源延遲。
• 快取有時命中、有時未命中。
• 行動版與桌機版測試條件不同。

比較合理的做法，是同一頁測 2 到 3 次看趨勢，再回頭看 GSC 的 28 天真實使用者資料。若每次都顯示同一類問題，例如 LCP 元素固定是首頁大圖，那就不用再懷疑工具，應該處理問題本身。

PageSpeed Insights 是免費的嗎？

是，PageSpeed Insights 是 Google 提供的免費工具。一般使用者可以直接在網頁上輸入網址檢查，工程團隊也可以透過 PageSpeed Insights API 做自動化查詢。

PageSpeed Insights 分數多少才算好？

PSI 的 Performance 分數通常以 90 到 100 視為良好，50 到 89 代表需要改善，49 以下代表較差。不過決策時不要只看總分，應同時看 LCP、INP、CLS 是否影響主要頁面。

PageSpeed Insights 的手機版和電腦版要看哪一個？

多數台灣網站應優先看手機版，尤其是自然搜尋、社群、廣告流量占比較高的網站。桌機版仍要檢查，但手機體驗通常更接近實際使用情境。

Field Data 和 Lab Data 不一樣時該相信哪個？

判斷長期使用者體驗時，優先看 Field Data；找技術原因與立即驗證時，優先看 Lab Data。兩者用途不同，不應用單一數字直接下結論。

為什麼我的網站沒有 CrUX 真實使用者資料？

通常是該網址或網站在 CrUX 中沒有足夠樣本。新網站、流量較小的頁面、剛上線的內容頁，都可能只顯示 Lab Data，而沒有完整 Field Data。

PageSpeed Insights 分數會直接影響 Google 排名嗎？

PSI 分數本身不是保證排名的開關。Google 會使用頁面體驗相關訊號，但內容品質、搜尋意圖、權威性、內部連結與技術可索引性仍然很重要。

INP 是什麼？為什麼現在不再主要看 FID？

INP 是 Interaction to Next Paint，用來衡量使用者互動後頁面完成反應的速度。它比 FID 更能反映整個瀏覽過程的互動品質，因此 2026 年判讀 Core Web Vitals 時應以 INP 為核心互動指標。

PSI 分數一定要做到 100 分嗎？

不一定。若核心頁面體驗良好、主要指標通過、轉換流程順暢，就不需要為了追 100 分移除必要功能。分數應服務於使用者體驗與商業目標。

WordPress 網站 PageSpeed 分數低通常要先檢查什麼？

先檢查圖片尺寸、快取設定、外掛數量、頁面編輯器載入資源、第三方追蹤碼與主機反應時間。WordPress 的速度問題常常不是單一原因，而是多個小問題累積。

電商網站最應該優先改善哪個速度指標？

電商網站通常優先看 LCP、INP 與 CLS。商品頁首屏圖片要快，加入購物車與篩選互動要順，結帳頁不能因版面跳動造成誤點或中斷。

PageSpeed Insights 可以取代負載測試工具嗎？

不可以。PSI 是單頁效能與使用者體驗診斷工具，不能模擬大量使用者同時進站。若要測高流量活動、秒殺、會員系統或結帳尖峰，仍需要專門的負載測試。

改完網站速度後，要多久才會反映在 Google Search Console？

Google Search Console 的 Core Web Vitals 報告使用真實使用者資料，通常需要累積一段時間才會反映。官方驗證流程會觀察 28 天資料，所以不要期待修改後隔天就完整轉綠。