Core Web Vitals 實戰：把 LCP 由 4.2 秒壓到 1.3 秒

方法論：所有前後對比數據取自該網站嘅 Chrome 使用者體驗報告（CrUX）欄位數據，為 75 百分位、手機裝置、28 日滾動視窗數值，而非 Lighthouse 實驗室分數。之所以強調這點：實驗室工具在固定環境測試，欄位數據反映真實用戶（不同裝置、不同網速），Google 搜尋用嘅是後者。個別優化步驟嘅毫秒貢獻以 Chrome DevTools 效能面板嘅 LCP 分段追蹤量度，於同一測試條件下逐項對比。文中引用嘅所有門檻與計算方式均以 Google 官方文件為準並標明出處。

一、起點：4.2 秒背後嘅四段時間

先講一個大部分人未做過嘅動作：把 LCP 拆開。Google 在 web.dev 嘅官方指引明確指出，任何頁面嘅 LCP 都可以拆成四個互不重疊、加起來剛好等於 LCP 總值嘅分段：

• TTFB（首位元組時間）：由用戶開始載入頁面，到瀏覽器收到 HTML 文件第一個位元組。
• 資源載入延遲（Resource load delay）：由 TTFB 到瀏覽器開始下載 LCP 資源。若 LCP 元素不需載入資源（例如用系統字體嘅文字節點），此值為 0。
• 資源載入時間（Resource load duration）：下載該 LCP 資源本身所需時間。
• 元素渲染延遲（Element render delay）：由資源下載完成到元素完整繪製出來。

官方亦給出一個「理想分佈」作參考：TTFB 約佔 40%、資源載入時間約佔 40%，兩個帶「延遲」字眼嘅分段各應少於 10%——因為名字帶 delay 就代表理論上應該接近零。

LCP 分段	改版前	佔比	官方理想佔比	診斷
TTFB	1,850ms	44%	~40%	絕對值過高，單靠這一段已幾乎注定過不了 2.5 秒
資源載入延遲	980ms	23%	<10%	最大浪費：主視覺是 CSS 背景圖 + lazy load，發現得太晚
資源載入時間	1,010ms	24%	~40%	3.2MB 未壓縮 JPG
元素渲染延遲	360ms	9%	<10%	比例合格，但仍有阻斷渲染嘅 CSS
LCP 合計	4,200ms	100%	—	屬「差」（>4.0 秒）

同期其他指標：CLS 0.24（差）、INP 320ms（需改善）、手機版首頁傳輸量 5.8MB、請求數 94 個。

為什麼「先壓縮圖片」是最常見嘅誤判

Google 官方文件有一段講得很直白：如果你把圖片壓細，只會縮短「資源載入時間」，但如果 LCP 元素本身被 JavaScript 隱藏到最後才一次顯示，省下嘅時間只會轉移到「元素渲染延遲」，LCP 總值不變。

官方亦引用整體數據指出：在 LCP 屬「差」嘅來源之中，至少有一半嘅 p75 TTFB 高達 2,270ms——單憑這一段就幾乎令 2.5 秒門檻無法達成。所以正確次序是先量度四段，再決定先修哪一段，而不是套用一份通用清單。

二、先講清楚門檻：網上流傳嘅「新標準」是錯嘅

寫這篇文章時，我們搜尋到大量 2026 年嘅文章聲稱「Google 在 2026 年 3 月核心更新把 LCP 良好門檻由 2.5 秒收緊至 2.0 秒」、「INP 超過 500ms 會被降級」、「新增 Visual Stability Index 指標」。

這些說法沒有官方依據。Google 開發者文件《Understanding Core Web Vitals and Google search results》（最後更新日期 2025 年 12 月 10 日）寫得清清楚楚：LCP 應在頁面開始載入嘅首 2.5 秒內發生、INP 應少於 200 毫秒、CLS 應少於 0.1。web.dev 嘅 LCP 優化指引（最後更新 2025 年 3 月 31 日）同樣寫明「至少 75% 嘅頁面瀏覽應達到 2.5 秒或以下」。自 2024 年 3 月 INP 取代 FID 之後，三項門檻並未改變，2026 年亦沒有新增核心指標。

