網站速度像咖啡溫度：太慢才送到，客人已經走了；太快變冷，又會懷疑你是不是只端了杯空氣。PageSpeed Insights（PSI） 能幫你看網站到底慢在哪裡，但它的分數不是一張「SEO 畢業證書」。

這篇以 2026 年仍適用的 Core Web Vitals 定義為基準，帶你分清 PSI 的實地資料與 Lighthouse 實驗室資料，理解 LCP、INP、CLS 三項指標，最後用一份可執行的檢查清單處理 WordPress 或靜態網站。讀完後，你會知道先修哪裡，也知道哪些綠色數字不必追到凌晨。

目錄

PageSpeed Insights 到底在測什麼

PageSpeed Insights 是 Google 的網頁效能分析工具。輸入公開網址後，它通常會提供兩種資料：

  1. 實地資料（Field Data）：來自 Chrome User Experience Report（CrUX），反映真實使用者在不同裝置與網路上的經驗。
  2. 實驗室資料（Lab Data）：由 Lighthouse 在固定的模擬環境中載入頁面，提供診斷與改善建議。

兩者回答的問題不同。實地資料回答「使用者最近用起來如何」，實驗室資料回答「在這次模擬裡，可能是哪個環節拖慢」。所以一次測試出現兩組不同數字，不是 PSI 在跟你玩猜謎，而是測量對象本來就不同。

CrUX 在 PSI 中使用過去 28 天的彙整資料，且每天更新 PSI 顯示的資料。新頁面或流量不足的網址，可能沒有網址層級資料，改顯示來源（origin）資料，甚至完全沒有資料。這不代表頁面一定很快或很慢，只代表目前樣本不足。

2026 年 Core Web Vitals 門檻

截至 2026 年，Core Web Vitals 仍是三項指標：

指標看什麼良好（Good）需要改善不佳（Poor）
LCP 最大內容繪製主要內容載入≤ 2.5 秒> 2.5–4 秒> 4 秒
INP 互動至下次繪製互動回應≤ 200 毫秒> 200–500 毫秒> 500 毫秒
CLS 累積版面位移畫面穩定≤ 0.1> 0.1–0.25> 0.25

這些門檻要用**實地資料的第 75 百分位數（p75）**來看，並且 LCP、INP、CLS 三項都達到 Good，才算通過 Core Web Vitals 評估。評估通常會依裝置類型分開呈現，因此手機與桌面可能得到不同結果。

Core Web Vitals 確實會被 Google 搜尋排名系統使用，但它只是整體頁面體驗的一組訊號；內容相關性、行動版體驗、安全性等也都重要。換句話說，Lighthouse 變綠不會自動把文章送上第一名，Google 沒有販售那種「滿分直達車」。

LCP：主要內容何時出現

LCP 衡量載入開始後，頁面主要內容元素完成繪製所需的時間。這個元素可能是大圖、標題或主要文字區塊，實際對象要看頁面內容。

遇到 LCP 過慢，先在 PSI 的 LCP 診斷中拆解時間，通常可從這幾個方向查：

  • 伺服器回應：TTFB 過高，瀏覽器連 HTML 都還沒拿到。
  • 資源載入：LCP 圖片太大、格式不合適，或真正的 LCP 資源太晚才被發現。
  • 渲染阻塞：CSS、同步 JavaScript 或字型延後了主要內容的繪製。
  • 元素渲染：資源已到位，但主執行緒仍忙著處理其他工作。

修正順序不要一看到圖片就全面 preload。先確認哪個元素是 LCP，再確保它的尺寸與格式合理；只有確定是關鍵資源且瀏覽器發現得太晚時，才考慮預載。預載太多東西，就像把所有客人都叫成 VIP，最後沒人真的被優先服務。

INP：FID 的接班人

