~/blog/wordpress-core-web-vitals-lcp-cls-fid-optimization-guide-2.md

網站效能與架構優化 · 2025 / 07 / 16

網站跑分滿江紅？拆解 Core Web Vitals，LCP/CLS/FID 調教實戰全攻略

Eric

浪花科技創辦人 · AI 架構師

網站跑分滿江紅？拆解 Core Web Vitals，LCP/CLS/FID 調教實戰全攻略

☰ 目錄 table-of-contents.md

為什麼換了主機、裝了快取外掛，PageSpeed Insights 還是一片紅？因為紅字幾乎都集中在 Core Web Vitals 三大指標——LCP（載入）、CLS（穩定）、FID/INP（互動），方向沒抓對，再多外掛也是白裝。要把分數從紅轉綠，路線其實很明確：LCP 顧伺服器回應時間與最大元素的圖片載入策略、CLS 替所有會撐開版面的元素事先預留空間、FID/INP 則想辦法別讓 JavaScript 把主執行緒塞滿。本文用工程師實戰的角度，逐項拆解每個指標的成因與可立即動手的修法。

身為一個天天跟 WordPress 程式碼打交道的工程師，最常被客戶問到的問題之一，大概就是：「Eric，為什麼我的網站用 Google PageSpeed Insights 測出來分數這麼難看？一片紅字，是不是網站快掛了？」

每次看到客戶傳來的滿江紅報告，我都能感受到那份焦慮。但別擔心，這篇文章就是要帶你撥開迷霧，深入理解這些分數背後的意義，並動手進行 WordPress 速度優化。我們不談那些虛無飄渺的理論，只講能讓你網站「有感」變快的實戰技巧，特別是針對 Google 最在意的三大指標：LCP、CLS、和 FID。

說真的，網站效能優化已經不是選修課，而是必修學分了。它不僅僅是為了討好 Google 的演算法，更是為了尊重每一位訪客寶貴的時間。一個卡頓、遲緩的網站，只會讓使用者毫不猶豫地按下上一頁。好了，囉嗦完畢，我們捲起袖子，開始幹活吧！

什麼是網站體驗核心指標 (Core Web Vitals)？為什麼 Google 這麼在意？

首先，我們得搞懂到底在跟誰「作戰」。Core Web Vitals（簡稱 CWV）是 Google 提出來的一組指標，用來衡量使用者在網頁上的實際體驗。你可以把它想像成 Google 派出的秘密客，專門評估你網站的「待客之道」。它主要由三個核心成員組成：

LCP (Largest Contentful Paint) — 最大內容繪製：使用者進到頁面後，畫面上「最大塊」的圖片或文字區塊需要多久才能完整顯示。這代表使用者感知到的「載入速度」。
CLS (Cumulative Layout Shift) — 累計版面配置位移：你有過這種經驗嗎？正要點擊一個按鈕，突然一個廣告或圖片載入把按鈕擠下去，結果點到別的東西。這種惱人的「畫面跳動」就是 CLS 在測量的東西，它代表「視覺穩定性」。
FID (First Input Delay) — 首次輸入延遲：當使用者第一次與頁面互動（例如點擊連結、按按鈕）時，瀏覽器需要多久才能開始處理這個動作。這代表網站的「互動性」。

最近 Google 也開始推廣 FID 的接班人——INP (Interaction to Next Paint)，它衡量的是整個互動過程的延遲，比 FID 更全面。但別緊張，優化 FID 的基本功，同樣能為 INP 打下良好基礎。

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

有一個觀念一定要先建立：你在 PageSpeed Insights 上看到的數字，其實分成兩類，這也解釋了為什麼很多人「測一次紅、測一次綠」覺得很玄。