指標	良好	需改善	差	量度方式
LCP	≤ 2.5 秒	2.5 – 4.0 秒	> 4.0 秒	真實用戶 75 百分位，按裝置類別分開
INP	< 200ms	200 – 500ms	> 500ms	同上
CLS	< 0.1	0.1 – 0.25	> 0.25	同上

為什麼要花一節講這件事？因為錯誤門檻會導致錯誤決策——例如為了追一個不存在嘅 2.0 秒標準而過度壓縮圖片質素，犧牲視覺卻換不到任何搜尋回報。在 AI 生成內容大量湧現嘅環境下，技術類資訊嘅第一原則是回到官方文件核對，而不是引用第五手轉述。這亦是我們寫技術內容時嘅硬規則，理由與GEO 是什麼？讓 ChatGPT 與 AI 搜尋引用你網站的 9 個做法裡面講嘅「事實可驗證性」一致。

順帶更正一個較新嘅計算細節

Chrome 已修改動畫圖片格式（例如 GIF）嘅 LCP 計算方式，改為以第一幀而非整張圖片載入完成嘅時間為準（見 Chrome UX Report 版本說明）。如果你嘅主視覺是 GIF，舊嘅診斷結論可能已不適用。

三、Core Web Vitals 對排名嘅實際權重

要誠實講：Core Web Vitals 不是排名嘅主要驅動力。Google 官方嘅說法是「我們強烈建議網站達到良好嘅 Core Web Vitals，這與其他頁面體驗因素一併，符合我們核心排名系統所希望獎勵嘅方向」，而頁面體驗常見問題亦說明並不存在單一「頁面體驗分數」用於排名。第三方相關性研究普遍把 CWV 嘅影響估算在整體演算法嘅 1% 至 3% 左右，定位為「同分時嘅決勝因素」而非主導因素——這個數字來自第三方研究而非 Google 公布，引用時應如此標示。

但這不代表不值得做，理由有三個：

• 轉換率。本個案嘅手機版跳出率由 61% 降至 43%，平均工作階段時長由 48 秒升至 1 分 22 秒。速度嘅商業回報大部分來自這裡，而非排名。
• AI 爬蟲。多數 AI 爬蟲不執行 JavaScript，而伺服器回應速度與初始 HTML 完整性直接影響它們能否讀到你嘅內容。TTFB 優化同時服務 SEO 與 GEO。
• 抓取效率。TTFB 下降後，同一抓取預算內 Googlebot 可抓取更多頁面。本個案嘅每日抓取頁面數在一個月內由平均 84 頁升至 210 頁。

四、逐段修正：每一步嘅實測毫秒

次序	修正內容	影響分段	節省	佔總改善
1	伺服器端頁面快取 + CDN 邊緣快取 + 移除兩層轉址 + 修正 N+1 查詢	TTFB	−1,230ms	42%
2	主視覺改為 HTML <img>、移除 lazy load、加 fetchpriority="high"	資源載入延遲	−890ms	31%
3	AVIF + 響應式 srcset（3.2MB → 148KB）	資源載入時間	−550ms	19%
4	內嵌關鍵 CSS、延後非關鍵 CSS/JS、字型 font-display: swap + 預載子集	元素渲染延遲	−230ms	8%
合計			−2,900ms	100%

第 1 步：TTFB 由 1,850ms 降至 620ms

這一段最容易被外包團隊跳過，因為它涉及伺服器而非前端。四項處理：

• 移除轉址鏈。原本 http://www → https://www → https:// 三跳，每跳在 4G 上約 180–260ms。改為一次性直接轉到最終網址。Google 官方特別點名「訪客經多重轉址到達」是快網站 TTFB 慢嘅常見成因。
• 伺服器端輸出快取。原本每次請求都重新查資料庫組頁面。加入頁面級快取（有效期 10 分鐘，後台更新時主動清除），未命中時間由 940ms 降至 120ms。
• 修正 N+1 查詢。頁尾導覽選單原本逐條 SQL 讀取，一頁 37 次查詢；改為一次查詢加記憶體分組，省 210ms。
• CDN 邊緣快取 + PHP OPcache。香港訪客命中本地節點，靜態資源不再回源。

