網站速度在過去幾年從「錦上添花」變成排名的必要條件，這個轉變不是突然發生的。Google 在 2021 年正式將核心網頁指標（Core Web Vitals，CWV）納入搜尋排名訊號，從那之後，伺服器回應時間、視覺穩定性這些以往只有開發者在意的數字，成了每位站長都得追蹤的指標。
數據面同樣清楚。根據 Google 的 Chrome 使用者體驗報告（Chrome UX Report，CrUX），首次載入在 2.5 秒內的頁面，跳出率平均比 5 秒以上的頁面低 22%。換句話說，速度同時作用在兩個地方——一邊影響爬蟲的抓取配額與排名評估，另一邊直接影響真實使用者的停留意願。
本文的焦點放在三件事：CWV 三項指標與排名的實際連動、如何讀懂 PageSpeed Insights 給的數據，以及優化時該優先處理哪些項目。
CWV 三項指標怎麼影響排名
核心網頁指標目前涵蓋三個量測面向，分別對應載入速度、互動反應、視覺穩定性。Google 將這三項整合成一個「通過／未通過」的門檻評估，未通過的頁面在競爭相近的結果中會被往後排列。
最大內容繪製（LCP）——速度感知的主要來源
最大內容繪製（Largest Contentful Paint，LCP）測量的是頁面主視覺元素——通常是英雄圖、大標題或橫幅圖片——從瀏覽器開始載入到出現在畫面上的時間。Google 的門檻是 2.5 秒以內為「良好」，超過 4 秒屬於「待改善」。
LCP 之所以被選為指標，在於它最接近使用者心理上感受到的「頁面載入完成」時間點。技術上的完整載入可能更晚，但使用者在主視覺出現後就會開始判斷要不要繼續留下。影響 LCP 的主要因素有兩個：伺服器首次回應時間（TTFB）偏慢，以及圖片本身缺乏尺寸最佳化。
互動延遲（INP）——點擊沒反應的代價
互動至下次繪製（Interaction to Next Paint，INP）在 2024 年 3 月取代了舊指標首次輸入延遲（First Input Delay，FID），成為正式的 CWV 組成項目。INP 量測的是整個工作階段中，使用者點擊、鍵盤輸入、觸控等互動行為到畫面更新之間的最長延遲時間，門檻是 200 毫秒以內。
FID 只量第一次互動，INP 量的是全程最差情況，這讓標準嚴格許多。常見的 INP 問題來源是 JavaScript 主執行緒阻塞——當頁面同時執行第三方廣告腳本、追蹤像素、聊天小工具時，使用者的點擊指令必須排隊等候，延遲感就從這裡產生。
累積版面位移（CLS）——畫面跳動的排名懲罰
累積版面位移（Cumulative Layout Shift，CLS）量測的是頁面載入過程中，元素非預期移動的總幅度。門檻是 0.1 以下。
CLS 問題最常出現在廣告位置、嵌入影片、外部字型三個地方。廣告框在載入前未預留空間，字型切換造成行高變化，這些都會讓段落或按鈕突然往下位移，使用者若在那個瞬間按下去，很可能觸及不想點的元素。Google 的邏輯是，視覺不穩定的頁面等同於糟糕的使用體驗，CLS 失分會連帶拉低整體 CWV 評估。
如何讀懂 PageSpeed Insights 與 CrUX 數據
PageSpeed Insights（PSI）是診斷頁面速度最直接的入口，但它提供的數字有兩個來源，混著解讀很容易誤判。
PSI 報告分成兩塊。上半部是「實際使用者資料」，來自 CrUX——這是 Chrome 瀏覽器收集的真實使用者體驗樣本，以過去 28 天的 75th 百分位數呈現，也就是 Google 搜尋排名實際參考的數值。下半部是「Lighthouse 模擬數據」，由工具在受控環境下模擬載入，用於找出技術改善點，但不等同於真實排名依據。
常見的誤判情境是：Lighthouse 分數達到 90 分以上，但 CrUX 的 LCP 仍顯示「需要改善」。這通常代表實際用戶的環境——低階手機、3G 網路、地理位置偏遠——比 Lighthouse 的模擬條件差許多。優化工作應以 CrUX 的實際數值為準，Lighthouse 的分項診斷只是找問題的工具。
CrUX 三個欄位的判讀重點
PSI 的實際使用者資料以色彩區分三個區間。
- 綠色（良好）：低於門檻，這部分的使用者佔比以百分比顯示，達到 75% 以上才算全站通過
- 橘色（需要改善）：介於良好與差之間，有改善空間但尚未構成嚴重排名壓力
- 紅色（差）：超過臨界值，每多一個百分比都在拖累整體評估
單看分數條不夠，要同時看行動裝置與桌面裝置兩份報告。許多站台桌面版通過、行動版亮紅燈，但 Google 現行採行動優先索引，行動版才是排名的主要依據。
Google Search Console 的 CWV 總覽
除了單頁診斷，Google Search Console 提供全站的 CWV 健康度彙總，按照頁面分組列出「差」和「需要改善」的 URL，能快速定位問題集中在哪類頁面——首頁、分類頁、文章頁各有不同的優化優先序。
圖片壓縮與延遲載入的優化邏輯
圖片是絕大多數 WordPress 站台 LCP 分數偏高的第一原因，也是最容易取得改善效益的項目。
格式轉換，從 JPEG 換到 WebP
WebP 在同等視覺品質下，檔案大小平均比 JPEG 小 25% 至 35%，比 PNG 則可能縮減 50% 以上。WordPress 從 5.8 版起原生支援 WebP 上傳，大多數現代快取外掛也能自動轉換，沒有理由繼續沿用 JPEG。
轉換流程可走外掛自動處理，也可以在上傳前用 Squoosh 或 ImageOptim 壓縮再上傳。兩種做法的差異在於：外掛轉換會保留原始檔並佔用空間，上傳前壓縮則更為乾淨，但需要手動步驟。站台規模小、圖片量不大時，上傳前處理反而更易掌控。
設定正確的尺寸，不讓瀏覽器縮圖
常見的問題是，用 CSS 把一張 1,920 × 1,080 像素的圖縮到 600 像素寬顯示，瀏覽器仍需下載完整解析度的檔案。修正方式有兩個：在 WordPress 媒體設定裡確保縮圖尺寸涵蓋實際顯示尺寸，或在 <img> 標籤使用 srcset 屬性，讓瀏覽器依裝置解析度選擇合適版本。
延遲載入（Lazy Loading）的適用範圍
延遲載入（Lazy Loading）讓畫面以外的圖片等到使用者捲動靠近時再下載，對長文章頁效果明顯。WordPress 從 5.5 版起預設對圖片加上 loading="lazy" 屬性，大多數情況不需要額外設定。
需要注意的是，首屏最大圖片——也就是 LCP 對應的那張——不應該套用延遲載入，否則會延後 LCP 時間。確認方式是在 PSI 的 Lighthouse 診斷中找「Largest Contentful Paint element」，確認那張圖沒有 loading="lazy"。
伺服器回應時間的優化優先項
LCP 的上半場在伺服器端，在第一個 HTML byte 送達瀏覽器之前，使用者只能等待。首位元組時間（Time to First Byte，TTFB）的 Google 門檻是 800 毫秒以內。
以下是優化 TTFB 時應按優先序處理的項目。
- 啟用頁面快取：WordPress 的 PHP 每次請求都要查詢資料庫組合頁面，快取外掛將組合好的 HTML 存起來，後續請求直接送出靜態檔案，TTFB 可以從數百毫秒壓縮至數十毫秒。常用選項包括 WP Rocket、LiteSpeed Cache（需搭配 LiteSpeed 伺服器）、W3 Total Cache。
- 採用 CDN 分散傳輸：內容傳遞網路（CDN）讓靜態資源從距離使用者最近的節點傳送，台灣訪客取得的資料來自台灣或東亞節點，而非遠端主機機房。Cloudflare 的免費方案對多數小型站台已足夠。
- 確認主機規格與資源狀況：共用虛擬主機在高峰時段 TTFB 不穩定，是常見卻容易忽視的問題。若快取已開、CDN 已設，但 TTFB 仍偶發超標，可考慮升級至虛擬專屬伺服器（VPS）或向主機商確認資源限制情況。
JavaScript 瘦身對 INP 的影響
INP 問題九成以上來自 JavaScript 主執行緒過載，而 WordPress 站台的 JS 膨脹往往不是主題造成的，而是外掛。每個外掛幾乎都會在全站載入自己的腳本，不論該頁面是否用得到。
診斷工具是 Chrome DevTools 的「效能（Performance）」面板。錄製一次頁面互動後，在「主執行緒」軌道找紅色標記的「長任務（Long Task）」——超過 50 毫秒的任務就算長任務，INP 問題通常是幾個長任務疊加的結果。
改善方向有三個。
- 移除未使用的外掛腳本：用 Query Monitor 外掛確認各外掛在每個頁面分別載入了哪些資源，非必要者選擇性停用，或改用不帶前端腳本的替代方案
- 延後非關鍵腳本載入：在
<script>標籤加上defer或async屬性，讓追蹤像素、熱圖工具、聊天小工具等不影響首次互動的腳本，在主執行緒空閒時再執行 - 控制第三方嵌入的時機：YouTube 嵌入、Google Maps、Facebook 讚好按鈕各自帶來大量第三方腳本。改用點擊後載入的「外觀替代圖」（facade）技術，讓使用者主動點擊才觸發真正的嵌入，可以大幅降低初次載入的 JS 負擔
整體 INP 的改善節奏是先診斷再刪減，不要為了數字好看就全面停用外掛——有些功能直接影響轉換率，停用得不償失。按長任務大小排序，優先處理貢獻最多延遲的一兩個腳本，往往可以用兩成的工夫解決八成的問題。