實驗室數據 (Lab Data)：由工具在一個受控環境中模擬載入所得到的，每次條件固定、可重現，適合用來除錯。但它測不到 FID（因為實驗室裡沒有真人去點擊），通常會用「總阻塞時間 (Total Blocking Time, TBT)」當作互動性的替身指標。
真實使用者數據 (Field Data)：來自實際造訪你網站的使用者，反映他們在各種裝置、各種網路下的真實體驗。Google 在評估搜尋排名時看的是這一類資料，而它需要累積一段時間的流量才會穩定。

換句話說，實驗室數據用來找問題、驗證修法是否有效；真實使用者數據才是 Google 真正拿來打分的依據。修完之後別急著看一次跑分就下結論，真實數據需要時間反映改善。

為什麼這些指標這麼重要？因為 Google 已經公開表示，Core Web Vitals 是搜尋排名的因素之一。也就是說，一個使用者體驗好的網站，更有機會獲得好的排名。這就是為什麼我們必須嚴肅看待 WordPress 速度優化：LCP / CLS / FID 調教 這件事。

LCP 拖垮速度？Largest Contentful Paint 優化實戰

LCP 通常是效能報告中最顯眼的紅字來源。一個理想的 LCP 時間應該在 2.5 秒以內。如果你的網站超過 4 秒，那使用者大概已經等到不耐煩了。LCP 過慢，通常代表你的「第一印象」很差。

LCP 的時間其實是好幾段加起來的

很多人以為 LCP 慢就是「圖片太大」，但實際上一張 LCP 圖片從使用者點進來到完整顯示，中間至少經過四個階段，每一段都可能是瓶頸：

第一個位元組之前的等待 (TTFB)：瀏覽器送出請求，到伺服器吐出第一個位元組的時間。主機慢，這段就慢。
資源載入延遲：從拿到 HTML 到瀏覽器「發現」並開始下載 LCP 資源之間的空窗。如果 LCP 圖片藏在 CSS 背景裡，或要等 JavaScript 跑完才插進來，這段就會被拉長。
資源載入時間：實際下載這張圖片本身花的時間，跟檔案大小、格式、CDN 直接相關。
元素繪製延遲：圖片下載完到實際畫上螢幕的時間，通常受到渲染阻塞的 CSS／JS 影響。

把 LCP 拆成這四段之後，優化策略就很清楚了：前面兩段靠主機與資源提示，後面兩段靠圖片優化與解除渲染阻塞。

揪出 LCP 的元兇：到底誰是那個「最大」的元素？

動手優化前，得先找到問題點。你可以使用 Google PageSpeed Insights 報告，它會明確告訴你哪個元素是 LCP 元兇。通常不是首圖 (Hero Image)，就是大標題。在 Chrome 開發者工具 (DevTools) 的「Performance」面板中，你也可以錄製頁面載入過程，找到 LCP 事件，確認是哪個元素。

LCP 優化四大絕招

找到元兇後，我們就可以對症下藥了。以下是我在實務中最常用的幾招：

1. 優化伺服器回應時間 (TTFB)：地基不穩，蓋什麼樓都危險。如果你的主機本身反應就慢（Time to First Byte, TTFB 過長），後面的優化做得再好都沒用。這也是我最常跟客戶囉嗦的一點：拜託不要再用那些便宜到不可思議的共享主機了！選擇一個優質的 WordPress 主機、設定頁面快取 (Page Caching)、使用 CDN 服務，是降低 TTFB 的根本之道。
2. 圖片優化是重中之重：LCP 元素十之八九是圖片。請務必做到：
- 正確的尺寸：不要上傳一張 4000px 寬的圖片，卻只在 800px 寬的欄位顯示。這是在謀殺使用者的流量和耐心。
- 有效的壓縮：使用像 TinyPNG 這樣的工具，在不犧牲太多畫質的前提下，大幅減少圖片檔案大小。
- 現代化的格式：盡量使用 WebP 或 AVIF 格式，它們的壓縮效率遠高於傳統的 JPG 或 PNG。
3. 延遲載入非關鍵 CSS 與 JavaScript：瀏覽器在渲染頁面時，如果遇到 CSS 或 JS 檔案，會停下來等它們下載並執行完畢，這就是所謂的「渲染阻塞 (Render-blocking)」。我們需要讓關鍵的 CSS（也就是讓頁面首屏能看的樣式）優先載入，而非關鍵的 CSS 和 JavaScript 則可以延後。許多快取外掛都有提供這類功能，或者你也可以手動為 script 標籤加上 defer 屬性。
```
<script src="my-script.js" defer></script>
```
4. 預載入 (Preload) 關鍵資源：對於 LCP 元素（例如那張最重要的首圖），我們可以給瀏覽器一個「提示」，告訴它：「嘿！這個資源很重要，請優先下載！」這可以透過在 <head> 中加入 <link rel="preload"> 來實現。
```

<link rel="preload" as="image" href="/path/to/your-lcp-image.webp">
```

