~/blog/wordpress-core-web-vitals-lcp-cls-fid-optimization-guide.md
網站效能與架構優化 · 2025 / 07 / 22

網站跑分不及格？Google Core Web Vitals 完整指南：LCP/CLS/FID 調教實戰，讓你的 WordPress 速度原地起飛！

Eric — 浪花科技創辦人 / AI 架構師
Eric
浪花科技創辦人 · AI 架構師
網站跑分不及格？Google Core Web Vitals 完整指南：LCP/CLS/FID 調教實戰，讓你的 WordPress 速度原地起飛！
☰ 目錄 table-of-contents.md

Core Web Vitals 怎麼救？重點先看

Core Web Vitals 量的其實只有三件事：載入快不快（LCP）、版面穩不穩（CLS）、點了有沒有反應（FID/INP）。WordPress 網站跑分不及格，元兇九成九逃不出圖片與伺服器拖慢 LCP、元素沒預留尺寸造成 CLS、過量 JavaScript 卡住主執行緒拉高 FID/INP 這三件事。這篇完整指南給你每個指標的合格門檻、常見元兇，以及可以直接照做的調教步驟，讓你的 WordPress 速度原地起飛。

這份指南由浪花科技整理。許多網站主被「網站為什麼這麼慢」困住，看著一堆紅色分數無從下手。Core Web Vitals 已經是 Google 的 SEO 排名因素之一，效能直接影響搜尋能見度。與其裝個快取外掛就自我安慰，不如從根本把網站體質調好——下面我們一項一項動手。

什麼是 Core Web Vitals？為什麼 Google 把它納入排名？

Core Web Vitals（網站體驗核心指標）是 Google 用來量化「使用者實際感受」的一組指標。它不再只看頁面從頭到尾載入完要多久，而是更細膩地分析使用者在瀏覽過程中的體驗。核心由三個指標組成：

  • LCP（Largest Contentful Paint，最大內容繪製）：衡量「載入效能」——使用者進到頁面後，看到最大塊的圖片或文字區塊需要多久。時間越短，使用者覺得網站「打開得越快」。
  • CLS（Cumulative Layout Shift，累計版面配置轉移）：衡量「視覺穩定性」。正在閱讀時突然跳出廣告把內容往下推、害你找不到剛才讀到哪，就是版面配置轉移。CLS 分數越低，頁面越穩定。
  • FID / INP（First Input Delay / Interaction to Next Paint，首次輸入延遲／互動延遲）：衡量「互動性」。使用者第一次點按鈕或輸入時，網站要多久才有反應。FID 已逐漸被更全面的 INP 取代，INP 會衡量整個瀏覽過程中的所有互動延遲。

重點就是：Google 希望使用者在網路上有好的體驗，所以會獎勵提供良好體驗的網站更高的排名。Core Web Vitals 已經不是「加分題」，而是「必考題」。

三個指標的合格門檻一次看懂

為了避免逐項描述時混淆，先把目標值整理成一張表。下列門檻為 Google 公開定義的「良好（Good）」標準：

指標衡量什麼良好門檻
LCP載入效能2.5 秒以內
CLS視覺穩定性低於 0.1
FID首次輸入延遲低於 100 毫秒
INP互動延遲（FID 的後繼指標）低於 200 毫秒

實驗室數據 vs. 真實使用者數據，差在哪？

動手前要先建立一個觀念：你看到的分數有兩種來源，兩者不一定一致。

  • 實驗室數據（Lab data）：在固定的模擬環境裡跑一次，例如 Lighthouse、PageSpeed Insights 的模擬區塊。適合開發階段反覆偵錯，但不代表真實使用者的體驗。
  • 真實使用者數據（Field data）：來自真實造訪者的瀏覽器回報，例如 PageSpeed Insights 上方的實地報告、Google Search Console 的核心指標報告。Google 用來判斷 SEO 排名的是這一類資料，它反映的是過去一段期間內真實使用者的整體表現。

實務上的差異很重要：實驗室分數很漂亮、但真實數據不及格的情況很常見（例如你的網路很快，但多數使用者在行動網路上）。所以優化做完後，別只看實驗室分數就收工，要回到 Search Console 觀察一段時間，確認真實數據也跟著改善。

LCP 調教：別讓使用者盯著白畫面發呆

LCP 的目標是 2.5 秒內。超過這個數字，使用者很可能在主要內容出現前就失去耐心。LCP 不佳通常是幾個元兇造成的：伺服器反應太慢、CSS/JS 阻礙渲染，或是英雄區塊（Hero Section）那張超大圖片載入太久。

