核心網站體驗指標（Core Web Vitals）與優化｜LCP、INP、CLS 完整解析

網站速度慢、操作卡頓、畫面亂跳,這些問題不只影響使用者體驗,也會影響搜尋表現。Core Web Vitals(網站核心指標)是 Google 用來量化「載入速度、互動反應、視覺穩定性」的三項核心指標——LCP、INP、CLS,屬於頁面體驗訊號的一部分,對 SEO 排名有參考價值,但不會單獨決定排名。在 2026 年的 AI 搜尋時代,使用者透過 ChatGPT、Perplexity、Google AI Overviews 進入網站後,前 3 秒的體驗就決定他們是否願意停留。這篇文章適合網站經營者、SEO 人員、前端工程師,以及正在改善網站效能的人閱讀,將從定義、門檻、量測工具、優化方向到常見誤區,一次整理清楚。

什麼是 Core Web Vitals?

Core Web Vitals(中文常稱「網站核心指標」)是 Google 用來衡量頁面真實使用者體驗的一組核心指標,重點在三件事:主要內容是否能快速出現、使用者操作後是否能迅速得到回應,以及頁面在載入過程中是否保持穩定。Google Search 文件將其描述為衡量「載入效能、互動性、視覺穩定性」的指標集合。

目前穩定的 Core Web Vitals 指標共有三個,各自對應一個體驗面向:

為什麼 Core Web Vitals 對 SEO 與體驗都重要?

很多人提到 Core Web Vitals,第一反應是「這是 SEO 要看的東西」。這樣說不算錯,但不夠完整。更準確地說,Core Web Vitals 是把使用者對網站的真實感受,轉換成可被量化、可被追蹤、可被優化的技術指標。

從使用者體驗角度看

當三項指標表現不佳時,使用者實際感受到的問題是這樣的:

• LCP 太慢 ── 使用者覺得「這頁是不是壞了?主圖怎麼一直沒出現?」,跳出率上升
• INP 太差 ── 按下按鈕沒反應,使用者連續點擊好幾次,造成表單重複送出或抱怨「網站很卡」
• CLS 過高 ── 正準備點連結時畫面突然跳動,結果誤點到廣告或其他按鈕,中斷閱讀體驗

從 SEO 與 AI 搜尋角度看

Google 明確表示 Core Web Vitals 會被納入排名系統的考量,但分數好不代表一定能排在前面,因為搜尋結果仍會綜合內容品質、相關性與其他頁面體驗因素。也就是說,Core Web Vitals 更像是網站品質的基本盤(及格門檻),而不是單一的排名捷徑。

在 2026 年的 AI 搜尋時代,這件事變得更重要。當 ChatGPT、Perplexity、Google AI Overviews 把您的網站列為引用來源,使用者點擊進站後若遇到載入慢、畫面亂跳的體驗,不只會降低品牌印象,還會直接影響轉換率。台灣中小企業常見的問題是「網站平常感覺還好,但廣告投放後跳出率特別高」,這時 Core Web Vitals 通常就是隱藏原因。

Core Web Vitals 三大指標解析

LCP 是什麼?(Largest Contentful Paint)

LCP 用來衡量頁面主要內容何時完成顯示。這個「最大內容元素」通常是首屏大圖、主視覺區塊、Hero Banner,或一段大型文字內容(例如部落格的主標題與導言段落)。它反映的不是整頁全部載完的時間,而是使用者何時覺得「這頁主要內容終於出現了」。

LCP 變差的常見原因可以歸納為四類:

• 伺服器回應慢(TTFB 過長) 主機效能不足、共享主機壅塞、資料庫查詢未優化,都會讓伺服器在收到請求後遲遲不回傳資料。
  使用低價共享主機的 WordPress 網站,常因鄰居網站流量爆量導致整台主機變慢,TTFB 從 200ms 拉到 1500ms。
• 首屏圖片過重或未優化 主視覺圖檔案太大(數 MB)、未使用 WebP/AVIF 格式、沒有 srcset 響應式尺寸,或缺少 fetchpriority="high"。
  電商首頁主視覺用 3000×2000px 的 JPEG(2.8MB),改成 1600×1067px 的 WebP(280KB)後,LCP 直接從 4.2 秒降到 1.9 秒。