進階一招：用 fetchpriority 直接告訴瀏覽器誰最重要

除了 preload，還有一個更精準的工具：fetchpriority 屬性。瀏覽器在載入初期會自己替資源排優先序，但它不一定猜得對你的首圖。直接在 LCP 圖片上標明高優先權，可以讓它在一堆資源裡插隊先下載；反過來，對於首屏看不到的圖片，標成低優先權能把頻寬讓給更重要的資源。

<!-- 首屏最重要的 LCP 圖片，請優先處理 -->
<img src="hero.webp" fetchpriority="high" width="1280" height="720" alt="首圖">

<!-- 首屏看不到、不急著載入的圖片 -->
<img src="footer-logo.webp" fetchpriority="low" width="200" height="80" alt="頁尾標誌">

提醒一點：preload 與 fetchpriority 是「加速最重要的一張」，不是「全部都標高優先」。如果你把每張圖都標成 high，等於沒有優先序，反而失去效果。

頁面亂跳逼走訪客？Cumulative Layout Shift (CLS) 調教指南

CLS 的理想分數應該低於 0.1。它雖然不像 LCP 那樣直接影響載入速度，卻嚴重破壞使用者體驗。一個高 CLS 分數的網站，會給人一種「不專業」、「不可靠」的感覺。

CLS 到底是怎麼算出來的？

理解計算方式，你就會知道為什麼有些位移特別致命。CLS 的分數來自兩個因素相乘：

影響範圍 (impact fraction)：發生位移的元素影響到畫面多大的比例。位移整片內容區塊，當然比位移一個小角標糟糕得多。
移動距離 (distance fraction)：這些元素相對於可視範圍移動了多遠。

這也解釋了一個常見現象：越接近首屏、面積越大的元素，一旦發生位移，對分數的傷害越嚴重。所以優化 CLS 時，優先盯住首屏的大圖、大橫幅與標題區。

CLS 的常見罪魁禍首

版面位移通常是由於瀏覽器一開始不知道某些元素「佔多大空間」所造成的。

沒有尺寸的圖片或影片：這是最常見的原因。圖片載入完成後，突然「撐開」一個空間，把下面的內容都擠下去了。
動態載入的廣告或 iframe：廣告商的腳本通常不會告訴你廣告多大，載入後就直接插入頁面，造成災難性的版面位移。
網頁字型 (Web Fonts) 造成的閃爍：當自訂字型還在下載時，瀏覽器可能會先用系統預設字型顯示文字，等自訂字型載入後再替換，這個替換過程可能因為字體大小不同而導致版面跳動。
在現有內容上方動態插入內容：例如一個「訂閱我們的電子報！」的橫幅，在頁面載入後才用 JavaScript 插入到頂部。

根治 CLS 的處方籤

幸運的是，CLS 相對容易修復，核心概念就是「事先預留空間」。