<?php
// 頁面級輸出快取（簡化示意）
$key  = 'page_' . md5($_SERVER['REQUEST_URI']);
$file = CACHE_DIR . '/' . $key . '.html';

if (is_file($file) && (time() - filemtime($file)) < 600) {
    header('X-Cache: HIT');
    readfile($file);
    exit;
}

ob_start();
// ... 正常渲染頁面 ...
$html = ob_get_clean();
file_put_contents($file, $html, LOCK_EX);
header('X-Cache: MISS');
echo $html;

第 2 步：資源載入延遲由 980ms 降至 90ms（單項最划算）

原本嘅主視覺寫法是這樣——三個錯誤同時出現：

<!-- 改版前：瀏覽器要等 CSS 下載並解析完才發現這張圖 -->
<div class="hero" style=""></div>
<!-- CSS: .hero { background-image: url(/images/hero.jpg); } -->

<!-- 另一個版本更差：lazy load 加在主視覺上 -->
<img data-src="/images/hero.jpg" loading="lazy" class="lazyload">

Google 官方明確列出三種「瀏覽器無法從 HTML 掃描發現 LCP 資源」嘅情況：由 JavaScript 動態加入嘅 <img>、被 lazy load 函式庫改成 data-src 嘅圖片、以及需要 CSS 背景圖嘅元素。這個網站同時中了兩項。修正後：

<!-- 改版後：src 直接在初始 HTML，預載掃描器即時發現 -->
<img src="/images/hero-800.avif"
     srcset="/images/hero-480.avif 480w,
             /images/hero-800.avif 800w,
             /images/hero-1600.avif 1600w"
     sizes="(max-width: 768px) 100vw, 800px"
     width="1600" height="900"
     alt="香港企業網站主視覺"
     fetchpriority="high">

<!-- 若主視覺必須是 CSS 背景圖，就要預載 -->
<link rel="preload" fetchpriority="high" as="image"
      href="/images/hero-800.avif" type="image/avif">

兩個實務提醒（皆來自官方指引）：fetchpriority="high" 只應用於一至兩張最可能成為 LCP 元素嘅圖片，設得太多就失去優先次序嘅意義；輪播中初始不可見嘅第二、三張圖，反而應設 fetchpriority="low" 釋出頻寬。我們就是把輪播第二至第五張全部降級，讓第一張獨佔頻寬。

第 3 步：資源載入時間由 1,010ms 降至 460ms

• 格式：JPG（3.2MB，2400×1350）→ AVIF（148KB，三種尺寸），品質設 72。曾試過壓到 40，客戶反映產品顏色失真，回調至 72 後視覺可接受而檔案仍細。
• 尺寸：原本無論手機或桌面都下載同一張 2400px 寬圖片；改為 srcset 三檔，手機只下載 480px 版本。
• 快取政策：靜態資源設 Cache-Control: public, max-age=31536000, immutable，檔名加版本雜湊。回訪用戶嘅資源載入時間接近零——官方稱之為「完全消除網路時間」。

第 4 步：元素渲染延遲由 360ms 降至 130ms

• 移除 <head> 內兩個同步 <script>（一個是舊版 jQuery、一個是第三方彈窗），改為 defer。官方講法是：幾乎從來沒有必要在 head 加入同步腳本。
• 把首屏必需 CSS（14KB）內嵌到 HTML，其餘 96KB 樣式表延後載入。官方建議只在樣式表夠細時才內嵌——若樣式表大到載入時間超過 LCP 資源，就不是好候選。
• 字型：由六個檔案減至兩個 woff2 子集（僅保留常用字），加 <link rel="preload"> 並設 font-display: swap。官方指出只要 font-display 不是 auto 或 block，文字就會在字型載入期間保持可見，LCP 不會被額外網路請求阻塞。
• 拆分長任務：把一個 480ms 嘅初始化腳本切成多段並延後執行。圖片渲染同樣發生在主執行緒，任何阻塞主執行緒嘅工作都會拖慢渲染。

