Core Web Vitals：網站速度怎麼量、怎麼改
一句話答案
Core Web Vitals 是 Google 衡量使用者體驗的三項指標：LCP（最大內容繪製）應低於 2.5 秒、INP（互動到下一次繪製）應低於 200 毫秒、CLS（累計版面配置位移）應低於 0.1，以 75% 的真實造訪達標為準。它是排名訊號之一，但比重低於內容相關性。
Core Web Vitals 是哪三項？
| 指標 | 衡量什麼 | 良好 | 需要改善 | 不佳 |
|---|---|---|---|---|
| LCP 最大內容繪製 | 主要內容多快出現 | ≤ 2.5 秒 | ≤ 4 秒 | > 4 秒 |
| INP 互動到下一次繪製 | 點擊後多快有反應 | ≤ 200 毫秒 | ≤ 500 毫秒 | > 500 毫秒 |
| CLS 累計版面配置位移 | 畫面會不會亂跳 | ≤ 0.1 | ≤ 0.25 | > 0.25 |
判斷標準是第 75 百分位數：75% 的真實造訪達到「良好」，這一項才算及格。門檻出自 web.dev 的 Web Vitals 說明。
實驗室數據和實際數據有什麼不同？
- 實驗室數據（Lighthouse）：在模擬的裝置與網路下測一次。適合開發時除錯，但不代表真實使用者。
- 實際數據（CrUX，Chrome 使用者體驗報告）：來自真實 Chrome 使用者的統計。Google 排名用的是這個。
新網站流量太少時沒有實際數據，只能先看實驗室數據。
每一項怎麼改善？
LCP 太慢
- 縮短伺服器回應時間（TTFB 建議低於 800 毫秒），使用 CDN。
- 主要圖片不要延遲載入（不要對首屏圖片加
loading="lazy"），並使用 WebP、AVIF 等新格式。 - 減少阻擋渲染的 CSS 與 JavaScript。
INP 太慢
- 減少主執行緒上的長時間 JavaScript 工作。
- 移除用不到的第三方腳本（廣告、追蹤碼、聊天小工具通常是元兇）。
- 把大量運算拆成小段，或延後到使用者互動之後。
CLS 太高
- 圖片與影片都要設定
width與height，讓瀏覽器預留空間。 - 廣告與嵌入內容預留固定大小的容器。
- 網頁字型使用
font-display: optional或預先載入，避免換字型時版面跳動。
用什麼工具量測？
- PageSpeed Insights：同時顯示實際數據（若有）與實驗室數據。
- Search Console 的「Core Web Vitals」報表：整站哪些網址不及格。
- Chrome 開發者工具的 Performance 面板：找出是哪段程式造成延遲。
為什麼靜態網站特別快？
本站選擇 Astro 的原因之一：它預設把頁面建置成純 HTML，不送出任何 JavaScript，除非你明確需要。沒有 JavaScript 要下載與執行，LCP 與 INP 自然就好。這對 GEO 也有幫助，因為 AI 爬蟲不需要執行 JavaScript 就能讀到內容（見〈GEO 生成式引擎優化〉）。
常見問題
PageSpeed Insights 分數 100 分才算好嗎？
不需要。Lighthouse 分數是實驗室模擬值，Google 排名使用的是真實使用者的 Core Web Vitals 數據。三項指標都在「良好」範圍內就足夠了。
FID 還是 Core Web Vitals 嗎？
不是。FID 已在 2024 年 3 月被 INP 取代，INP 衡量整個造訪期間所有互動的反應速度，比 FID 更完整。
網站速度對排名影響有多大？
Google 表示頁面體驗是排名訊號之一，但內容相關性遠比速度重要。當多個頁面內容品質相近時，體驗較好的可能勝出。