速度差，排名就掉：Google 如何用體驗指標打分
點開一個網站，等了三秒畫面還是空白；正要點按鈕，頁面突然跳動讓你誤觸了廣告。這些讓人想直接關掉分頁的瞬間，正是 Google 在 2021 年推出 Core Web Vitals（核心網頁指標）想要量化並改善的問題。
Core Web Vitals 是 Google 官方定義的三項指標，用來衡量真實使用者實際感受到的網站效能，目前已正式納入搜尋排名演算法（Page Experience 訊號）。白話說：你的載入速度與互動流暢度，會直接反映在 Google 自然排名上。
對想在台灣市場搶 SEO 優勢的品牌來說，把這三項指標顧好，不只是技術加分，更是當內容同質化時拉開差距的籌碼。以下從三大指標講起，並給出可以馬上動手的優化做法。
LCP、INP、CLS 各自在量什麼？
2025–2026 年的三項 Core Web Vitals 指標如下，分別對應載入、互動、穩定三個面向。
LCP：使用者多久才看到「主要內容出現」
LCP（Largest Contentful Paint，最大內容繪製） 測量頁面最大的圖片或文字區塊完成渲染所需的時間。它代表使用者感知到「這頁載好了」的那一刻——使用者在意的是畫面什麼時候看起來完整，而不是背景還有多少資源在偷偷下載。
- 良好（Good）：≤ 2.5 秒
- 待改善（Needs Improvement）：2.5 – 4.0 秒
- 不佳（Poor）：> 4.0 秒
常見的 LCP 元素包括英雄圖（Hero Image）、大型文字標題、影片縮圖。如果你的首頁有一張全幅橫幅圖，那張圖的載入速度通常就決定了整個 LCP 分數。
INP：每次點擊後，畫面多快給你回應
INP（Interaction to Next Paint） 是 2024 年 3 月正式取代 FID（First Input Delay） 的新指標，衡量使用者點擊、按鍵或觸碰之後，瀏覽器完成對應視覺更新所花的延遲。
FID 只看「第一次互動」，INP 則持續觀察整個工作階段中的所有互動，取其中最差的結果（排除少數異常值）作為代表值。這讓它更貼近真實使用感受：偶爾卡一次還能忍，但每一次操作都要等半秒才有反應，使用者很快就會失去耐心。
- 良好（Good）：≤ 200 毫秒
- 待改善（Needs Improvement）：200 – 500 毫秒
- 不佳（Poor）：> 500 毫秒
CLS：版面在你眼前跳了幾次
CLS（Cumulative Layout Shift，累積版面配置偏移） 衡量頁面載入過程中，可見元素因非預期原因發生位移的總量。分數越低，版面越穩定，使用者越不會誤點或被打斷閱讀。正在看文章時被插入的廣告擠開、要按按鈕時按鈕忽然位移讓你點到旁邊的連結——這些都會推高 CLS。
- 良好（Good）：≤ 0.1
- 待改善（Needs Improvement）：0.1 – 0.25
- 不佳（Poor）：> 0.25
| 指標 | 衡量內容 | 良好門檻 | 主要影響因素 |
|---|---|---|---|
| LCP | 最大內容載入時間 | ≤ 2.5 秒 | 圖片大小、伺服器回應、渲染阻塞資源 |
| INP | 互動到畫面更新延遲 | ≤ 200 毫秒 | JavaScript 執行量、長任務、事件處理器 |
| CLS | 版面偏移累積分數 | ≤ 0.1 | 圖片無尺寸屬性、動態插入內容、字型載入 |
動手優化前，先量出你的現況
沒有數據就不知道從哪改起。Google 提供了完整的工具生態，數據分為兩種類型：「Lab Data（模擬環境）」與「Field Data（真實用戶數據）」。
四個必備的測量工具
- PageSpeed Insights（最推薦入門）：輸入 URL 就能拿到 Lab 與 Field 雙重數據，並同時給出優化建議。搜尋「PageSpeed Insights」即可使用免費版。
- Google Search Console — 核心網頁指標報告：以全站視角呈現哪些頁面群組「通過」或「需改進」，數據來源為 CrUX（Chrome User Experience Report）的真實用戶資料。
- Chrome DevTools + Lighthouse：開發者最常用的本地測試工具，可模擬不同網速與裝置，定位具體的效能瓶頸。
- web-vitals.js：Google 官方 JavaScript 函式庫，可嵌入網站持續收集真實用戶的 Core Web Vitals 數據，並與 Google Analytics 4 整合。
關鍵提醒：排名評估用的是 Field Data（真實用戶數據），不是 Lab Data。Lab Data 只是診斷與參考工具，Search Console 裡的 CrUX 數據才是 Google 判斷你網站是否「通過」的依據。別只盯著 Lighthouse 的高分自我感覺良好。
LCP 優化：讓主要內容更快出現
LCP 是最容易讓使用者「有感」的指標，也是多數網站最需要動刀的地方。以下五招都是經過驗證的做法。
1. 優化圖片格式與大小
圖片通常就是那個 LCP 元素，在多數網站佔總體積的 50–70%，因此往往是投報率最高的優化項目。把圖片轉成 WebP（比 JPEG 小 25–35%）或 AVIF（比 JPEG 小約 50%、比 WebP 再小 30%，2026 年首選），能在相同畫質下大幅省下檔案大小。實務上用 <picture> 標籤提供 AVIF + WebP 的漸進式 fallback，並用 srcset 針對不同螢幕尺寸供給對應解析度，避免手機下載 2400px 寬的大圖再縮小顯示。
2. 預載入關鍵資源（Resource Hints）
對 LCP 圖片加上 <link rel="preload">，讓瀏覽器優先下載這項資源，而不是等解析到 HTML 那一行才開始抓：
<link rel="preload" as="image" href="/hero-image.webp" fetchpriority="high">3. 用 CDN 加速靜態資源
內容傳遞網路（CDN）把靜態資源部署到全球節點，讓台灣用戶從最近的伺服器拿到圖片與腳本，有效降低 TTFB（首位元組時間），連帶改善 LCP。以台灣為主要市場的網站，Cloudflare 免費方案對多數中小型網站已足夠，設定流程約 30 分鐘，幾乎是零成本的速度提升；通常可降低延遲 50–70%，其中 TTFB 改善最明顯。
4. 移除渲染阻塞資源
把非必要的 CSS、JavaScript 標記為 defer 或 async，別讓它們卡住瀏覽器繪製主要內容。再搭配「關鍵 CSS 內嵌（Critical CSS Inlining）」，讓首屏所需樣式直接寫進 HTML。
5. 壓低伺服器回應時間（TTFB）
目標是把 TTFB 壓到 800ms 以下。可行方法：啟用伺服器快取、升級主機方案、改用邊緣運算（Edge Computing）。WordPress 網站則可用 WP Rocket 或 LiteSpeed Cache。
INP 優化：讓每次點擊都即時回應
INP 是 2024 年後最多網站踩坑的指標，尤其是大量使用 JavaScript 的 React、Vue、Angular 等 SPA（單頁應用）框架。
1. 拆分長任務（Long Tasks）
任何執行超過 50ms 的 JavaScript 任務都算「長任務」，會卡住主執行緒、拖慢互動。用 scheduler.yield()（Chrome 115+）或 setTimeout(0) 把長任務切成小段，讓瀏覽器在任務之間有空檔回應使用者操作。
2. 減少 JavaScript Payload
頁面初次載入用不到的 JavaScript，應該延後載入（Code Splitting）。用 Tree Shaking 移除未使用的程式碼，並分析 Bundle 大小找出冗餘依賴。React 應用就用 React.lazy() 與動態 import() 這套標準工具。
3. 用 Web Workers 接走重運算
把不需要操作 DOM 的複雜運算（資料排序、加密、圖片處理）丟到 Web Worker 執行，讓主執行緒保持輕盈，UI 才能持續流暢回應。
4. 整理事件監聽器
別在 click、keydown 的回呼函式裡塞耗時操作。善用 requestAnimationFrame 把 DOM 更新推到下一個渲染週期，減少強制重排（Forced Reflow）帶來的卡頓。
5. 管理第三方腳本
一個中型品牌網站平均裝了 15–30 個第三方腳本（Google Analytics、Facebook Pixel、LINE Tag、聊天小工具、各種廣告追蹤碼），每一個都需要額外的 DNS 解析、TCP 連線與執行時間，輕易就能為頁面添上 300–500ms 延遲並惡化 INP。瘦身四步驟：① 用 Chrome DevTools 的 Network 面板篩 Script 類型，清點所有第三方請求；② 逐一自問「今天移除它會有人發現嗎」，砍掉早就沒人在看報告的舊追蹤碼；③ 非首屏必要的腳本改用 defer / async，或設定在使用者第一次互動後才載入；④ 用 Google Tag Manager 集中管理，以觸發條件精準控制每個腳本的載入時機。
CLS 優化：讓版面配置保持穩定
CLS 通常出自幾個固定的「慣犯」，把它們揪出來修掉，分數往往就能大幅改善。
1. 永遠幫圖片和影片標好寬高
這是最簡單、CP 值最高的 CLS 修法。在 HTML 為所有 <img> 和 <video> 加上 width 與 height，讓瀏覽器在圖片下載前就先把空間預留好：
<img src="photo.webp" width="800" height="600" alt="描述文字">2. 為廣告和嵌入內容預留固定空間
廣告是 CLS 的頭號元兇。在廣告容器設定最小高度（min-height），就算廣告還沒載入，版面也不會被擠開。
3. 別在既有內容上方硬塞元素
要顯示橫幅通知、Cookie 同意欄或促銷訊息時，優先用固定定位（position: fixed 或 position: sticky），或事先保留固定高度的容器，而不是動態把既有內容往下推。
4. 處理好字型載入策略
自訂字型載入前會先顯示備用字型，若兩者尺寸差很多，就會出現「FOUT（無樣式文字閃現）」造成版面跳動。建議用 font-display: optional：字型沒及時到位時直接沿用備用字型，避免版面重排。
傳輸層加速：Brotli 壓縮與 HTTP/3
有些速度問題不在內容本身，而是卡在傳輸層——資源已經優化過，傳輸效率卻拖了後腿。以下幾項調整幾乎零成本，而且主流 CDN 多半預設支援：
- 用 Brotli 取代 Gzip：Brotli 是 Google 開發的新一代文字壓縮演算法，壓 HTML / CSS / JavaScript 等文字資源時，比 Gzip 再省下 15–30% 的體積。Cloudflare、Netlify、Vercel 多半預設啟用；自管的 Nginx / Apache 需確認已手動開啟 Brotli 模組。
- 啟用 HTTP/3（QUIC）：HTTP/3 解決了 HTTP/2 在高延遲或封包遺失場景下的瓶頸——這在行動網路環境特別常見。實測連線建立速度比 HTTP/2 快約 30%，對台灣行動使用者的體驗提升尤其明顯。
- 長期瀏覽器快取：靜態資源設定
Cache-Control: max-age=31536000, immutable，讓回訪使用者不必重新下載相同資源。 - 預先連線（preconnect）：對 Google Fonts、CDN、分析服務等重要第三方網域，在
<head>加入<link rel="preconnect">，提前完成 DNS 解析與 TCP 握手，減少實際載入時的等待。
依投報率排序：3–5 小時的優化行動清單
Google 自己給過一組震撼數字：頁面載入時間從 1 秒增加到 3 秒，跳出率提升 32%；拉長到 5 秒，跳出率飆升 90%。反過來，每節省 100ms，電商網站的轉換率平均提升 1–2%。面對一長串待辦，關鍵是按投報率排序，把有限時間花在效益最高、難度最低的項目。以下清單實測可在 3–5 小時內完成：
| 優先序 | 優化項目 | 預估效益 | 執行難度 |
|---|---|---|---|
| P1 | 圖片轉 AVIF/WebP + 尺寸縮減 | LCP 改善 0.5–1.5s，體積 −30–50% | 低 |
| P2 | 啟用 CDN（Cloudflare 免費版） | TTFB 降低 50–70% | 低 |
| P3 | LCP 圖片加 <link rel="preload"> | LCP 改善 0.3–0.8s | 低 |
| P4 | 移除或延遲非必要第三方腳本 | INP 改善 100–300ms | 中 |
| P5 | 所有圖片加 width/height 屬性防 CLS | CLS 歸零或大幅降低 | 低 |
| P6 | 確認 Brotli 壓縮 + HTTP/3 已開啟 | 資源體積降低 15–30% | 低 |
| P7 | 字型優化（font-display + preload） | CLS 改善、FCP 提升 | 低 |
| P8 | JavaScript Code Splitting | INP 改善、TTI 降低 | 高 |
分數差，排名真的會掉嗎？
這大概是最多人問的問題。答案是：有影響，但它不是唯一決定因素。
Google 明確說過，在內容相關性相近的情況下，通過 Core Web Vitals 門檻的頁面會拿到排名加分。評估基準是第 75 個百分位數（P75）——也就是你網站中 75% 的真實用戶體驗都要達到「良好」。
更重要的觀念是：目標是「通過（Pass）」，不是「追求滿分」。LCP 1.8 秒的網站和 LCP 0.9 秒的網站，排名上幾乎沒差；但 LCP 1.8 秒和 LCP 4.5 秒就差很多。先讓所有頁面進入「良好」區間，再去想極致優化。
就我們對台灣市場的觀察，B2B 服務頁和電商商品頁受 Core Web Vitals 影響最明顯——這些頁面圖片多、JavaScript 複雜，而且競爭頁面之間內容高度同質，速度就成了關鍵的差異化因素。延伸閱讀：Google 到底看哪些 SEO 排名因素？
排名不只看技術分數：使用者行為 UX 信號
Core Web Vitals 是可量化的技術門檻，但 Google 蒐集的訊號不止於此。2024 年外洩的 Google API 文件顯示，它確實分析了大量來自 Chrome 瀏覽器的真實互動數據。幾個被普遍認為與排名高度相關的 UX 行為信號，值得和速度一起顧好：
- 點擊率（CTR）：SERP 上的點擊率是使用者對你標題與描述最直接的投票，高 CTR 往往與較高排名呈正相關。撰寫具情感觸發力的標題、在描述中正面回答核心問題，都能拉高 CTR。
- 停留時間與滾動深度：使用者從點入頁面到返回 SERP 的這段時間（Dwell Time）越長，通常代表內容越能接住搜尋意圖。首屏立即傳遞核心價值、用目錄引導往下探索、適時插入影片或互動元素，都能加深參與。
- Pogo-sticking：進站後幾秒內就返回 SERP 改點其他結果，是相當刺眼的負面信號。常見成因是頁面載入過慢、內容與搜尋意圖不符、首屏被廣告佔據或設計令人困惑。
這些信號的源頭，其實是版面設計——好的版面讓使用者自然往下讀，壞的設計則讓人第一眼就想關掉分頁。下表整理幾個常被忽略的版面元素與其 UX 信號效果：
| UX 設計元素 | 對 UX 信號的影響 | 優化建議 |
|---|---|---|
| 首屏設計 | 降低 Pogo-sticking 機率 | 5 秒內傳達核心價值 |
| 頁面目錄 | 提升滾動深度與停留時間 | 浮動側邊欄或頂部目錄 |
| CTA 按鈕設計 | 影響點擊率與轉換行為 | 對比色、明確動詞文案 |
| 相關文章推薦 | 提升每次工作階段頁面數 | 文末自動推薦 3 篇相關 |
| 進度條 | 鼓勵讀者讀完全文 | 頂部閱讀進度指示器 |
2025–2026：Core Web Vitals 的新戰場
Core Web Vitals 不是定下來就不動的標準，Google 持續在調整評估方式，這幾個趨勢值得盯著：
- INP 成為主戰場：2024 年 INP 取代 FID 後，前端框架（React、Vue、Next.js）的互動效能優化變成熱門題目，
React 19的 Concurrent Mode 與scheduler.yield()API 被廣泛採用。 - AI 生成內容的 CLS 風險：AI 串流輸出（Streaming Text）在前端逐字渲染時容易引起版面跳動，開發者要特別處理保留空間。
- Speculation Rules API：Chrome 108+ 支援的新 API，可預先載入使用者可能點擊的下一頁，大幅改善「頁面轉換」的感知速度。
- Edge Computing 壓低 TTFB：Cloudflare Workers、Vercel Edge Functions 等邊緣運算服務讓伺服器回應時間明顯縮短，LCP 跟著改善。
- 速度影響 AI 搜尋的引用意願：根據業界觀察，Perplexity 和 Google AI Overview 在爬取引用來源時，載入失敗或過慢的頁面被選為答案來源的機率會下降。速度已經不只是排名問題，也關係到 AI 引用率。延伸閱讀：AEO 答案引擎優化完整指南
TOPCLASS 觀點：速度是 SEO 的前置條件，不是加分題
在輔導台灣品牌做 SEO 的過程裡，我們看到一個反覆出現的規律：成效突出的企業，往往是最早把技術問題解掉的那一批。Core Web Vitals 就是一道明顯的分水嶺。一個更直接的觀察是——我們診斷的網站中，超過 60% 的行動版 PageSpeed 分數低於 50 分，但這些網站往往有精心的視覺設計與豐富內容；問題不在不夠用心，而在使用者根本等不到內容呈現就先離開了。
很多品牌把預算重壓在內容創作與關鍵字上，卻忽略了「網站會不會讓用戶等到不耐煩就跑掉」。一篇排名第五的文章，點進去要等四秒才載入，跳出率會高得嚇人；而這個高跳出率，又會反過來把排名往下拖，形成惡性循環。
速度優化的投報率，在多數案例中都意外地高：一次集中的速度改善工程，通常帶來 15–30% 的有機流量提升（排名改善）與 10–20% 的轉換率提升（體驗改善），投入一次、長期受益。我們的建議很直接：把三項指標「全部通過」當成 SEO 的前置條件，而不是錦上添花。先用 PageSpeed Insights 跑行動版測試做一次全站健診，找出實地數據裡紅色的頁面群組（通常是商品頁或部落格文章頁），從圖片優化和 CDN 開始一個一個動手——大多數網站 80% 的速度問題都集中在這兩項，而且通常不必動程式碼就能完成。
延伸閱讀：台灣品牌最常踩的 10 個 SEO 地雷、Schema 結構化資料實戰指南
Core Web Vitals 不是修一次就結案，而是要持續監控的品質標準。建議每季透過 Google Search Console 查看核心網頁指標報告，確保新功能上線後沒有引入效能退化。速度優化的複利會隨時間累積，讓你的競爭優勢越來越難被追上。