• 關鍵 CSS 或 JS 阻塞渲染 首屏需要的 CSS 沒有 inline 處理、第三方 JS(廣告、客服、追蹤碼)排在前面同步載入,擋住瀏覽器渲染主內容。
  頁面前段同時掛上 GTM、Facebook Pixel、客服小工具、A/B 測試工具,光是這些就讓主執行緒卡 1.5 秒以上。
• 資源優先順序配置不當 重要的首屏資源被排在後面,反而把不重要的腳本排在前面。
  首頁底部的「精選文章區塊」的圖片用 eager loading,但首屏主圖卻沒設定 fetchpriority="high",造成資源搶頻寬。

INP 是什麼?(Interaction to Next Paint)

INP 用來衡量使用者操作後,到下一次畫面更新之間的延遲表現。這項指標於 2024 年 3 月正式取代 FID,成為 Core Web Vitals 中負責互動反應的核心指標。Google 說明,原因在於 INP 比 FID 更能反映整體互動品質,而不只看第一次輸入延遲。

INP 與 FID 的關鍵差異在於:FID 只測量第一次互動的延遲,INP 則測量整個 session 中所有互動的延遲表現,並取較差的數值。這代表只有「全程都順暢」的網站才能拿到好分數,任何一次卡頓都會被記錄。

INP 不佳的常見症狀

INP 表現不佳的網站,使用者最常抱怨的是「按鈕明明可以點,但點下去後畫面延遲很久才有反應」。這通常與以下原因有關:

• 長時間執行的 JavaScript:單一任務超過 50ms 就會影響 INP,超過 200ms 則直接落入「不佳」區間
• 主執行緒阻塞:大型陣列運算、複雜的 DOM 操作、未優化的事件處理器
• 框架 hydration 過重:Next.js、Nuxt 等 SSR 框架在 client 端重新建立元件樹時佔用主執行緒
• 同步觸發大量計算:篩選器一次重新計算所有商品、搜尋建議即時呼叫 API、表單欄位每次輸入都驗證整份資料

CLS 是什麼?(Cumulative Layout Shift)

CLS 用來衡量頁面載入過程中是否出現非預期的版面位移。CLS 偏高時,常見情況是您正要點連結,畫面卻突然跳動,結果誤點到其他內容。web.dev 在 CLS 說明中提到,這類位移常見原因包括圖片或影片未預留尺寸、第三方廣告或小工具動態改變大小,以及字型替換導致版面變動。

CLS 雖然不像 LCP 或 INP 那樣常被視為「效能」議題,但對實際體驗的破壞很直接。尤其在內容網站、媒體站或電商頁面中,若推薦模組、廣告位或彈窗在畫面已出現後才插入,就很容易造成位移。CLS 累計計算頁面 lifecycle 中所有位移分數,目標是讓使用者不會因為版面晃動而中斷閱讀或誤觸。

Core Web Vitals 的標準門檻

目前官方建議的「良好(Good)」門檻為:LCP ≤ 2.5 秒、INP ≤ 200 毫秒、CLS ≤ 0.1。這些門檻以第 75 百分位(p75)作為評估基準,目的是讓多數使用者(75%)都能獲得良好體驗,而不是只有少數高效能裝置上的使用者表現良好。

如何量測 Core Web Vitals(工具總覽)

Core Web Vitals 的量測可分成兩種:Field Data(真實使用者資料)與 Lab Data(實驗室資料)。前者反映真實訪客在各種裝置與網路條件下的實際體驗,後者則適合在開發階段重現問題、定位瓶頸,並驗證修正效果。

常用量測工具對照

推薦的量測工作流程

• 用 Search Console 找「有問題的頁面群」 進入「Core Web Vitals 報告」,看哪些頁面被歸類為「不佳」或「需要改善」,並注意是手機版還是桌機版問題。
• 用 PageSpeed Insights 診斷代表性頁面 從問題頁面群中挑 1-2 個代表性 URL,看 Field Data 的具體數值,並對照下方的優化建議清單。
• 用 Lighthouse 找出技術瓶頸 在 Chrome DevTools 開啟 Lighthouse,執行 Mobile 模式測試,觀察「Diagnostics」與「Opportunities」區塊。
• 用 WebPageTest 看瀑布圖找根因 如果問題複雜,進一步用 WebPageTest 分析資源載入順序、阻塞時間、Long Tasks 落在哪個腳本上。
• 改完後等 28 天再看 Field Data CrUX 資料是 28 天移動平均,改動後不會立刻反映在 Search Console。期間用 Lab Data 驗證即可。