永遠為圖片和影片設定 width 和 height 屬性：這是最簡單也最有效的解法。只要在 <img> 標籤上加上寬高，瀏覽器在圖片下載完成前，就會先根據寬高比幫你把位置佔好（即使你用 CSS 把寬度設成 100%，現代瀏覽器仍會依寬高比保留正確的縱向空間）。
```

<img src="image.jpg" width="1280" height="720" alt="一個有設定寬高的好圖片" style="width: 100%; height: auto;">
```
為廣告和嵌入內容預留空間：如果你知道廣告區塊的大小，可以用 CSS 設定一個容器 div，並給它一個 min-height，確保它在廣告載入前就佔據了足夠的空間。
優化字型載入策略：在你的 @font-face 規則中加入 font-display: swap;。這會讓瀏覽器在自訂字型載入完成前，先用備用字型顯示文字，減少文字隱形的時間。同時，也可以預載入重要的字型檔案。
動畫只動 transform，不要動會撐開版面的屬性：如果你有開場動畫或互動效果，盡量用 transform（位移、縮放）與 opacity 來做，這類屬性不會影響其他元素的排版位置，因此不計入 CLS。反之，直接去改 top、margin、width、height 會推擠周圍內容，很容易把分數搞糟。

點擊沒反應？First Input Delay (FID) 與 INP 互動優化

理想的 FID 應該低於 100 毫秒。當使用者點擊按鈕卻感覺到「延遲」、「卡頓」，背後的主因通常是瀏覽器的主執行緒 (Main Thread) 太忙了，沒空理你。

是什麼佔用了你的瀏覽器主執行緒？

主執行緒就像一個單線道的工廠作業員，他要負責處理 JavaScript、渲染畫面、回應使用者操作等所有事情。如果他正在處理一個非常耗時的 JavaScript 任務，就沒辦法回應你的點擊了。

冗長且複雜的 JavaScript 執行：一個執行時間超過 50ms 的 JavaScript 任務，就被稱為「長任務 (Long Task)」。過多的長任務是造成 FID/INP 過高的主因。
巨大的 JS 檔案：瀏覽器需要時間去下載、解析和編譯這些檔案。
過多的第三方腳本：你裝的 Facebook Pixel、Google Analytics、線上客服外掛……每一個都在搶佔主執行緒的資源。這也是我常跟客戶唸的，裝外掛前請三思，真的每個都需要嗎？

釋放主執行緒，讓網站「動」起來

優化 FID/INP 的核心就是「別讓主執行緒太忙」。

拆分長任務 (Long Tasks)：將一個龐大的 JavaScript 任務，切分成數個小任務，並透過 setTimeout 來排程執行。這樣可以在任務的空檔，讓瀏覽器有機會去處理使用者的輸入。

// 一次跑完整批，主執行緒會被卡死
function processAll(items) {
  for (const item of items) heavyWork(item);
}

// 切成小批、每批之間把控制權還給瀏覽器
function processInChunks(items, chunkSize = 50) {
  let i = 0;
  function next() {
    const end = Math.min(i + chunkSize, items.length);
    for (; i < end; i++) heavyWork(items[i]);
    if (i < items.length) setTimeout(next, 0); // 讓出主執行緒，先回應使用者
  }
  next();
}

延遲載入非必要的 JavaScript：跟優化 LCP 的概念一樣，不是所有 JS 都需要在頁面一載入就執行。例如，處理表單驗證的腳本，只有在使用者真的開始填表單時才需要。同樣地，使用 defer 屬性是你的好朋友。
減少第三方腳本的依賴：定期審視你的 WordPress 網站安裝了哪些外掛和第三方追蹤碼。每個腳本都會帶來效能成本。問問自己：「這個功能帶來的價值，是否值得犧牲網站的互動性？」

為什麼大家都在從 FID 轉向 INP？

這裡補充一個觀念，幫你理解「為何不能只顧 FID」。FID 只測量使用者「第一次」互動前的那段等待，而且只算延遲、不算後續處理時間，所以即使 FID 很漂亮，使用者在頁面上後續每一次點擊、捲動都可能很卡。INP 則會把整個瀏覽過程中的互動都納入觀察，反映的是「整體互動順不順」。

