結論先講
Core Web Vitals（CWV）是 Google 排名的硬指標。 不是加分項，是門檻。你的 LCP 超過 2.5 秒、CLS 超過 0.1、INP 超過 200 毫秒，Google 就會降低你的排名優先度。好消息是：如果你用靜態網站產生器（Quartz、Astro、Hugo），你天生就贏了大半。
真實場景：同樣主題的兩篇文章，內容品質差不多。一個在 WordPress 上跑，LCP 4.2 秒；一個在 Quartz 上，LCP 0.8 秒。Google 會偏好後者。不是因為它比較會寫文章，是因為使用者體驗好太多了。
什麼是 Core Web Vitals
Core Web Vitals 是 Google 從 2021 年開始使用的三個核心指標，用來衡量「使用者在你的網站上的體驗好不好」。2024 年起，INP 正式取代了 FID。
三大指標一覽
| 指標 | 全名 | 衡量什麼 | 好 | 需改善 | 差 |
|---|---|---|---|---|---|
| LCP | Largest Contentful Paint | 最大元素載入時間 | ≤ 2.5s | 2.5s - 4.0s | > 4.0s |
| CLS | Cumulative Layout Shift | 版面位移累計量 | ≤ 0.1 | 0.1 - 0.25 | > 0.25 |
| INP | Interaction to Next Paint | 互動到畫面回應時間 | ≤ 200ms | 200ms - 500ms | > 500ms |
簡單說：
- LCP = 你的頁面主要內容多快出現
- CLS = 你的頁面有沒有「跳來跳去」
- INP = 使用者點按鈕後多快有反應
怎麼測量 CWV
別猜，用工具量。以下是四種主要測量方式：
1. PageSpeed Insights（最直覺）
直接去 pagespeed.web.dev 貼你的 URL。它會給你：
- 實際使用者數據（Field Data）— 來自 Chrome UX Report，代表真實使用者的體驗
- 實驗室數據（Lab Data）— Lighthouse 在模擬環境跑的結果
# 用 API 批次檢查（免費，需要 API key）
curl "https://www.googleapis.com/pagespeedonline/v5/runPagespeed?\
url=https://your-blog.com/seo/01-seo-fundamentals&\
key=YOUR_API_KEY&\
category=performance&\
strategy=mobile"2. Lighthouse（本地開發必備）
Chrome DevTools → Lighthouse 頁籤 → 勾 Performance → 跑一次。
# CLI 版本，適合 CI/CD
npm install -g lighthouse
lighthouse https://your-blog.com --output=json --output-path=./report.json
# 只看 CWV 相關指標
lighthouse https://your-blog.com --only-audits=largest-contentful-paint,cumulative-layout-shift,interactive3. Google Search Console（真實數據）
GSC → 體驗 → Core Web Vitals。這裡的數據是真實使用者的，不是模擬的。如果 PageSpeed 說你很快但 GSC 說你很慢，信 GSC。
4. CrUX Dashboard（趨勢追蹤）
Chrome UX Report 提供 BigQuery 公開數據集，可以查歷史趨勢：
-- 查特定網站的 CWV 趨勢（BigQuery）
SELECT
date,
p75_lcp,
p75_cls,
p75_inp
FROM `chrome-ux-report.materialized.metrics_summary`
WHERE origin = 'https://your-blog.com'
ORDER BY date DESC
LIMIT 12;LCP 優化：讓主要內容快點出現
LCP 通常是頁面上最大的圖片或文字區塊。大多數情況下，問題出在圖片。
圖片優化是第一優先
<!-- 不好：用 PNG，沒指定尺寸，沒 lazy loading 策略 -->
<img src="hero.png">
<!-- 好：WebP 格式、指定尺寸、above-the-fold 用 eager -->
<img
src="hero.webp"
width="1200"
height="630"
loading="eager"
fetchpriority="high"
alt="文章封面圖"
>LCP 優化清單
| 優化項目 | 影響程度 | 難度 |
|---|---|---|
| 圖片轉 WebP/AVIF | 高 | 低 |
| 首屏圖片 preload | 高 | 低 |
| 使用 CDN | 高 | 中 |
| 減少 render-blocking CSS/JS | 高 | 中 |
| 伺服器端快取 | 中 | 低 |
| 字型 preload | 中 | 低 |
<!-- 在 <head> 預載 LCP 圖片 -->
<link rel="preload" as="image" href="/covers/hero.webp" type="image/webp">
<!-- 預載字型，避免 FOIT（Flash of Invisible Text）-->
<link rel="preload" as="font" href="/fonts/inter.woff2" type="font/woff2" crossorigin>靜態網站的天然優勢
WordPress 請求流程：
Browser → CDN → Server → PHP → MySQL → Render → Response
~200ms ~100ms ~300ms ~50ms ~200ms = ~850ms+
Quartz/Astro 請求流程：
Browser → CDN → Static HTML
~50ms ~10ms = ~60ms
靜態 HTML 不需要跑程式、不需要查資料庫。光是這點，LCP 就能快 10 倍以上。
CLS 優化：不要讓畫面跳
CLS 是使用者最容易「感覺到」的問題。你有沒有在看手機時，正要點一個按鈕，結果畫面突然往下跳，你點到廣告？那就是 CLS。
常見 CLS 元兇
- 沒有設定圖片尺寸 — 圖片載入後撐開空間
- 字型載入導致文字重排 — FOUT（Flash of Unstyled Text）
- 動態插入的內容 — 廣告、cookie consent、通知
/* 用 aspect-ratio 防止圖片 CLS */
img {
aspect-ratio: 16 / 9;
width: 100%;
height: auto;
}
/* 字型載入策略：用 font-display: swap 避免 FOIT */
@font-face {
font-family: 'Inter';
src: url('/fonts/inter.woff2') format('woff2');
font-display: swap;
}
/* 預留廣告空間（如果你有放廣告的話）*/
.ad-container {
min-height: 250px;
background: #f0f0f0;
}動態內容處理
// 不好：直接插入 DOM，造成位移
document.body.insertAdjacentHTML('afterbegin', '<div class="banner">公告</div>');
// 好：預留空間，內容載入後填入
const placeholder = document.querySelector('.banner-placeholder');
placeholder.innerHTML = '<div class="banner">公告</div>';
// placeholder 本身已經有 min-height，不會造成位移INP 優化：讓互動有反應
INP（Interaction to Next Paint）取代了 FID，衡量的是「使用者做了一個互動（點擊、鍵盤輸入、觸控）之後，畫面多快有視覺回饋」。
為什麼 INP 比 FID 更嚴格
| 差異 | FID | INP |
|---|---|---|
| 衡量對象 | 只看第一次互動 | 看所有互動中最慢的 |
| 涵蓋範圍 | 只看 input delay | 看完整流程（delay + processing + paint） |
| 門檻 | ≤ 100ms 為好 | ≤ 200ms 為好 |
INP 優化策略
// 不好：長任務阻塞主線程
button.addEventListener('click', () => {
// 假設這個運算要 500ms
const result = heavyComputation(data);
updateUI(result);
});
// 好：用 requestAnimationFrame 分段處理
button.addEventListener('click', () => {
// 先給視覺回饋
button.classList.add('loading');
// 把重計算延到下一幀
requestAnimationFrame(() => {
setTimeout(() => {
const result = heavyComputation(data);
updateUI(result);
button.classList.remove('loading');
}, 0);
});
});
// 更好：用 Web Worker 處理重計算
const worker = new Worker('/js/compute-worker.js');
button.addEventListener('click', () => {
button.classList.add('loading');
worker.postMessage({ data });
});
worker.onmessage = (e) => {
updateUI(e.data.result);
button.classList.remove('loading');
};輸入事件 debounce
// 搜尋輸入：不要每個按鍵都觸發搜尋
const searchInput = document.querySelector('#search');
let timeout;
searchInput.addEventListener('input', (e) => {
clearTimeout(timeout);
timeout = setTimeout(() => {
performSearch(e.target.value);
}, 300); // 等 300ms 沒有新輸入才搜尋
});靜態網站產生器的效能比較
如果你還在選框架，這張表可以幫你決定：
| 框架 | 預設輸出 | 典型 LCP | JS 體積 | 適合 |
|---|---|---|---|---|
| Quartz | 靜態 HTML | 0.5-1.0s | ~50KB | 技術部落格、知識庫 |
| Astro | 靜態 HTML（Island） | 0.5-1.2s | 極少 | 行銷網站、部落格 |
| Hugo | 靜態 HTML | 0.3-0.8s | ~0KB | 純內容網站 |
| Next.js SSG | 靜態 HTML + Hydration | 0.8-1.5s | ~80KB+ | 需要互動的網站 |
| Gatsby | 靜態 HTML + Hydration | 1.0-2.0s | ~100KB+ | 資料驅動的網站 |
| WordPress | 動態渲染 | 2.0-4.0s+ | 視外掛而定 | 不推薦（效能角度） |
我們的 Quartz 部落格：LCP 0.8s、CLS 0.01、INP 50ms。三項全綠。
實際測量範例
用 Web Vitals 函式庫在你的網站上收集真實數據：
// 安裝：npm install web-vitals
import { onLCP, onCLS, onINP } from 'web-vitals';
function sendToAnalytics(metric) {
const body = JSON.stringify({
name: metric.name,
value: metric.value,
rating: metric.rating, // 'good', 'needs-improvement', 'poor'
delta: metric.delta,
id: metric.id,
url: window.location.href,
});
// 用 sendBeacon 確保頁面關閉時也能送出
navigator.sendBeacon('/api/vitals', body);
}
onLCP(sendToAnalytics);
onCLS(sendToAnalytics);
onINP(sendToAnalytics);FAQ
Q: Core Web Vitals 是 Google 排名的必要條件嗎？
是排名因素之一，但不是唯一因素。如果你的內容品質遠優於競爭對手，即使 CWV 稍差也可能排名更高。但在內容品質相近的情況下，CWV 好的頁面會排在前面。
Q: 實驗室數據和實際用戶數據差很多怎麼辦？
以實際用戶數據（Field Data / CrUX）為準。實驗室數據（Lighthouse）只是模擬。差異通常來自：使用者的裝置比你的開發機慢、網路環境不同、第三方腳本影響。
Q: 我的網站是 SPA，CWV 一定很差嗎？
不一定，但確實更難優化。SPA 的 LCP 容易受 JavaScript bundle 大小影響，INP 也容易因為 hydration 而變差。如果是內容型網站，建議用 SSG 或 SSR。
Q: INP 跟 FID 有什麼差別？為什麼 Google 換了？
FID 只量「第一次」互動的 input delay；INP 量「所有互動中最慢的」完整回應時間。FID 太寬鬆了，很多網站 FID 過關但互動體驗其實很差。INP 更能反映真實使用者感受。
Q: 我用了 CDN，LCP 還是很慢？
CDN 只解決網路延遲，不解決資源太大的問題。檢查：圖片是否用了 WebP/AVIF？CSS/JS 是否有壓縮？有沒有 render-blocking 資源？首屏圖片有沒有 preload？
本系列文章
- SEO 基礎與注意事項
- 技術 SEO 實作
- 內容 SEO 策略
- 網站搬家 SEO
- GSC 實戰指南
- Open Graph 與社群分享
- AEO 基礎
- AEO 內容策略
- SEO vs AEO 整合策略
- Core Web Vitals 效能優化（本篇）
- AEO 監控自動化
- 案例：從 0 到被搜到