順手處理 CLS 與 INP

• CLS 0.24 → 0.02：所有 <img> 補上 width／height 屬性、為輪播與橫幅容器預留固定高度（aspect-ratio）、把字型後備堆疊改為度量接近嘅本地字體以減少替換跳動、移除會推移版面嘅頂部公告條（改為 sticky 疊層）。
• INP 320ms → 110ms：移除一個每次滾動都重算版面嘅輪播插件、把分析與聊天工具延後至互動後載入、把選單展開嘅事件處理拆細。

五、結果與商業影響

指標（手機版 p75）	改版前	改版後
LCP	4,200ms（差）	1,300ms（良好）
CLS	0.24（差）	0.02（良好）
INP	320ms（需改善）	110ms（良好）
首頁傳輸量	5.8MB	0.9MB
請求數	94	38
手機跳出率	61%	43%
平均工作階段時長	48 秒	1 分 22 秒
Googlebot 每日抓取頁數	84	210
表單提交轉換率	1.4%	2.6%

兩個必須誠實說明嘅限制

一、Search Console 嘅 Core Web Vitals 報表不會即時反映。因為欄位數據採 28 日滾動視窗，即使代碼今日上線，報表要約四星期後才完整呈現新狀態。中途看到「部分網址仍為差」是正常現象，不代表修正失敗。

二、轉換率提升不能全部歸因於速度。同期我們亦簡化了表單欄位。要嚴謹歸因，應該分階段上線並分開量度——這是我們當時為了趕客戶檔期而妥協嘅地方，如實記錄。

六、四個試過但反效果嘅做法

1. 一鍵開齊「速度優化外掛」全部選項

第一晚我們貪快，把某個效能外掛嘅所有選項（合併 CSS、延後全部 JS、移除未使用 CSS、lazy load 全站圖片）一次開齊。結果：主視覺被 lazy load 拖慢、輪播閃爍、手機版選單完全失效，而 LCP 只由 4.2 秒降到 3.9 秒。翌日全部關掉，改為逐項手動處理。教訓是——自動化工具不知道哪一張圖是你嘅 LCP 元素。

2. 把圖片品質壓到 40

檔案由 148KB 再降至 61KB，LCP 只快約 40ms，但客戶產品顏色明顯失真並提出投訴。回調至品質 72。速度與質素嘅邊際回報在某一點後會急速遞減。

3. 用 data URL 把主視覺內嵌到 HTML

理論上可以消除一次網路請求，實際上 HTML 文件由 42KB 漲到 210KB，TTFB 反而升 130ms，而且圖片無法被快取，回訪用戶更慢。官方文件亦已警告：data URL 無法被快取，且在部分情況下會因額外解碼成本導致更長嘅渲染延遲。只適用於極小資源。

4. 追 Lighthouse 100 分

我們曾為了把 Lighthouse 由 96 推到 100 而花了半日移除一段第三方追蹤碼，但欄位數據（CrUX）幾乎無變化，客戶卻失去了廣告轉換追蹤。官方立場很清楚：實驗室工具與欄位數據不一致時，CrUX 更能反映真實用戶體驗。Google 搜尋用嘅是欄位數據，所以優化目標應該是欄位數據，不是實驗室分數。

七、可複製嘅診斷流程

1. 在 PageSpeed Insights 先看「探索真實使用者的體驗」一節（CrUX 欄位數據），並分開檢視手機／桌面、本網址／整個來源四組數字。
2. 用 Chrome DevTools 效能面板取得四段 LCP 分段時間，找出佔比明顯偏離官方理想分佈（TTFB ~40%、載入延遲 <10%、載入時間 ~40%、渲染延遲 <10%）嘅那一段。
3. 若 TTFB 超過 800ms，先修伺服器與轉址，其餘全部後話——因為前端任何優化都要等第一個位元組。
4. 確認 LCP 元素嘅資源可從初始 HTML 被發現（不是 CSS 背景圖、不是 JS 動態插入、不是 data-src）。
5. 為 LCP 圖片加 fetchpriority="high"，移除其上嘅 loading="lazy"，並為輪播後續圖片設 fetchpriority="low"。
6. 轉 AVIF／WebP 並用 srcset 分尺寸；設長期快取與版本雜湊。
7. 清理 <head>：無同步腳本、關鍵 CSS 內嵌、其餘延後；字型子集化並設 font-display: swap。
8. 所有圖片與嵌入內容補上尺寸屬性，為動態區塊預留空間（處理 CLS）。
9. 上線後等 28 日再看 Search Console 嘅 Core Web Vitals 報表，中途只看 CrUX 與 RUM 數據。
10. 設定持續監察：每月覆核一次，因為新加嘅第三方腳本是效能回退最常見嘅原因。