好消息是，兩者變差的根本原因相同——都是 JavaScript 把主執行緒佔住了。所以上面那些「減少、延遲、拆分 JavaScript」的功夫，優化 FID 的同時也直接改善 INP，不必另起爐灶。

沒有頭緒時，照這個順序動手

面對一份滿江紅的報告，與其東補一塊西補一塊，不如照投資報酬率排序，由地基往上修：

先確認主機與 TTFB：地基太慢，後面全白做。先確認頁面快取有開、主機等級夠用。
處理首屏最大的圖片：正確尺寸、現代格式、加上 width／height，必要時用 preload 或 fetchpriority="high"。這一步通常同時改善 LCP 與 CLS。
替所有會撐開版面的元素預留空間：圖片、影片、廣告、嵌入內容、動態橫幅，全部給定尺寸或 min-height。
盤點並瘦身 JavaScript：砍掉用不到的外掛與追蹤碼，剩下的能 defer 就 defer、能延後就延後、長任務切小。
回到真實使用者數據驗收：記得真實數據要累積流量才會反映改善，別只看一次實驗室跑分就下定論。

總結：WordPress 速度優化是一場持續的旅程

搞定 WordPress 速度優化，特別是針對 LCP / CLS / FID 的調教，絕對不是安裝一個外掛就能一勞永逸的。它更像是一場結合了技術偵錯、資源管理與使用者體驗思維的持續性工程。

從伺服器 TTFB 的基礎建設，到 LCP 的圖片與資源載入策略，再到 CLS 的版面穩定性，最後是 FID/INP 的 JavaScript 執行效率，每一個環節都息息相關。今天我們分享的，是你在面對 PageSpeed Insights 紅字時，最應該優先檢查與動手的方向。

我知道，這其中涉及的技術細節可能讓你感到有些頭大。沒關係，這正是浪花科技存在的價值。如果你的團隊希望專注在核心業務上，而將網站效能這個燒腦的任務交給專業的工程師團隊，我們非常樂意為你服務。我們擅長深入程式碼層級，找出真正的效能瓶頸，並打造出既快速又穩定的 WordPress 網站。

準備好讓你的網站從滿江紅變成一片綠了嗎？立即聯繫我們，讓我們聊聊如何為你的網站進行一次徹底的健康檢查與效能升級！

延伸閱讀

// FAQ

常見問題

Core Web Vitals 是哪三個核心指標？

三個核心指標為 LCP（Largest Contentful Paint，最大內容繪製，衡量載入速度）、CLS（Cumulative Layout Shift，累計版面配置位移，衡量視覺穩定性）、FID（First Input Delay，首次輸入延遲，衡量互動性）。Google 也以 INP（Interaction to Next Paint）作為 FID 的接班指標。

理想的 LCP 時間應該是多少？

理想的 LCP 應在 2.5 秒以內。若超過 4 秒，使用者通常已等到不耐煩，代表頁面的「第一印象」載入體驗不佳。

PageSpeed Insights 的實驗室數據和真實使用者數據有什麼差別？

實驗室數據（Lab Data）在受控、可重現的環境模擬載入，適合除錯，但測不到 FID，通常以總阻塞時間（TBT）作為互動性替身。真實使用者數據（Field Data）來自實際訪客的各種裝置與網路，是 Google 評估搜尋排名的依據，需累積一段流量才會穩定。

如何優化網站的 LCP？

主要方向有四：降低伺服器回應時間（TTFB，選用優質主機、頁面快取與 CDN）、優化圖片（正確尺寸、有效壓縮、改用 WebP/AVIF）、延遲載入非關鍵 CSS 與 JavaScript（為 script 加上 defer）、以及對關鍵資源使用 preload 預載入。

preload 和 fetchpriority 該怎麼用才不會適得其反？

preload 與 fetchpriority 用來加速「最重要的那一張」資源，例如首屏 LCP 圖片可標 fetchpriority="high"、首屏外的圖片標 "low"。若把每張圖片都標成 high 等於沒有優先序，反而失去效果。

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