Core Web Vitals 優化方法

每項指標的優化邏輯不同,以下分別說明最有效的改善方向,並補充常見實作技巧。

LCP 優化重點

LCP 的改善核心,不是讓所有資源同時變快,而是讓「首屏最重要的內容」更早出現。可從四個方向著手:

• 降低 TTFB(伺服器回應時間) 升級主機規格、啟用伺服器端快取(如 Redis、Memcached)、使用 CDN 把靜態資源分散到全球節點。
  WordPress 網站啟用 Cloudflare CDN + WP Rocket 快取外掛,TTFB 可從 800ms 降到 150ms 以下。
• 壓縮並優化首屏圖片 使用 WebP 或 AVIF 格式、設定 fetchpriority="high"、加上 srcset 提供響應式尺寸、首屏圖片不要用 lazy loading。
  首屏主視覺改用 AVIF 格式(較 WebP 再省 30% 容量),搭配 fetchpriority="high",可讓圖片在主執行緒空檔優先載入。
• 減少阻塞渲染的 CSS 與 JS 首屏關鍵 CSS 用 inline、非關鍵 CSS 用 media="print" 技巧延遲載入、第三方腳本一律加 async 或 defer。
  GTM、Facebook Pixel、客服小工具改用 defer 或延遲到 onload 之後執行,LCP 可降低 30-50%。
• 使用 preload 提升資源優先級 對首屏字型、主視覺圖、關鍵 JS 使用 <link rel="preload">,告訴瀏覽器這些資源最重要。
  首屏使用 Noto Sans TC 字型時,在 head 加上 preload 並設 crossorigin,可避免字型延遲導致的視覺位移。

<!-- 首屏主圖優先載入 + 響應式尺寸 -->
<img src="hero-1600.avif"
     srcset="hero-800.avif 800w, hero-1600.avif 1600w, hero-2400.avif 2400w"
     sizes="(max-width: 768px) 100vw, 1600px"
     fetchpriority="high"
     width="1600" height="900"
     alt="主視覺說明">

<!-- 首屏字型預先載入 -->
<link rel="preload" href="/fonts/NotoSansTC.woff2"
      as="font" type="font/woff2" crossorigin>

<!-- 第三方腳本延遲執行 -->
<script src="https://www.googletagmanager.com/gtag/js" defer></script>

INP 優化重點

INP 的改善重點,是讓互動後的處理流程更短、更輕。web.dev 把「拆分長任務、經常讓出主執行緒」列為改善 INP 的關鍵方法。

• 拆分長任務(Long Tasks) 把超過 50ms 的任務切成小塊,用 setTimeout、scheduler.yield() 或 requestIdleCallback 讓出主執行緒。
  商品列表一次渲染 1000 筆改成「先渲染 30 筆,其餘用 requestIdleCallback 分批處理」,INP 從 480ms 降到 120ms。
• 移除不必要的第三方腳本 盤點所有第三方 JS,刪除沒在用的追蹤碼、聊天工具、A/B 測試工具。每個第三方腳本都是 INP 殺手。
  某電商網站同時掛 12 個第三方腳本,移除 5 個沒在追蹤數據的工具後,INP 改善 40%。
• 使用 debounce 與 throttle 搜尋建議、表單即時驗證、視窗 resize 事件,都應使用 debounce(延遲執行)或 throttle(限制頻率)避免過度觸發。
  搜尋框輸入時的 API 呼叫加上 300ms debounce,使用者打字流暢度大幅提升,且 API 請求量減少 70%。
• 用 Web Worker 處理重運算 把大型運算(排序、過濾、資料處理)搬到 Web Worker 中,不阻塞主執行緒。
  電商網站的進階篩選功能(從 5000 筆商品中即時過濾)改用 Web Worker,INP 從 600ms 降到 80ms。

CLS 優化重點

CLS 的優化方向通常最明確、最容易快速見效。圖片、影片、iframe 都應預先設定寬高;廣告位、推薦模組、嵌入式內容也不應在畫面顯示後才突然改變尺寸。