如何找出拖慢 LCP 的元兇？

用 Google PageSpeed Insights 測試你的網址，報告中會明確標出「最大內容繪製元素」是哪一個。通常不是首圖，就是最大的標題文字。鎖定目標後，再對症下藥。

理解 LCP 的內部組成會讓優化更有方向。一個元素被「畫出來」之前，瀏覽器要依序經過四個階段，任何一段過長都會拉高 LCP：

  1. TTFB（首位元組時間）：從瀏覽器發出請求，到收到伺服器第一個位元組的時間。對應的是主機與後端處理速度。
  2. 資源載入延遲：瀏覽器發現了 LCP 圖片，但因為被其他資源排擠、或太晚才知道要下載而拖延的時間。
  3. 資源載入時間：真正下載 LCP 圖片所花的時間，取決於檔案大小與網路。
  4. 元素渲染延遲：資源到齊後，因為主執行緒忙著跑 JS、或還在等 CSS 解析而無法立即畫出來的時間。

換句話說，LCP 不只是「圖片大小」的問題，而是貫穿伺服器、網路與前端渲染的整條鏈路。

LCP 實戰優化技巧

  • 終極圖片優化：這是最常見也最有效的項目。確保 LCP 元素（若是圖片）被妥善處理：
    • 使用現代格式：將圖片轉為 WebP 或 AVIF，檔案大小能有效減少約 30% 以上，畫質卻差不多。
    • 正確的圖片尺寸：不要上傳一張 4000px 寬的圖片，卻只在 800px 寬的容器裡顯示——這是在浪費頻寬與等待時間。請依顯示尺寸裁切。
    • 預載入（Preload）關鍵圖片：對一定會出現在首屏的 LCP 圖片，可以告訴瀏覽器優先下載。這需要在 <head> 區塊手動加入 link 標籤，或用 Perfmatters 這類外掛處理。
    • 避免對首屏圖片使用 Lazy Load：延遲載入是好技術，但千萬別用在 LCP 圖片上！這會讓它更晚載入，LCP 分數直接爆炸。
  • 優化伺服器回應時間（TTFB）：TTFB 是瀏覽器發出請求後、收到伺服器第一個位元組所需的時間。
    • 啟用頁面快取：這是 WordPress 速度優化的基本盤。用 WP Rocket 或 LiteSpeed Cache 等外掛，把動態產生的頁面存成靜態 HTML，大幅減少伺服器處理時間。
    • 使用物件快取（Object Cache）：對複雜或高流量網站，啟用 Redis 或 Memcached 可快取資料庫查詢結果，減輕資料庫負擔，TTFB 會非常有感。
    • 選擇優質主機與 CDN：別再用那些便宜的共享主機，效能跟不上神仙也難救。投資好主機，並搭配像 Cloudflare 這樣的 CDN，讓全球使用者都能從最近的節點載入資源。
  • 消除渲染阻礙資源：瀏覽器渲染頁面時，遇到 CSS 或 JS 檔案會停下來等它下載並執行完畢。
    • 關鍵 CSS（Critical CSS）：把首屏所需的最小 CSS 直接內嵌進 HTML 的 <head>，讓頁面能馬上被渲染，其餘 CSS 改用非同步方式載入。這有點複雜，但 WP Rocket 等效能外掛通常有一鍵生成功能。

CLS 調教：終結頁面跳動的惱人體驗

CLS 的理想分數是低於 0.1。這就像看報紙看到一半，有人硬從中間抽走一張，整個版面都亂掉——誰受得了？Google 也受不了。CLS 過高通常是因為圖片、廣告或 iframe 等元素在載入後才確定尺寸，導致頁面內容「跳動」。

CLS 的常見罪魁禍首

  • 未指定尺寸的圖片或影片：這是大多數 CLS 問題的來源。若 <img> 沒有明確的 width 與 height 屬性，瀏覽器一開始不知道要留多大空間，只好等圖片載入後再把空間「撐開」，造成版面位移。
  • 動態插入的內容：後來才載入的廣告橫幅、Cookie 同意橫幅，如果沒有預留空間，出現時就會推擠現有內容。
  • 網頁字型載入（FOIT/FOUT）：字型載入時可能先用系統預設字型顯示，等客製字型載入完再替換。若兩種字型尺寸差異太大，文字區塊就會閃爍或位移。