FID（First Input Delay） 只看頁面第一次互動的輸入延遲；INP（Interaction to Next Paint） 會觀察頁面生命週期中的點擊、點按與鍵盤互動，評估從互動開始到瀏覽器能繪製下一幀的延遲。INP 因此更能反映使用者操作過程中的整體回應性。

INP 常見問題包括：

  • JavaScript 太多，主執行緒被長任務塞滿。
  • 事件處理函式做了過多同步工作。
  • 第三方分析、廣告或聊天工具在關鍵時刻搶走資源。
  • 互動開始時瀏覽器仍在處理載入工作。

可以先用 Chrome DevTools 的 Performance 錄製常見流程，例如開啟選單、送出表單、切換分頁。測試時不要只在頁面完全閒置後點按，也要在載入期間操作；真正的慢，常常躲在大家以為「等一下就好了」的那幾秒。

Lighthouse 在沒有真實互動的情況下，不能完整代表 INP。若實驗室工具提供 TBT（Total Blocking Time），它可以協助找出主執行緒阻塞問題，但 TBT 不是 INP 的替代品。

CLS：不要讓畫面自己搬家

CLS 衡量頁面生命週期中非預期的版面位移。使用者正要按按鈕，畫面卻突然往下跳，這不叫互動設計，叫按鈕在玩躲貓貓。

常見原因與修正方式如下：

  • 圖片、影片或 iframe 沒有預留尺寸：設定 width、height 或 aspect-ratio。
  • 廣告、嵌入內容在載入後才插入：預留容器空間，避免把既有內容往下推。
  • 字型替換造成文字重新排版：選擇尺寸相近的 fallback，並依需求調整字型載入策略。
  • 動畫改變版面幾何尺寸：優先使用不會觸發重新排版的 transform。

實地資料與 Lighthouse，應該先看哪個

答案取決於你要回答的問題：

  • 想知道真實訪客是否達標：先看 PSI 的 CrUX 資料或 Search Console 的 Core Web Vitals 報表。
  • 想知道可能的瓶頸：看 Lighthouse 的診斷、瀑布圖與效能細節。
  • 想追蹤改版後的實際影響：建立自己的 RUM（Real User Monitoring），因為 CrUX 是彙整資料，未必提供足夠的互動情境細節。

一個實用流程是：

  1. 先在 Search Console 查看整站的問題網址與裝置分布。
  2. 對代表性網址執行 PSI，記下 LCP、INP、CLS 的 p75 與資料來源。
  3. 用 Lighthouse 找出可操作的線索，再用 DevTools 重現問題。
  4. 一次處理一個主要瓶頸，部署後再比較同一網址、同一裝置類型的結果。
  5. 等待實地資料的滾動視窗反映變化，再判斷修正是否真的有效。

如果頁面沒有 CrUX 資料，就先用 Lighthouse 與自己的監測建立基準；不要把「沒有資料」誤讀成「已經 Good」。

30 分鐘優化 Checklist

以下順序適合內容型網站。它不是保證所有網站都有效的魔法咒語，但能讓你少一點亂改、多一點證據。

前 10 分鐘：先找主要瓶頸

  • [ ] 記下 PSI 的 Field Data 與 Lab Data，確認自己沒有混看。
  • [ ] 確認 LCP 元素是什麼，以及 LCP 時間主要花在伺服器、資源或渲染哪一段。
  • [ ] 找出 INP 最慢的互動；沒有互動資料時，先用 TBT 與 Performance trace 找長任務。
  • [ ] 開啟頁面錄影或 DevTools Layout Shift 診斷，找出 CLS 的位移來源。

接著 10 分鐘：處理載入與版面

  • [ ] 壓縮 LCP 圖片，提供符合顯示尺寸的 WebP、AVIF 或其他合適格式。
  • [ ] 為圖片、影片與 iframe 預留尺寸。
  • [ ] 移除不必要的渲染阻塞資源；不要未確認原因就把所有資源都 defer 或 async。
  • [ ] 檢查伺服器回應時間、快取標頭與 CDN 設定，依實際主機能力調整。

