網站速度不只影響使用者體驗，也與 Google 搜尋排名相關。要衡量與改善效能，PageSpeed Insights（PSI） 仍是最常用的免費工具——但 2024 年後 Core Web Vitals 已從 FID 改為 INP，很多人還在用舊觀念解讀分數。

本文整理 2026 年門檻、實地數據（CrUX）與實驗室數據（Lighthouse）的差異，以及 WordPress／靜態網站各自該優先處理什麼。若你只想先動手，可直接跳到「30 分鐘優化 Checklist」。

目錄

PageSpeed Insights 是什麼

PageSpeed Insights 是 Google 提供的免費網頁效能檢測工具，輸入網址即可取得：

  1. 實地數據（Field Data）：來自 Chrome User Experience Report（CrUX），反映真實使用者在過去 28 天內的體驗。
  2. 實驗室數據（Lab Data）：由 Lighthouse 在模擬環境中跑分，適合診斷「為什麼慢」，但不等於搜尋排名依據。

重點：Google 評估 Core Web Vitals 是否達標，看的是 實地數據第 75 百分位數（p75），不是 Lighthouse 分數。Lighthouse 90 分但 CrUX 顯示「需要改善」的情況很常見。

Core Web Vitals 2026：三項指標與門檻

2024 年 3 月起，INP（Interaction to Next Paint） 正式取代 FID，成為互動性指標。目前三項 Core Web Vitals 如下：

指標衡量面向良好（Good）需要改善不佳（Poor）
LCP 最大內容繪製載入速度≤ 2.5 秒2.5–4.0 秒> 4.0 秒
INP 互動至下次繪製互動回應≤ 200 毫秒200–500 毫秒> 500 毫秒
CLS 累積版面位移視覺穩定≤ 0.10.1–0.25> 0.25

要通過 Core Web Vitals 評估，三項指標必須同時在「良好」門檻內（p75）。任一項落在「需要改善」或「不佳」，整體即視為未通過。

LCP：最大內容繪製

LCP 測量頁面主要內容（通常是 hero 圖、大標題或主要文字區塊）出現在螢幕上的時間。

常見拖慢原因：

  • 伺服器回應慢（TTFB 過高）
  • 未壓縮或未預載的大圖
  • 阻塞渲染的 CSS / JavaScript
  • 字型載入延遲

PSI 近年提供 LCP 子項目診斷（TTFB、資源載入延遲、元素渲染延遲），可快速判斷瓶頸在伺服器還是前端。

INP：取代 FID 的互動指標

舊版 FID 只量測「第一次」互動的延遲；INP 則看頁面上所有互動中最慢的一次，更能反映整體操作流暢度。

常見拖慢原因：

  • 過多或過大的 JavaScript（長任務 > 50ms）
  • 第三方腳本（廣告、追蹤、聊天外掛）
  • 主執行緒被同步運算佔用

診斷建議：用 Chrome DevTools → Performance 錄製，在手機模擬模式下點擊選單、按鈕、表單，找出最慢的互動。

CLS：累積版面位移

CLS 衡量版面在載入過程中「意外跳動」的程度，例如廣告插入、圖片沒預留高度、字型切換（FOIT/FOUT）。

修正方向：

  • 圖片與影片設定 width / height 或 aspect-ratio
  • 廣告與嵌入內容預留固定空間
  • 使用 font-display: swap 並搭配相近的 fallback 字型

實地數據 vs Lighthouse：該信哪個

實地數據（CrUX）實驗室數據（Lighthouse）
資料來源真實 Chrome 使用者模擬裝置與網路
用途判斷是否達 CWV 門檻找出具體優化項目
更新頻率約 28 天滾動窗口每次重新分析即時
新站 / 低流量站可能顯示「沒有足夠資料」仍可取得分數