CLS 實戰優化技巧

  • 為所有媒體元素加上尺寸屬性：這是最簡單也最重要的步驟。確保所有 <img> 和 <iframe> 都包含 width 與 height。WordPress 5.5 之後會自動為後台新增的圖片補上這些屬性，但舊內容、或佈景主題／外掛產生的圖片可能仍需手動檢查。 
    <!-- 錯誤示範 -->
<img src="example.jpg" alt="一個會造成CLS的圖片">

<!-- 正確示範 -->
<img src="example.jpg" width="1200" height="800" alt="一個穩定的圖片">
    小提醒：只要 HTML 帶有正確的 width 與 height，瀏覽器就能依寬高比預先保留空間，即使你用 CSS 把圖片設成 max-width: 100% 做響應式縮放也不會破壞效果。
  • 為動態內容預留空間：如果你知道某處會載入一個 300×250 的廣告，就先用 CSS 設一個 min-height: 250px; 的容器把它框起來。這樣即使廣告晚一點才出現，也不會影響下方內容。
  • 優化字型載入：在 CSS 的 @font-face 規則中加入 font-display: swap;，讓瀏覽器在客製字型載入完成前先用備用字型顯示，減少空白時間。同時可預載入（Preload）重要的字型檔案，讓它們更早被下載。

FID 與 INP 的崛起：讓互動如絲般滑順

FID 的目標是低於 100 毫秒，新的 INP 標準則是 200 毫秒。使用者點了按鈕、結果網站像當機一樣沒反應，這體驗差到不行。問題的根源，幾乎都指向萬惡的 JavaScript：當瀏覽器的主執行緒（Main Thread）忙著執行冗長的 JS 時，它就沒空理會使用者的點擊或輸入。

為什麼 INP 比 FID 更難對付？

理解兩者差別，才知道優化方向為何要轉變。

  • FID 只量「第一次」：它記錄使用者第一次互動時、瀏覽器要等多久才開始處理。多半發生在頁面剛載入、JS 還在大量執行的那一刻。
  • INP 量「整個瀏覽過程」：它會觀察使用者在整個頁面停留期間的所有互動（點擊、點按、鍵盤輸入），並回報其中偏慢的延遲。也就是說，頁面載入後的任何一次卡頓都算數。

這代表只把載入瞬間調順是不夠的——你得確保按鈕、選單、表單這類事後互動的回應同樣即時，優化重心要從「載入期」延伸到「整個生命週期」。

是什麼卡住了你的主執行緒？

過多、未經優化的 JavaScript 是主要元兇，包括華麗的動畫效果、複雜的第三方追蹤碼（Google Analytics、Facebook Pixel）、客服聊天外掛，或處理大量資料的前端運算。

FID/INP 實戰優化技巧

  • 延遲／非同步載入 JavaScript：不是所有 JS 都需要在頁面一開始就載入。非必要的腳本可以加上 defer 或 async。defer 會讓腳本在 HTML 解析完畢後才按順序執行，async 則是下載完就立刻執行。一般來說 defer 較安全、較推薦。你可以用以下程式碼片段加到 functions.php，自動為所有 JS 加上 defer（請小心測試，某些外掛可能因此出錯）： 
    function add_defer_attribute_to_scripts($tag, $handle) {
    // 排除特定不需要 defer 的腳本，例如 jQuery
    if ('jquery-core' === $handle) {
        return $tag;
    }
    return str_replace(' src', ' defer src', $tag);
}
add_filter('script_loader_tag', 'add_defer_attribute_to_scripts', 10, 2);
  • 拆分長任務（Code Splitting）：如果有一個非常巨大的 JS 檔案，試著拆成多個小檔案，只在需要時才載入對應模組。這需要打包工具（如 Webpack）的協助，對客製化開發的專案來說是重要的優化方向。
  • 減少第三方腳本：每多一個第三方腳本，就多一個你無法控制的效能風險。審視一下你的網站，真的需要那麼多追蹤碼和外部工具嗎？有時候，少即是多。

從零開始：一套可照做的優化流程

把上面的技巧串起來，整理成一個可重複執行的流程。每次改完一輪，就回頭重測一次。

  1. 量測現況：用 PageSpeed Insights 測試代表性的頁面（首頁、文章頁、產品頁各一），同時看實驗室與真實數據，記下三個指標的起點分數。
  2. 定位瓶頸：找出 LCP 元素是誰、CLS 是哪些元素在跳、哪些 JS 拉長了互動延遲，鎖定影響最大的前幾項。
  3. 從成本低、影響大的先做：通常是「圖片轉 WebP/AVIF＋裁切尺寸」「補齊 width/height」「啟用頁面快取」「非必要 JS 加 defer」。
  4. 處理架構層：再進一步啟用物件快取、調整主機與 CDN、生成關鍵 CSS。
  5. 回測與觀察：重測實驗室分數確認沒倒退，再到 Google Search Console 觀察一段時間，確認真實數據跟著改善。

