你是否曾經用 PageSpeed Insights 測試 WordPress 網站，看見手機版分數一片紅，接著安裝快取外掛、壓縮圖片，分數卻沒有明顯改善？問題往往不是「網站不夠快」這麼簡單，而是你還沒確認讀者真正遇到的是載入慢、點擊沒反應，還是頁面一直亂跳。
Core Web Vitals 是 Google 用來衡量真實使用體驗的一組指標，主要包含 LCP、INP 與 CLS。簡單來說，它們分別觀察主要內容何時出現、操作多久有回應，以及版面是否穩定。改善這三項指標不能只靠一鍵加速，而要先找出是哪一種體驗出了問題，再對症處理。
快速結論：
- LCP 不佳，優先檢查首屏封面、伺服器回應、快取與關鍵 CSS。
- INP 不佳，優先檢查 JavaScript、第三方追蹤碼、頁面編輯器與重型外掛。
- CLS 不佳，優先檢查圖片尺寸、廣告／嵌入區塊及網頁字型。
- 不必執著 PageSpeed 得到 100 分，應先讓真實使用者的主要頁面穩定達標。
Core Web Vitals 與 SEO 有什麼關係？
Google 將 Core Web Vitals 納入整體頁面體驗的評估，但它不是讓網站直接衝上第一名的按鈕。內容是否符合搜尋需求、資訊是否可信，依然比單一速度分數更重要。換句話說，一篇沒有解決問題的文章，不會因為載入快就自然超越內容完整的競爭頁面。
不過，當兩個頁面的內容品質相近時，速度快、操作順、版面穩定的網站更容易留住讀者。效能優化的價值也不只在排名，而是降低讀者還沒看到內容就離開的機率。
Google 建議以行動版與桌面版各自第 75 百分位的真實使用資料判斷是否達標。也就是說，不能只拿自己辦公室裡的一次測試代表所有訪客，而要觀察多數使用者長期遇到的體驗。
LCP：主要內容多久才出現？
LCP（Largest Contentful Paint，最大內容繪製） 衡量畫面中最大主要元素完成顯示的時間，良好門檻是 2.5 秒以內。在 WordPress 文章頁，LCP 元素很常是封面圖片、大型 Hero 圖，或首屏的大段文字區塊。
如果封面使用數 MB 的原始 PNG，又被設定成延遲載入，瀏覽器直到很晚才發現並下載它，LCP 自然會被拖長。常見改善方式包括：
- 將封面轉成適當壓縮的 WebP 或 AVIF。
- 提供符合顯示尺寸的圖片與
srcset，不要讓手機下載桌機大圖。 - 首屏封面通常不要使用 lazy loading，並讓瀏覽器能在 HTML 早期找到它。
- 啟用頁面快取、物件快取或 CDN，縮短伺服器與資源回應時間。
- 減少阻擋首屏的 CSS、字型與外部資源。
但也不要看到 LCP 慢就把所有圖片都設成預載。預載太多資源會互相搶頻寬，反而延後真正重要的封面與樣式。重點是找出每種頁面模板的 LCP 元素，而不是套用同一張優化清單。
INP：點擊後多久才有反應？
INP（Interaction to Next Paint，互動至下一次繪製） 衡量使用者點擊、觸控或鍵盤操作後，頁面多久呈現下一個畫面。良好門檻是 200 毫秒以內。當讀者打開選單、切換頁籤或送出表單，畫面停頓一下才反應，通常就是 INP 問題。
WordPress 最常見的原因不是 PHP 本身，而是瀏覽器主執行緒被大量 JavaScript 占住。例如功能重疊的外掛、複雜頁面編輯器、廣告程式、聊天室、熱圖、社群嵌入與多套追蹤碼，都可能同時在訪客裝置上執行。
改善 INP 可以依序進行：
- 盤點外掛與第三方程式，移除沒有實際價值或功能重複者。
- 將非必要 JavaScript 延後到互動後或頁面穩定後載入。
- 拆解長時間工作，避免一次運算占住主執行緒太久。
- 簡化行動版選單、篩選器、輪播及複雜動畫。
- 使用 Chrome DevTools 或 PageSpeed Insights 找出最慢的互動與腳本來源。
外掛數量多不一定代表網站慢，一個設計不良的外掛也可能比十個簡單外掛更重。因此不要只看安裝數量，而要看它在前台載入了什麼資源、影響哪些頁面。
CLS：為什麼內容載入時一直跳動？
CLS（Cumulative Layout Shift，累積版面配置位移） 衡量頁面在非預期情況下移動的程度，良好分數為 0.1 以下。最典型的狀況是讀者正準備點選一個連結，上方廣告或圖片突然出現，把按鈕往下推，結果點到別的位置。
WordPress 常見 CLS 來源包括：
- 圖片、影片與 iframe 沒有設定寬高或比例。
- Cookie 通知、廣告及促銷橫幅載入後才插入頁面。
- 網頁字型載入前後尺寸差異太大。
- 輪播、推薦文章或留言模組未預留空間。
處理方法很直觀：先為媒體與嵌入內容保留固定比例，讓瀏覽器在檔案下載前就知道需要多少空間；動態區塊也應事先保留位置。字型則要選擇接近的備援字型，並避免一次載入過多字重。
三項指標該先改善哪一個？
| 指標 | 良好門檻 | WordPress 常見原因 | 優先檢查 |
|---|---|---|---|
| LCP | ≤ 2.5 秒 | 大型首圖、慢主機、阻擋資源 | 封面圖片、快取、伺服器、關鍵 CSS |
| INP | ≤ 200 毫秒 | JavaScript、第三方腳本、重型外掛 | 互動元件、外掛、追蹤碼、長工作 |
| CLS | ≤ 0.1 | 圖片無尺寸、動態橫幅、字型切換 | 寬高屬性、預留空間、字型策略 |
不要同時改十件事。先從 Search Console 的 Core Web Vitals 報告找出問題頁面群組，再以 PageSpeed Insights 檢視代表頁面。Search Console 偏向真實使用者長期資料；PageSpeed Insights 也提供實驗室診斷，適合定位當下可能的技術原因。兩者用途不同，不能只看其中一個總分。
建議優先順序是：先處理大量頁面共同使用的模板問題，再處理單篇文章。若所有文章頁都載入同一個超大封面尺寸或同一套重型腳本，修正模板的收益會遠高於逐篇微調。
快取外掛為什麼不是萬靈丹？
快取能減少伺服器重複運算、縮短文件回應時間，也能協助壓縮與合併資源，因此是 WordPress 效能的重要基礎。但快取無法自動修好沒有尺寸的圖片，也無法保證第三方 JavaScript 立即回應。
WordPress 官方效能文件 也將改善分成硬體、軟體、快取、內容卸載、壓縮與資料庫調校等不同層面。這代表網站速度是整個系統共同作用的結果：主機回應、佈景主題、外掛、圖片與前端程式都需要一起檢查。
若安裝快取外掛後分數仍不理想，不要立刻再裝第二套。先確認目前瓶頸屬於 LCP、INP 還是 CLS，再選擇對應工具，才能避免外掛互相衝突又沒有解決核心問題。
結語：先找瓶頸，再談滿分
Core Web Vitals 最有價值的地方，不是把複雜的網站濃縮成一個分數，而是把使用者的不耐煩拆成三種可以量測的問題：看不到主要內容、操作沒有反應，以及版面不斷跳動。
對 WordPress 網站來說，建議先挑選首頁、文章頁、分類頁與流量最高的內容各一頁進行測試，再找出影響最多頁面的共同原因。LCP 從首屏資源下手，INP 從 JavaScript 與互動元件下手，CLS 則從尺寸與預留空間下手。做到這一步，即使 PageSpeed 沒有顯示漂亮的 100 分，網站也會比盲目安裝加速外掛更穩、更快，讀者感受到的改善也更真實。
