Core Web Vitals 是 Google 用真實 Chrome 使用者資料衡量網頁體驗的一組指標，目前穩定版本包含 LCP（最大內容繪製，良好門檻 2.5 秒內）、INP（互動至下一次繪製，良好 200ms 內，已於 2024 年 3 月正式取代 FID）、CLS（累計版面配置位移，良好 0.1 以內）三項。它跟單純測「網站多快打開」不同，因為資料來自真實使用者的回報（CrUX），不是用一台機器跑模擬，這也是 SEO 站長在 Search Console 看到「網頁體驗」紅燈時，真正該看懂的數字。
TL;DR：Core Web Vitals 是 tie-breaker 而非主角，LCP 2.5 秒、INP 200ms、CLS 0.1 三項都過門檻即可拿到體驗分，過了門檻再壓數字對排名邊際效益很小，真正該投資的是先過門檻、再回去補內容與連結（來源：web.dev、Google Search Central）。
很多人看到這裡會問：那 CWV 到底值不值得花工程資源改？這篇會把定義、三大指標門檻、field 與 lab 兩份分數的差異、逐項實戰改善順序，一路講到 2026 年 AI 搜尋時代 CWV 還有沒有投資價值。如果你之前把 PSI 分數當信仰，這篇會幫你把心態校正回來。
先把一個最常見的誤解講掉：CWV 不是「網站越快排名越高」的線性關係，而是「過了門檻就拿到體驗分，沒過就掉隊」的門檻關係。這個觀念會貫穿整篇文章，因為它直接決定你該把工程資源花在哪。如果心裡還停留在「分數越高越好」，那麼後面每一個改善順序的判斷都會被這個迷思帶偏。把它想成考駕照的及格制，過了就好，沒有人會因為你考一百分就讓你開兩台車。
文章目錄
Core Web Vitals 是什麼：Google 用真實使用者資料量的三項體驗指標
Core Web Vitals（簡稱 CWV）是 Google 定義的頁面體驗核心指標，用來衡量「真實使用者」在網頁上的體驗，目前穩定版本就是 LCP、INP、CLS 三項的組合（web.dev 官方總覽）。它跟你平常聽到的「網站速度」最大的差別在於：速度只看載入，CWV 還同時看互動回應（INP）跟視覺穩定（CLS）。
關鍵差異在資料來源。CWV 用的是 field 資料，也就是 Chrome 真實使用者回傳的 Chrome UX Report（CrUX），不是用一台固定規格的機器跑模擬。這也是為什麼 PageSpeed Insights 會同時給你兩份分數，而兩份常常對不上。這不是工具壞了，是兩種資料本來就在量不同的東西。
如果只看「首頁幾秒打開」，你會漏掉兩種體驗地獄：點了按鈕半天才反應（INP 卡住），以及廣告載入後把你要點的按鈕擠到別的地方（CLS 位移）。這兩種痛用單純的速度測試完全測不出來。CWV 屬於 頁面體驗訊號的一部分，不是獨立的排名魔法，這個定位我們後面會講清楚。
LCP、INP、CLS 三大指標標準：測什麼、門檻多少一次看懂
三大指標各有明確門檻，而且這些數字都有 web.dev 官方來源，可以直接拿來當判斷標準。LCP 測主要內容的載入速度，INP 測頁面對點擊與輸入的回應速度，CLS 測頁面載入過程的視覺穩定度。三項都跨過「良好」門檻，就拿到 Core Web Vitals 的體驗分數。
| 指標 | 測什麼 | 良好 | 需改善 | 不佳 | 常見瓶頸 |
|---|---|---|---|---|---|
| LCP | 最大可見元素渲染完成時間 | ≤ 2.5 秒 | 2.5 – 4 秒 | > 4 秒 | 伺服器回應慢、大圖未壓縮、阻斷渲染的 CSS/JS |
| INP | 頁面所有互動中最慢那次（代表整體回應） | ≤ 200ms | 200 – 500ms | > 500ms | 主執行緒被 JS 卡住、第三方腳本、長任務 |
| CLS | 頁面生命週期內非預期位移累計分數 | ≤ 0.1 | 0.1 – 0.25 | > 0.25 | 圖片無尺寸、字型載入推擠、動態插入內容 |
INP 已在 2024 年 3 月正式取代 FID
這裡要特別提醒：INP 於 2024 年 3 月正式取代舊指標 FID（首次輸入延遲），成為穩定的核心指標（web.dev INP 官方文件）。舊的「最佳化 FID」建議大量失效，因為 FID 只測首次輸入延遲，INP 測的是整個頁面所有互動裡最慢那一次，標準嚴格得多。如果你看的中文教學還停在 FID 時代，那篇八成過期了。
實務上很多人只記得「2.5 秒」這個 LCP 數字，卻忘了 INP 跟 CLS，結果 PSI 分數還是紅燈。說實在話，LCP 過了不等於體驗過了，三大指標是各自獨立評分的。要懂完整的排名因素脈絡，可以搭配 SEO 排名因素一起看。
Core Web Vitals 會影響排名嗎：它是 tie-breaker 不是主角
會影響，但不是主角。Google 自己把頁面體驗訊號定位為 tie-breaker，意思是只有在「兩個頁面內容相關度差不多」時，體驗分數才會拿來當決勝條件（Google Search Central 官方文件）。所以該投資的順序是：先把三大指標拉過「良好」門檻、別停在紅燈區，然後把主力放回內容與連結。
老實說，我早期也把 PSI 滿分當信仰，以為分數越高排名越好，拼命把 LCP 從 2 秒壓到 1 秒。後來發現排名根本沒跟著動。過了門檻之後，再繼續壓數字，對排名的邊際效益很小。CWV 的確切排名權重 Google 沒公開，這裡講的是官方定位，不是精確比例。
ROI 判斷：紅燈值得改，過門檻就收手
判斷 ROI 很簡單：停留在不佳（紅燈）就值得改，因為你在同分時會輸；剛過門檻進入「良好」，再壓分數的邊際效益低，該回去補 On-Page SEO 與 內部連結。體驗訊號的附帶價值在於載入快、互動順、版面穩，通常伴隨較高的留存與轉換，這是業界普遍觀察，但我們不寫死百分比，各家研究數字差太多。
體驗好的頁面，停留時間通常較長、跳出率較低，這對 自然流量是正循環。但要記得，這是副產品，不是 CWV 直接推升排名。想看頁面體驗是不是排名因素的完整觀念論戰，可以讀這篇頁面體驗訊號解析，本篇則聚焦在 CWV 怎麼測、怎麼改。
怎麼測 Core Web Vitals：PageSpeed Insights、Search Console 與 field/lab 讀法
入門用 PageSpeed Insights（PSI），輸入網址就能看，它會同時給你 field（來自 Chrome 真實使用者的 CrUX）與 lab（Lighthouse 模擬）兩份分數。站長等級則看 Search Console 的 Core Web Vitals 報告，它直接列出哪些網址群組不合格，最適合找全站問題的範圍。
| 項目 | field（CrUX 實測） | lab（Lighthouse 模擬） |
|---|---|---|
| 資料來源 | Chrome 真實使用者回報 | 固定環境模擬載入 |
| 優點 | 代表真實體驗，Google 用這份評分 | 環境可控，建議具體可重現 |
| 限制 | 需有足夠流量才會累積資料 | 跟真實使用者環境不同 |
| 什麼時候看 | 判斷瓶頸、看真實狀態 | 找具體解法、驗證修改 |
為什麼兩份對不上很正常？因為 field 是真實使用者，每個人的網路速度、裝置等級差異很大；lab 是固定環境模擬，數字本來就會不同。判斷瓶頸優先看 field（代表真實使用者），找具體解法再參考 lab（環境可控、建議具體）。分數紅燈但你看不懂是哪一項？那就先看是 LCP、INP 還是 CLS 在拖。
操作清單：先 PSI 看門檻，再 Search Console 看範圍
- 第一步：用 PSI 輸入網址，看三大指標是否落在良好門檻。
- 第二步：進 Search Console 的 Core Web Vitals 報告，看是全站性還是單頁問題。
- 第三步：用 Chrome DevTools 的 Performance 面板錄製，抓出真正的瓶頸。
- 第四步：進階可搭配 web.dev 工具、Web Vitals 擴充功能持續監控。
如果你的站是 WordPress，搭配 WordPress SEO 最佳化流程一起做會更有效率。要提醒的是，PSI 跟 網站速度檢測是入門，但它不會告訴你瓶頸在主機、主題還是第三方腳本，這要靠 DevTools 才看得出來。
實務上有個小陷阱要注意：CrUX 的 field 資料需要一定的流量門檻才會累積，新站或低流量頁可能根本沒有 field 分數，這時 PSI 只會給你 lab 那份。遇到這種情況別慌，lab 分數一樣能幫你抓瓶頸，只是它代表的是模擬環境、不是真實使用者。等流量起來，field 資料自然會出現，這也是為什麼衝流量與監測體驗是相輔相成的兩件事。對自然排名還在爬升的站來說，先把 lab 顧好、別讓紅燈卡住成長，是最務實的起步。
LCP 太慢怎麼辦：伺服器回應、圖片與阻斷資源的改善順序
LCP 慢，八成出在三個地方之一：伺服器回應太慢（TTFB 高）、LCP 元素是沒壓縮的大圖、或有阻斷渲染的 CSS/JS。改善順序是先壓伺服器回應時間，再把 LCP 圖片改成現代格式並預先載入，到頭來再清掉阻斷渲染的資源。先動影響最大的那一項，比分頭改一堆小東西有效。
第一步：降 TTFB，主機往往是真正瓶頸
第一步是降低 TTFB（第一個位元組時間）。換夠快的伺服器或主機、開頁面快取，是 CJK 站長最常忽略的一環。WordPress 的常見瓶頸其實在共享主機太弱，TTFB 動輒一兩秒起跳，這時候你怎麼壓圖片都沒用。老實說，很多站 LCP 紅燈根本不是圖片問題，是主機太弱，換主機比分秒必爭壓圖片有效。
第二步：LCP 圖片轉現代格式並預先載入
第二步是 LCP 圖片最佳化。把首圖或主要圖片轉成 WebP 或 AVIF、設正確尺寸、用 fetchpriority="high" 與 preload 提前下載。圖片相關的 圖片替代文字與 網站程式碼最佳化是兩條獨立但都該做的線，前者管 SEO 語意，後者管載入效能。
第三步：清掉阻斷渲染的資源
第三步是清掉阻斷渲染的 CSS 與 JS。延後非必要的樣式與腳本、拆分 critical CSS、改用 HTTP/2 或 HTTP/3 讓資源並行下載減少排隊。常見誤判是「以為裝了快取外掛就會快」，結果 TTFB 還是高，瓶頸其實在主機或 技術 SEO 層的資源載入順序。
LCP 元素不一定是圖片，有時是一段大字標題或區塊，這時改善重點會變成字型載入與關鍵 CSS 的內聯。重點是先用 PSI 或 DevTools 確認「你的 LCP 元素到底是哪一個」，再決定從哪裡下手，別盲目跟著教學壓圖片。
CDN 與 HTTP/2、HTTP/3 的價值在於讓資源並行下載、減少排隊，對圖片與字型多的內容站特別有感。不過 CDN 不是萬能，如果你的主機回應本身就慢，CDN 只是把那個慢的回應快取起來而已，源頭沒解等於沒解。這也呼應前面講的：先壓 TTFB，再做下游最佳化。把 網站最佳化流程當成一份檢查清單逐項過，會比一次想做完所有事更踏實。
一個常被忽略的細節：LCP 的計算會把「伺服器回應時間」算進去，所以 TTFB 高的站，LCP 幾乎不可能好。換句話說，你在 PSI 看到的 LCP 數字，其實有相當一部分反映的是主機與後端的健康度，而不是前端。這也是為什麼我們一再強調主機優先，它影響的是所有指標的地基，跟 技術 SEO 的真正價值是同一件事：它是能見度的地基，不是修一修就好的小毛病。
INP 太慢怎麼辦：主執行緒、第三方腳本與長任務的處理
INP 慢，通常是主執行緒被 JavaScript 卡住，最常見的兇手是過多的第三方腳本（廣告、追蹤、社群按鈕）與過長的任務（long task）。改善方向是減少主執行緒工作量：延後或條件載入非必要腳本、把長任務拆成小塊、用 requestIdleCallback 排程非緊急工作。要先在 DevTools Performance 面板抓出是哪段腳本在卡，而不是盲目砍外掛。
找出瓶頸：錄製互動，看主執行緒
用 Chrome DevTools 開 Performance 面板，錄製一次完整的互動（例如點選單、展開摺疊區塊），然後看主執行緒的長任務分布。紅色長條就是阻塞點，點進去能看到是哪個腳本造成的。這個動作比刪外掛精準太多，刪錯外掛還可能破壞 網站架構或功能。
第三方腳本管理與長任務拆分
第三方腳本的管理方向是：延後載入、條件觸發、用 tag manager 收斂，減少主執行緒競爭。廣告賺錢，但也在吃你的 INP 分數，這是現實的取捨。長任務則要拆成可中斷的小塊，避免一次佔住主執行緒幾百毫秒。這些方向來自 web.dev 官方建議，我們不寫死「降低 X ms」這類硬數字。
常見誤判是把所有外掛刪光以為會變快，結果破壞功能又沒解決真正阻塞的腳本。技術 SEO 的常見盲點之一就是「以為少即是快」，其實關鍵是阻塞主執行緒的那幾個腳本，不是外掛總數。行動裝置的 CPU 比你想的弱，INP 在手機上特別容易翻車，這也跟 行動裝置網站速度為什麼重要是同一件事。
拆分長任務的具體手法有幾種：把同步的大段工作用 setTimeout 或 scheduler.yield() 切成可中斷的小塊，讓瀏覽器有機會在區塊之間回應使用者的輸入；把非緊急的工作（例如埋點追蹤、非關鍵分析）排到 requestIdleCallback；對會反覆執行的互動邏輯做 debounce 或 throttle，避免連續觸發把主執行緒塞爆。這些都是前端工程的基本功，但對 INP 的改善往往比換外掛明顯，因為它們直接處理的是「點了為什麼沒反應」這個根本問題。
CLS 版面一直跳：圖片尺寸、字型與動態內容的修正方法
CLS 高，代表頁面在載入過程中元素非預期地位移，最常見三個原因：圖片與影片沒設寬高、網頁字型載入後把文字推擠、廣告或嵌入內容動態插入把下方內容擠開。修正方法是幫所有媒體預留固定尺寸、字型用 font-display: swap 並預載、動態內容先保留版位空間（web.dev CLS 官方文件）。
- 原因一：圖片與影片缺寬高屬性，瀏覽器無法預留空間，載入後撐開版面。
- 原因二：網頁字型載入後改變文字高度，用
font-display: swap加 preload 緩和。 - 原因三：廣告或嵌入內容動態插入，先在版面保留
min-height佔位。
現代解法是用 CSS aspect-ratio 一行解決多數媒體尺寸預留，不必再每張圖手填寬高。另一個容易忽略的點是：避免在既有內容上方插入新元素，例如通知列或廣告插入點，這種從上方推擠的位移對 CLS 殺傷最大。你有沒有遇過要點的按鈕在點下去前一秒被廣告擠走？那就是 CLS 在搞鬼。
CLS 在 點擊率與 轉換率上的影響是間接但真實的：使用者點不到按鈕、點錯位置，自然就離開了。把 CLS 修到 0.1 以內，等於是把「被廣告擠走」這種體驗地獄從你的頁面移除，這對電商與表單頁尤其關鍵。
廣告版位的處理是 CLS 修正裡最棘手的一段，因為廣告通常是非同步載入，而且尺寸不固定。實務上的做法是：在廣告插槽先用 CSS 預留一個 min-height，讓廣告載入時不會把下方內容往下推。如果是自適應廣告，可以依常見寬高比預留空間，再讓廣告填入。這些細節看起來瑣碎，但累積起來就是 CLS 紅燈與綠燈的差別，也直接影響停留時間與使用者對網站的信任。嵌入內容（影片、推文、地圖）也是同樣道理，給它一個固定比例的容器，載入時就不會把後面的內容擠得亂跳。
Core Web Vitals 最常見的 5 個錯誤：分數動不了的真正原因
改了圖片、裝了快取，CWV 分數還是不動，通常踩到下面這五個坑之一。分數卡住不代表沒救，多半是方向錯了。下面這張表把每個錯誤與第一個該做的修正動作列在一起，照著檢查比從頭摸索快。
| 常見錯誤 | 症狀 | 第一個修正動作 |
|---|---|---|
| 只信 lab 分數 | Lighthouse 滿分，field 還是紅燈 | 改看 field（CrUX）為準 |
| 瓶頸誤判 | LCP 紅燈就壓圖片，主機其實是兇手 | 先量 TTFB 再壓圖片 |
| 快取外掛衝突 | 裝了等於沒裝，關鍵資源被延後 | 驗證前端真的吃到快取 |
| 過度刪外掛 | 功能壞了，阻塞腳本還在 | 用 DevTools 找真正阻塞點 |
| 改錯指標 | 紅的是 INP 卻一直壓 LCP | 先確認紅燈是哪一項 |
第一個錯誤最普遍：只看 lab 分數，忽略 field 才是 Google 用來評分的真實資料。第二個是瓶頸誤判，看到 LCP 紅燈就壓圖片，其實是主機 TTFB 太高。第三個是快取外掛衝突或設定不當，裝了等於沒裝，甚至延後了關鍵資源，這也是 WordPress SEO 站長最常踩的雷。
第四個是過度刪外掛，破壞功能又沒解決真正阻塞主執行緒的腳本。第五個是改錯指標，三大指標紅的是 INP 卻一直壓 LCP，當然分數不動。我自己也踩過「快取外掛裝好就沒理它」的坑，後來才學會用 DevTools 的 Network 面板驗證前端真的吃到快取回應。要懂 SEO 排名因素全貌，這些細節都是基礎。
這五個錯誤有一個共同根源：把 CWV 當成獨立的技術競賽，而不是體驗與內容的一環。分數卡住時，最該做的不是換更強的外掛或更激進的設定，而是退一步問三個問題：我的 field 與 lab 哪一份顯示紅燈、紅的是哪一項指標、這一項最可能的瓶頸在哪一層（主機、主題、第三方腳本、還是圖片）。把這三個問題答清楚，八成的卡關都能就地解掉，不必把整個網站翻掉重來。
還有一種隱形的錯誤：改了 CWV 之後沒有回去驗證。很多人改完圖片、裝完快取，就假設分數一定會好，結果過了兩週才發現 field 還是紅的，因為改錯了地方或改完根本沒生效。正確的做法是改完每一項之後，等七到二十八天的 CrUX 更新週期，再用 Search Console 回頭看那一群網址的狀態有沒有從紅轉黃、從黃轉綠。沒有驗證的改善，跟沒改善沒兩樣，這個紀律比任何外掛都重要。
WordPress 站長的 CWV 改善優先順序：主機、主題、外掛一條龍
對使用 WordPress 的台灣站長來說，CWV 的改善有一條相對固定的優先順序，照著走比無頭蒼蠅式亂改有效得多。順序是：先換夠快的主機把 TTFB 壓下來，再處理 LCP 的首圖，接著修 CLS 的版面位移，到頭來才收尾 INP。這個順序的邏輯是「先解影響面最大的、再解技術門檻最高的」，與 SEO 入門實戰裡強調的「先打地基再蓋樓」是同一個道理。
主機與快取：先解 TTFB
很多台灣站長卡在共享主機，TTFB 動輒超過一秒，這時候做什麼 LCP 最佳化都事倍功半。LiteSpeed Cache、Cloudflare 這類工具能幫上忙，但前提是主機本身要夠快。頁面快取要確認前端真的吃到靜態回應，而不是每次都打到 PHP；物件快取（如 Redis）對動態查詢多的站效果明顯。主機挑選可以參考 WordPress SEO 流程，把速度與技術 SEO 一起看。
佈景主題與外掛：別讓它們成為 INP 殺手
佈景主題載入越多前端資源（字型、圖示、動畫），越容易拖垮 INP 與 LCP。挑主題時優先選輕量、少內建頁面產生器（page builder）的版本；已經在用的主題，可以關掉用不到的模組。外掛也是同樣道理，程式碼層 SEO 常見的問題就是外掛載入了一堆只在某頁用到的 JS。行動裝置特別敏感，這跟 行動優先索引與 手機版排名是同一條線，手機上的 INP 往往比桌機差一大截。
圖片與字型：LCP 與 CLS 的共同戰場
圖片用 WebP/AVIF、設寬高或 aspect-ratio、首圖加 fetchpriority="high"，這些動作同時顧到 LCP（快）與 CLS（穩）。字型則用 font-display: swap 搭配 preload，避免載入後把文字推擠。延遲載入（lazy loading）對首圖以外的圖片有效，但首圖千萬別 lazy，否則反而拖慢 LCP。圖片替代文字寫得好，對 結構化資料與圖片搜尋也是加分，但那是另一條獨立但平行的線，別跟效能最佳化混在一起改。
第三方腳本（廣告、分析、社群按鈕）是 WordPress 站 INP 紅燈的最大宗原因。用 Google Tag Manager 收斂、延後載入非必要腳本、對廣告預留固定版位，這三招下來通常就能把 INP 拉進良好區間。改完之後記得用轉換率與 自然排名的數字回頭驗證，確認體驗改善真的帶來了正向的流量回饋。
2026 年 AI 搜尋時代，Core Web Vitals 還值得做嗎
值得，但理由變了。CWV 在 2026 年的價值不在「直接推升排名」，而在三件事：跨過「良好」門檻拿體驗分（別在同分時輸掉）、用更快的載入與更穩的版面提升留存與轉換、讓頁面更容易被 AI 搜尋引擎乾淨地抓取與引用。把目標從「追求滿分」改成「先過門檻、穩定可被索引」，ROI 才會合理。
CWV 在 GEO 時代的角色：可抓取性與可讀性
講白一點，頁面體驗影響的是「被 AI 引用前的可抓取性與可讀性」，不是直接排名權重。AI 引擎偏好能快速、乾淨解析的頁面：版面穩（CLS 低）、互動不卡（INP 好），有助於擷取正確內容。這個觀點是目前中文 SERP 最缺的視角，把 CWV 從「排名工具」重新定位成「可被引用的前置條件」。
ChatGPT、Perplexity、Google AI Overview 這些引擎在解析你的頁面時，跟一般爬蟲一樣需要乾淨的 HTML 與穩定的版面。CWV 顧好，等於是給它們一張乾淨的地圖。要懂 GEO（生成式引擎最佳化） 與 AI SEO 的完整策略，這條線是必經之路。
別走極端：過門檻後把主力放回內容
別走極端。不能因為「只是 tie-breaker」就放任紅燈，也不能為了滿分把資源全砸在速度上。過門檻後，把主力放回 內容深度與 連結，才是 2026 排名與 AI 引用的主力。CWV 與 AI 引用率的確切相關程度目前沒有公開研究，這裡講的是方向而非保證。
想搶 Google 第一名或被 生成式搜尋引用，內容與 E-E-A-T 才是主戰場。CWV 是地基，地基穩了，上面的內容才有機會被看見、被引用。這也是為什麼我們一直強調「先過門檻」而不是「追求滿分」，兩者的 ROI 差很多。
把視野拉大一點，2026 年的搜尋版圖正在重組，SEO 趨勢從單純拼排名，轉向「能不能被 AI 引用、能不能留住使用者」。CWV 在這個新版圖裡的位置很清楚：它是讓你的頁面「可被乾淨讀取」的前置條件，而不是排名魔法。對 E-E-A-T 與 權威信任的投資，才是真正決定你能不能被引用與被信任的主力。
還有一點要誠實說：CWV 與 AI 引用率之間，目前沒有公開的因果研究，我們講的是方向性觀察，不是保證。但從工程直覺來看，一個版面會跳、點了沒反應的頁面，對爬蟲與 AI 解析器都不友善，這是合理的推論。與其爭論 CWV 在 2026 年還重不重要，不如把它當成「讓內容被正確讀取」的基本功，做完就收手，把心力花在 內容與 連結上，長期報酬會高得多。
FAQ：關於 Core Web Vitals 最常被問的 7 個問題
Q1：Core Web Vitals 是什麼？
Core Web Vitals 是 Google 用來衡量網頁真實使用者體驗的一組指標，目前穩定版本包含 LCP（載入）、INP（互動）、CLS（視覺穩定）三項，資料來自 Chrome 真實使用者的 CrUX 回報。
Q2：Core Web Vitals 會影響 Google 排名嗎？
會，但只是 tie-breaker。Google 把頁面體驗定位為同分時的決勝條件，不是主要排名因素。先把三大指標拉過良好門檻最要緊，過了門檻再壓數字邊際效益低。想搞懂完整的排名因素脈絡，可以看 SEO 排名因素解析與 SEO 排名因素週期表，CWV 只是其中一塊。
Q3：要用什麼工具測 Core Web Vitals？
入門用 PageSpeed Insights，輸入網址就能同時看到 field 與 lab 兩份分數；站長等級則看 Search Console 的 Core Web Vitals 報告，它直接列出不合格的網址群組。
Q4：LCP、INP、CLS 的門檻是多少？
LCP 良好門檻為 2.5 秒、INP 為 200ms、CLS 為 0.1，這三個數字都有 web.dev 官方來源。三項都跨過良好門檻，就拿到 Core Web Vitals 體驗分數。
Q5：LCP 太慢先改什麼？
先看伺服器回應時間（TTFB），再改 LCP 圖片（轉 WebP/AVIF、設尺寸、preload），再清掉阻斷渲染的 CSS/JS。先動影響最大的那一項最有效。
Q6：INP 跟 FID 一樣嗎？
不一樣。INP 已於 2024 年 3 月正式取代 FID，FID 只測首次輸入延遲，INP 測整個頁面所有互動中最慢那次，標準更嚴格。舊的最佳化 FID 建議要更新成 INP 思維。
Q7：三大指標都過門檻了還要繼續改嗎？
邊際效益低，建議把主力放回內容與連結。CWV 過了門檻之後，再繼續壓數字對排名的邊際加成很小，真正能拉開差距的是內容深度與 E-E-A-T。與其把 LCP 從 2 秒壓到 1 秒，不如回去補站內 SEO、內部連結策略，或經營 反向連結，長期 ROI 高得多。
回顧一下，Core Web Vitals 不是萬靈丹，也不是可忽略的裝飾品。把 LCP、INP、CLS 三項做到「良好」門檻，拿到體驗分、別在同分時輸掉，再把主力放回內容與連結，這是 2026 年最合理的 CWV 投資策略。從觀念到實戰的完整脈絡，可以接著讀頁面體驗訊號解析與 年度 SEO 最佳化指南。如果你已經在 Search Console 看到紅燈，別急著灌一堆外掛，先打開 PageSpeed Insights 確認是哪一項在拖，再按這篇的優先順序動手，七到二十八天後回來看 field 分數的變化，才是最務實的做法。