想快速取得自己網站嘅基線，可以先跑SEO 檢查工具（內含速度與技術項目評分）與GEO 檢查工具；需要人接手處理伺服器與前端，可看網頁設計服務或直接聯絡我們。

八、常見問題

LCP 良好門檻究竟是 2.5 秒還是 2.0 秒？

2.5 秒。Google 開發者文件（最後更新 2025 年 12 月 10 日）與 web.dev 嘅 LCP 指引均寫明應在 2.5 秒或以下，且需有至少 75% 嘅頁面瀏覽達標。網上流傳「2026 年收緊至 2.0 秒」嘅說法沒有官方依據；三項門檻自 2024 年 3 月 INP 取代 FID 後未曾改變，2026 年亦無新增核心指標。

為什麼壓縮圖片之後 LCP 完全無改善？

因為瓶頸不在資源載入時間。最常見嘅情況是 LCP 元素被 JavaScript 隱藏或需要等 CSS 解析才被發現——這時省下嘅下載時間只會轉移到「元素渲染延遲」或「資源載入延遲」，總值不變。正確做法是先量度四段分佈，再對症下藥。

TTFB 應該壓到幾多？

官方指引指出過高嘅 TTFB 會令 2.5 秒 LCP 難以甚至不可能達成；一般以 800ms 以下為診斷參考線。常見成因包括多重轉址、用戶距離伺服器太遠、網絡條件差，以及因網址帶查詢參數而無法使用 CDN 快取內容。

Lighthouse 分數 90 分以上，但 Search Console 顯示「差」，信邊個？

信 Search Console／CrUX。Lighthouse 是實驗室工具，在固定裝置與網速下模擬；CrUX 收集真實 Chrome 用戶嘅匿名數據。官方明確表示兩者不一致時，CrUX 更能代表用戶體驗，而 Google 搜尋使用嘅正是欄位數據。

Core Web Vitals 真係影響排名嗎？

是排名考量之一，但屬次要。Google 表示良好嘅 Core Web Vitals 連同其他頁面體驗因素，符合核心排名系統希望獎勵嘅方向，同時說明並不存在單一「頁面體驗分數」。第三方相關性研究普遍估算其影響約佔整體演算法 1–3%，定位為決勝因素。真正嘅回報通常來自轉換率與跳出率嘅改善。

WordPress 站可以怎樣做？

次序與本文相同：先處理伺服器（快取外掛 + CDN + 移除轉址鏈 + PHP 8.x + OPcache），再處理主視覺（確認主題有無為 hero 加 lazy load，多數效能外掛會誤加），然後圖片格式與 srcset，最後清理 <head>。切忌一次開齊外掛所有選項——我們就是這樣浪費了一晚。

用 React／Next.js 嘅網站有什麼特別要注意？

客戶端渲染會同時傷害 LCP 與 AI 可見度。官方指出伺服器端渲染（SSR）對 LCP 有兩個好處：圖片資源可從 HTML 被發現，且內容不需等額外 JavaScript 請求完成才能渲染；代價是伺服器處理時間增加，可能拖慢 TTFB，但這個取捨通常值得，因為伺服器時間在你控制範圍內，用戶嘅網絡與裝置則不是。若架構允許，靜態產生（SSG）在效能上更佳。

修正後幾耐會反映在 Search Console？