• 圖片與影片預先指定寬高 所有 <img>、<video>、<iframe> 都要設定 width 與 height 屬性,讓瀏覽器在資源載入前就預留空間。
  部落格文章內的圖片若沒設 width/height,文字會在圖片載入時被往下推,CLS 可能從 0 暴增到 0.4。
• 為動態內容預留空間 廣告位、推薦商品區塊、訂閱表單彈窗,都應在 HTML 結構中先用 min-height 或骨架屏(skeleton)佔位。
  廣告位設定 min-height: 280px,即使廣告載入失敗或延遲,版面也不會塌陷或跳動。
• 優化字型載入策略 使用 font-display: optional 或 swap,並透過 size-adjust 微調備援字型的寬高,讓字型切換時版面變動最小。
  中文網站使用 Noto Sans TC 時,先用系統字型(PingFang TC / Microsoft JhengHei)顯示,避免字型載入時的大幅重排。
• 避免在現有內容上方插入新內容 浮動公告、Cookie 提示、彈窗等元素應使用 position: fixed 或 position: absolute 浮在內容上方,不要插入文件流中推擠原有內容。
  Cookie 同意彈窗從「插入頁面頂部推擠所有內容」改成「fixed 在底部浮層」,CLS 直接歸零。

常見錯誤與優化優先順序

很多網站不是不知道要做 Core Web Vitals,而是用錯方法、花錯地方、做錯順序。以下六個常見錯誤,幾乎每個團隊都會踩到:

• 看到分數不好就全面重構 這通常成本高,也不一定能優先解到問題。改善方式:先找出高流量、高價值頁面(首頁、商品頁、結帳頁),確認是 LCP、INP 還是 CLS 出問題,再對症下藥。一次只改一個指標。
• 只看測速工具分數,忽略商業頁面 首頁、商品頁、分類頁、文章頁、結帳頁的價值不同,優化排序應該不同。改善方式:對企業來說,最值得先做的不是「所有頁面一起變好」,而是「最關鍵的頁面先改善」。例如電商先處理結帳頁,媒體先處理熱門文章頁。
• 把 Core Web Vitals 當成 SEO 全部 Google 已明確說明,Core Web Vitals 只是頁面體驗的一部分,不保證分數好就能拿到最好排名。改善方式:把 CWV 當成「基本盤」而非「決勝關鍵」。內容品質、搜尋意圖匹配、E-E-A-T 仍然是不可取代的核心。
• 只測首頁,忽略內頁與手機版 首頁通常被優化過了,真正拖累整站分數的往往是商品頁、文章頁、搜尋結果頁。改善方式:用 Search Console 的 Core Web Vitals 報告找出「問題頁面群」,並區分手機版與桌機版分別處理。台灣 70% 以上流量來自手機,手機版優先。
• 改完當天就期待分數提升 CrUX 真實使用者資料是 28 天移動平均,改完當天不會立刻反映。改善方式:改完先用 Lab Data(Lighthouse、WebPageTest)驗證效果,並等 4 週後再看 Field Data。期間別急著推翻改動。
• 用本機開發環境測效能 開發者用光纖網路 + 高階電腦測試,當然飛快。改善方式:Lighthouse 要切到「Mobile + Slow 4G」模式測試,模擬真實使用者環境。若有預算,使用 BrowserStack 或實體中階手機(如 Samsung A 系列)實測更準確。

建議的優化優先順序

如果不知道從哪裡開始,可以依照以下順序處理:

結論

Core Web Vitals 不只是技術名詞,而是一套把使用者感受轉為可管理指標的方法。LCP 看主要內容是否能快速出現、INP 看互動是否足夠即時、CLS 看畫面是否保持穩定。如果網站在這三項表現都不佳,使用者通常也很難對整體體驗留下好印象,更別說提升轉換率。

真正有效的優化路徑可以濃縮成五個步驟,在改版前可先自我檢查:

• 是否已經用 Search Console + PageSpeed Insights 找出真正有問題的頁面群?
• 是否確認問題出在 LCP、INP 還是 CLS?三者的優化邏輯完全不同。
• 是否優先處理高流量、高價值頁面(首頁、商品頁、結帳頁)而非所有頁面一起改?
• 是否同時驗證 Lab Data 與 Field Data?本機快不代表使用者快。
• 是否設定持續追蹤機制?改完一次不代表永久,新功能上線都可能讓分數退步。

常見問答 FAQ