最後 10 分鐘：處理互動與驗證

  • [ ] 移除不必要的 JavaScript 與第三方腳本。
  • [ ] 將非關鍵工作拆小，避免一次執行很久的同步任務。
  • [ ] 用真實常見流程測試選單、搜尋、表單與按鈕。
  • [ ] 部署後重新測試，並保留前後數字與測試條件。

WordPress 與靜態網站，優先順序有何不同

WordPress 的效能問題常分布在主機、佈景主題、外掛與內容四層。可以依序檢查：

  1. 主機與快取：確認 HTML 是否有全頁快取、伺服器回應是否穩定，以及 CDN 是否真的命中快取。
  2. 佈景主題與外掛：停用不必要的功能，檢查它們是否載入不需要的 CSS、JavaScript 或第三方資源。
  3. 媒體與內容：調整圖片尺寸與格式，避免首屏塞入太多輪播、影片或外部嵌入。
  4. 驗證：不要只看外掛的「最佳化完成」通知，回到 PSI、DevTools 與實地監測確認結果。

靜態網站通常少了一層伺服器端內容生成，但不代表自動得到好分數。大型圖片、未拆分的 JavaScript、字型載入與第三方腳本，仍然可以把 LCP 或 INP 拉慢。你可以參考本站的 WordPress 與 Eleventy 比較 了解架構差異；若要實際遷移內容，再看 Eleventy 匯入教學。

改版、刪文或換網址時，也要處理正確的 301 轉址，避免讀者與搜尋引擎撞上 404。這件事不屬於 Core Web Vitals，但網站體驗不只是一張效能成績單。

工具怎麼分工

  • PageSpeed Insights：快速查看單一網址的 Field Data 與 Lighthouse Lab Data。
  • Google Search Console：查看網站層級的 Core Web Vitals 問題與網址群組。
  • Chrome DevTools Performance：錄製載入與互動，找出長任務、主執行緒阻塞與渲染瓶頸。
  • web-vitals：在自己的 RUM 系統中收集與 Google 工具一致的 Web Vitals 指標。

常見迷思

Lighthouse 90 分以上，就代表 SEO 沒問題？

不是。Google 文件將 Lighthouse 分數視為實驗室測量結果；搜尋系統會使用 Core Web Vitals，但頁面體驗還包含其他訊號，內容品質與相關性也不會因為分數變綠就消失。

FID 還需要優化嗎？

截至 2026 年，Core Web Vitals 的互動指標是 INP。舊文章、舊儀表板或歷史報表可能仍出現 FID，但新的效能檢查應以 INP 與造成它的實際互動為主。

沒有 CrUX 資料，是不是網站太慢？

不一定。公開網址仍需要足夠的匿名樣本才能產生資料。新站、低流量頁面或未被收錄的網址，都可能沒有 URL 層級資料；請先用 Lighthouse 與自有 RUM 觀察。

改完馬上重跑 PSI，就能判斷成功嗎？

Lighthouse 可以很快反映一次模擬結果，但 Field Data 是過去 28 天的滾動彙整。立刻重跑可以確認部署沒有出錯，不能單獨證明所有真實使用者都已改善。

結語

2026 年看 PSI，先記住三件事：Field Data 看真實體驗、Lighthouse 找診斷線索、Core Web Vitals 以 LCP、INP、CLS 的 p75 為準。修正時先找瓶頸，再做小幅變更，最後用相同條件驗證；這比追著每一個綠色圓圈跑更可靠。

如果你的 WordPress 站 LCP 長期卡在需要改善，先從伺服器回應、快取與主要圖片開始；如果你正在評估靜態站，本站的 11ty 入門教學 可以接著看。網站慢的時候先別急著怪咖啡，咖啡至少不會偷偷載入三十支第三方腳本。

參考資料