約 28 日，因為欄位數據採 28 日滾動視窗。這段期間應以 CrUX 或自建 RUM 監察即時變化，不要因為報表未變而反覆改動。

主視覺是 GIF 動畫會怎樣計算？

Chrome 已改為以動畫圖片嘅第一幀而非整張圖片載入完成時間作為 LCP 時間（見 Chrome UX Report 版本說明）。若你依據舊資料判斷 GIF 主視覺嘅 LCP，結論可能已過時。

速度優化要幾錢、幾久？

視乎瓶頸在哪。純前端修正（圖片、head 清理、屬性補全）通常 1–3 個工作天；涉及伺服器架構、快取層與資料庫查詢嘅，需 1–2 星期。本個案由診斷到全部上線共 9 個工作天。整體網站項目嘅費用結構可參考香港網頁設計價錢完整拆解。

九、結語：速度優化係量度問題，唔係清單問題

市面上大部分「提升網站速度 20 招」嘅文章有一個共同問題：它們列出所有可能有用嘅做法，卻不告訴你哪一項對你有用。本個案 2,900 毫秒嘅改善之中，73% 來自兩項工作（TTFB 與資源發現），而最常被優先執行嘅圖片壓縮只佔 19%。若當初照清單由第一項做起，可能花了三日只換到 300 毫秒。

所以整個流程可以壓縮成一句：先拆四段、找出偏離理想分佈最遠嘅那一段、只修那一段、再量度。重複三輪，通常已經足夠。

想知道自己網站卡在哪一段，可以由SEO 檢查工具開始，或聯絡我們做一次 LCP 分段診斷。相關內容：SEO 幾耐先見效、診所網站改版個案、SEO 專欄、作品集。

資料來源

• Google 開發者文件，《Understanding Core Web Vitals and Google search results》（最後更新 2025 年 12 月 10 日）：LCP 應在首 2.5 秒內發生、INP 少於 200 毫秒、CLS 少於 0.1；並說明良好 Core Web Vitals 連同其他頁面體驗因素符合核心排名系統嘅獎勵方向。
• web.dev，《Optimize Largest Contentful Paint》（Philip Walton、Barry Pollard 撰寫，2020 年 4 月 30 日發布，2025 年 3 月 31 日最後更新）：LCP 四段拆解定義；理想分佈為 TTFB ~40%、資源載入延遲 <10%、資源載入時間 ~40%、元素渲染延遲 <10%；「至少 75% 頁面瀏覽達 2.5 秒或以下」；壓縮圖片可能只把時間轉移至渲染延遲；三種令 LCP 資源無法被預載掃描器發現嘅情況；fetchpriority 用法與限制；同步腳本、內嵌 CSS、SSR／SSG 取捨；font-display 非 auto／block 時文字保持可見；data URL 無法快取且可能增加解碼成本；轉址與查詢參數導致 TTFB 上升。
• web.dev，《Common misconceptions about how to optimize LCP》：在 LCP 屬「差」嘅來源中，至少一半嘅 p75 TTFB 達 2,270 毫秒，單此一段已幾乎令 2.5 秒門檻無法達成。
• Chrome UX Report 版本說明：動畫圖片格式（如 GIF）嘅 LCP 改以第一幀計算。
• INP 於 2024 年 3 月正式取代 FID 成為 Core Web Vitals 之一；三項門檻自此未變，2026 年無新增核心指標。
• Core Web Vitals 佔整體排名影響約 1–3% 嘅估算，來自第三方相關性研究，並非 Google 公布數字。
• 本個案前後對比數據：取自該網站 CrUX 欄位數據（75 百分位、手機、28 日滾動視窗）、Chrome DevTools 效能面板 LCP 分段追蹤、Google Search Console 與 GA4，已取得客戶同意匿名引用。

更新日誌：2026 年 8 月 16 日——依 Google 官方文件（2025 年 12 月 10 日版）核實三項門檻並新增第二節辟謠、加入 Chrome 對動畫圖片 LCP 計算方式嘅變更、補充 web.dev 關於 TTFB 佔比嘅整體數據。原文發布：2026 年 9 月 15 日（原為排程稿）。本文每季度覆核一次。