實務流程：

  1. 先看 Search Console →「體驗」→ Core Web Vitals 報表（整站概況）。
  2. 對問題 URL 跑 PSI，確認實地數據哪一項未達標。
  3. 往下捲看 Lighthouse「診斷」與「建議」，逐項修復。
  4. 部署後等待 CrUX 更新（通常需數週）再驗證。

30 分鐘優化 Checklist

依影響力由高到低排列，適合多數內容型網站：

伺服器與快取（優先）

  • [ ] 啟用 HTTPS 與 HTTP/2 / HTTP/3
  • [ ] 使用 CDN 或邊緣快取
  • [ ] WordPress 站：啟用全頁快取（LiteSpeed Cache、WP Rocket 或主機內建快取）
  • [ ] 靜態站：確認託管商有邊緣快取（如 Cloudflare、Netlify）

圖片與字型

  • [ ] 轉換為 WebP / AVIF，並設定適當尺寸
  • [ ] 對 LCP 圖片使用 <link rel="preload">
  • [ ] 字型子集化，避免載入整個字型家族

JavaScript 與 CSS

  • [ ] 延遲載入非關鍵 JS（defer / async）
  • [ ] 移除未使用的 CSS 與外掛腳本
  • [ ] 審查第三方腳本（GA、廣告、社群外掛）

版面穩定

  • [ ] 所有媒體元素預留尺寸
  • [ ] 避免在首屏上方動態插入橫幅

WordPress 站的常見路徑

若你使用 WordPress，效能優化通常分三層：

  1. 主機：優先選支援 HTTP/2／HTTP/3、物件快取，或 LiteSpeed／同等高效 Web Server 的方案。
  2. 快取外掛：全頁快取、圖片 WebP／延遲載入、CSS／JS 延遲；Guest Mode 類功能可加速未登入訪客。
  3. 內容：精簡外掛、媒體庫定期清理「尚無關聯」圖檔（先備份）、避免首屏塞過多第三方腳本。

若考慮脫離 WordPress 的維護成本，可參考 WordPress vs Eleventy 的遷移經驗——靜態站天生在 LCP 與 INP 上有結構優勢。遷移內容時可用 eleventy-import（或先從 WP 匯出 WXR 再轉換）。

轉址與重複內容（簡記）

  • 改版或刪文後，用主機 Redirects／.htaccess 做 301，避免 404 流失權重。
  • 多篇搶同一關鍵字時，合併成一篇支柱文並把舊 URL 301 過來，比硬留薄文更有效。

工具對照表

工具類型適合用途
PageSpeed Insights實地 + 實驗室單頁快速檢測
Google Search Console實地（整站）監控通過率與問題 URL
Chrome DevTools → Performance實驗室深入追蹤 INP / 長任務
web-vitals JS 函式庫自訂 RUM送 GA4 做長期監控

常見迷思

Q：Lighthouse 滿分就代表 SEO 沒問題？
A：不一定。Lighthouse 是實驗室環境；排名相關的是 CrUX 實地數據。兩者都要看。

Q：FID 還會出現在 PSI 嗎？
A：部分舊報表或診斷可能仍提及 FID，但 Core Web Vitals 評估已改用 INP。優化時以 INP 為準。

Q：新站沒有 CrUX 資料怎麼辦？
A：先用 Lighthouse 修到合理分數，上線累積流量後再依 Search Console 調整。流量極低的頁面可能長期沒有實地數據，這是正常現象。

Q：改完多久才會在 PSI 看到改善？
A：Lighthouse 即時反映；CrUX 實地數據通常需 數週 才會更新。

結語

2026 年解讀 PageSpeed Insights 的關鍵字是：實地數據優先、INP 取代 FID、三項同時達標。先把 LCP 與伺服器/快取处理好，再處理 JavaScript 對 INP 的影響，最後補 CLS 的版面預留——這個順序在多數部落格與內容站上最省時間。

若你的 WordPress 站 LCP 長期卡在「需要改善」，先從主機快取與圖片著手；若已考慮遷移靜態站，本站 11ty 入門教學 可作為下一步參考。