提醒：每次只動一兩個變數再重測，否則出問題時你會分不清是哪一項造成的。

總結：效能優化是一場永無止盡的旅程

調教 Core Web Vitals 不是裝個外掛就一勞永逸的事。它需要你像偵探一樣，用工具找出瓶頸、理解背後原因，再對症下藥。從 LCP 的載入速度、CLS 的視覺穩定性，到 FID/INP 的互動流暢度，每一步優化都是為了提供使用者更棒的體驗。

記住，網站效能優化是一個持續的過程。每次新增功能或內容後，都應重新檢視這些指標。雖然過程有點繁瑣，但當你看到 PageSpeed Insights 上漂亮的綠色分數，以及隨之而來的 SEO 排名提升與使用者滿意度，你會發現一切努力都值得。

覺得這些技術細節太過複雜，或需要專業協助來徹底檢測並優化你的 WordPress 網站嗎？在浪花科技，我們專精於 WordPress 網站的深度效能調校與架構優化。與其自己花大量時間摸索，不如讓我們的專家團隊為你提供最有效的解決方案。

👉 立即聯繫浪花科技，讓我們為你的網站進行專業健檢，打造兼具速度與使用者體驗的頂尖網站！

延伸閱讀

// FAQ

常見問題

Core Web Vitals 包含哪些指標，合格門檻各是多少？
Core Web Vitals 由三個面向組成：LCP（最大內容繪製）衡量載入效能，良好門檻為 2.5 秒以內；CLS（累計版面配置轉移）衡量視覺穩定性，良好門檻為低於 0.1；互動性方面，FID（首次輸入延遲）良好門檻為低於 100 毫秒，其後繼指標 INP（互動延遲）則為低於 200 毫秒。這些已是 Google 的 SEO 排名因素之一。
PageSpeed Insights 的實驗室數據與真實使用者數據差在哪？
實驗室數據（Lab data）是在固定模擬環境跑一次的結果，如 Lighthouse 或 PageSpeed Insights 的模擬區塊，適合開發階段反覆偵錯，但不代表真實體驗。真實使用者數據（Field data）來自真實造訪者瀏覽器的回報，如 PageSpeed Insights 的實地報告與 Search Console 的核心指標報告，Google 用來判斷排名的正是這一類。優化後應回到 Search Console 觀察一段時間，確認真實數據也改善。
如何優化 WordPress 的 LCP（最大內容繪製）？
先用 PageSpeed Insights 找出「最大內容繪製元素」是哪個（常是首圖或最大標題文字）再對症下藥。常見有效做法包括：把圖片轉成 WebP 或 AVIF、依顯示尺寸裁切圖片、對首屏 LCP 圖片做預載入（Preload）、千萬別對 LCP 圖片用 Lazy Load；同時優化 TTFB，例如啟用頁面快取、物件快取（Redis/Memcached）、選用優質主機並搭配 CDN，並消除阻礙渲染的 CSS/JS。
造成 CLS（版面跳動）的常見原因有哪些，如何解決？
常見原因有三：圖片或影片未指定尺寸、後來才動態插入的廣告或 Cookie 橫幅沒預留空間、網頁字型載入時的替換造成位移。解決方式是替所有 <img> 與 <iframe> 補上 width 與 height 屬性，為已知尺寸的動態內容預留容器空間（如 min-height），並在 @font-face 加入 font-display: swap 並預載入重要字型。
圖片加了 width 和 height，做響應式縮放會不會被破壞？
不會。只要 HTML 帶有正確的 width 與 height，瀏覽器就能依寬高比預先保留版面空間，避免載入後撐開造成位移；即使用 CSS 把圖片設成 max-width: 100% 做響應式縮放，效果也不會被破壞。WordPress 5.5 之後會自動為後台新增的圖片補上這些屬性，但舊內容或佈景主題、外掛產生的圖片可能仍需手動檢查。
~/roamer-tech/newsletter // FREE
// newsletter

訂閱免費電子報

把 AI 自動化、企業系統設計與 WordPress / Laravel 開發的真實案例和可直接照做的技巧，整理成電子報寄給你。只寄精選內容、不灌垃圾信，一鍵就能退訂。

$
// final.exec()

準備好讓你的網站開始為你工作了嗎？

免費 30 分鐘諮詢 → 看作品