Core Web Vitals 是什麼？LCP、INP、CLS 指標與改善流程

Core Web Vitals 是什麼？

Core Web Vitals 是 Google 用來衡量網頁真實使用者體驗的一組核心指標，重點看載入速度、互動反應與版面穩定性。

對網站經營者來說，Core Web Vitals 不是單純的技術分數，而是使用者進入網頁後是否能順利閱讀、點擊、完成任務的基本體驗檢查。Google 也把它放在 Page Experience 相關訊號之中，作為搜尋品質判斷的一部分，但它不是唯一排名因素。

Google 為什麼用這組指標評估網頁體驗

Google 搜尋希望使用者不只找到相關內容，也能順利使用該網頁。若頁面內容很完整，但開啟太慢、按鈕點了沒反應、閱讀時版面一直跳動，對使用者仍然是不好的搜尋結果體驗。

Kevin Lin 的實務判斷是：Core Web Vitals 最有價值的地方，不在於追求滿分，而在於把「網站很卡」這種模糊感受，拆成可以討論、可以修復、可以驗證的具體問題。

三個核心面向：載入、互動、穩定

2026 年 Core Web Vitals 三大指標：LCP、INP、CLS

2026 年 Core Web Vitals 的核心指標是 LCP、INP、CLS，分別衡量主要內容載入、互動回應速度與視覺穩定性。

這三項指標剛好對應一個使用者打開網頁後最常遇到的三種阻力：等太久、點了沒反應、畫面亂跳。SEO PM 和工程師討論效能時，最好先用這三個問題對齊，而不是一開始就陷入工具分數。

LCP 是什麼

LCP 衡量使用者開啟網頁後，視窗內最大的主要內容元素多久完成顯示。這個元素常見是首屏主圖、文章標題區、產品圖片或大段文字。

LCP 差的網站，使用者通常會覺得「網頁一直白白的」或「內容很慢才出現」。對 SEO 文章、電商商品頁、服務頁來說，LCP 常是第一個該看的效能指標。

INP 是什麼

INP 衡量使用者在頁面上互動後，到下一次畫面更新之間的反應時間。互動包含點擊按鈕、打字、展開選單、切換篩選條件等。

INP 是 2026 年最容易被低估的指標。很多網站載入速度看起來可以，但一點選單、表單或購物車就卡住，真正流失使用者的往往是這裡。

CLS 是什麼

CLS 衡量頁面載入過程中，內容是否發生非預期位移。分數越高，代表版面越不穩定，使用者越可能點錯或閱讀中斷。

最典型的 CLS 問題，是使用者準備點某個按鈕時，廣告或圖片突然載入，把按鈕推到別的位置。這種體驗會直接破壞信任感。

使用者實際感受

Core Web Vitals 合格標準是多少？

Core Web Vitals 合格標準是 LCP 2.5 秒內、INP 200ms 以下、CLS 0.1 以下，且通常以第 75 百分位的真實使用者資料判斷。

Google 官方標準把每個指標分成 Good、Needs Improvement、Poor 三個區間。實務上，不要只看單次測試結果，要看真實使用者在手機與桌機上的整體分布。

良好、需要改善、不良的分數區間

為什麼要看第 75 百分位

第 75 百分位代表至少 75% 的使用者體驗要落在該數值以內。這比平均值更適合判斷真實體驗，因為平均值可能被少數極快或極慢的樣本扭曲。

舉例來說，如果某頁 LCP p75 是 3.2 秒，代表有 75% 的載入樣本在 3.2 秒內完成最大內容繪製。這頁沒有達到 2.5 秒的良好門檻，即使你自己在辦公室網路測起來很快，也不能直接判定已通過。

FID 為什麼被 INP 取代？Core Web Vitals 如何演進

FID 被 INP 取代，是因為 FID 只看第一次互動延遲，INP 更能反映使用者整段瀏覽期間的互動反應品質。

2024 年 3 月後，INP 正式成為 Core Web Vitals 的核心互動指標。2026 年做網站效能或 SEO 健檢時，FID 只適合作為歷史背景，不該再當成主要優化目標。

從速度排名到 Page Experience

Google 很早就把速度與行動裝置體驗納入搜尋品質脈絡。後來 Core Web Vitals 被整合進 Page Experience 相關訊號，讓網站主能用更具體的方式檢查使用者體驗。

這裡要拿捏分寸：Core Web Vitals 和 Google 排名因素有關，但不等於只要通過三項指標就能排名上升。內容品質、搜尋意圖、網站權威與內部連結仍然重要。

FID 的限制

FID 只測量使用者第一次互動時，瀏覽器能不能開始處理事件。它沒有完整反映後續互動，也沒有涵蓋處理事件後畫面更新的等待時間。

這造成一個問題：有些網站第一次點擊看起來合格，但之後展開選單、切換篩選、輸入表單仍然卡。FID 會低估這類體驗問題。

INP 更接近真實互動體驗

INP 觀察頁面生命週期中的互動反應，並用較能代表糟糕體驗的互動延遲來評估。它比 FID 更接近使用者口中的「這個網站很卡」。

Core Web Vitals 為什麼重要？不只是 SEO 分數

Core Web Vitals 重要，因為它同時影響搜尋體驗、使用者信任、轉換流程與網站維護優先順序，不只是 PageSpeed 分數。

對台灣多數網站來說，CWV 最大的價值是幫你判斷「哪一類頁面正在拖累使用者體驗」。若商品頁、預約頁、報名頁或高流量文章頁體驗差，損失通常不只發生在 SEO。

對搜尋排名的影響

Google Search Central 對 Core Web Vitals 與搜尋結果的說法，是它衡量真實使用者在載入、互動、視覺穩定上的體驗，並與其他 Page Experience 面向一起符合核心排名系統想獎勵的方向。

實務判斷上，CWV 比較像競爭接近時的體驗門檻。若內容與權威落差很大，只靠 CWV 很難翻盤；但在內容品質接近時，較好的網頁體驗會降低被使用者放棄的風險。

對跳出率、轉換率、信任感的影響

載入慢會讓使用者離開，互動慢會讓人懷疑表單或購物車失效，版面跳動會讓人覺得網站不穩定。這些行為會反映在 跳出率、停留時間、轉換流程與品牌信任上。

特別是需要表單送出、付款、預約、加入會員的頁面，INP 和 CLS 往往比單純的速度分數更接近商業損失。

不同網站類型的風險

如何測量 Core Web Vitals？工具與資料來源怎麼選

測量 Core Web Vitals 要同時看 PageSpeed Insights、Search Console、Lighthouse 與 CrUX，因為每個工具的資料來源與用途不同。

如果只看單一工具，很容易做出錯誤判斷。Search Console 適合看整體 URL group 狀態，PageSpeed Insights 適合快速診斷單頁，Lighthouse 適合工程測試，CrUX 則是真實使用者資料來源。

PageSpeed Insights

PageSpeed Insights 適合快速檢查單一網址。它通常會同時呈現真實使用者資料與實驗室模擬結果，並提供可執行的改善建議。

使用時要先分清楚上方的 Field Data 與下方的 Lab Data。很多人看到 Lighthouse 分數很高，就以為真實使用者一定通過，這是常見誤判。

Search Console Core Web Vitals report

Search Console 的 Core Web Vitals report 適合看網站整體狀態。它會依手機版、桌機版、狀態、指標與 URL group 顯示問題。

SEO PM 排任務時，Search Console 比單頁測速更有用，因為它能看出哪些模板或頁型一起出問題，而不是只盯著首頁。

Lighthouse

Lighthouse 是實驗室測試工具，適合工程師在固定條件下重複測試。它可以用來比較修復前後的變化，也能指出阻塞資源、圖片、JavaScript 等技術問題。

但 Lighthouse 不是真實使用者資料。它的分數會受測試環境、網路條件、裝置模擬設定影響，不能直接等同於 Search Console 狀態。

CrUX

CrUX 是 Chrome User Experience Report，提供真實 Chrome 使用者的體驗資料。Search Console 與 PageSpeed Insights 中的現場資料，許多判讀都與 CrUX 脈絡有關。

CrUX 的強項是反映真實使用情境，限制是資料需要足夠樣本。小型網站或低流量頁面，可能會看不到完整資料。

Field Data 和 Lab Data 差在哪？為什麼兩份報告結果不同

Field Data 是真實使用者資料，Lab Data 是模擬環境測試資料；兩者用途不同，所以 PageSpeed Insights、Lighthouse、Search Console 結果可能不同。

這是 Core Web Vitals 最容易造成團隊爭論的地方。SEO 端看 Search Console 說不合格，工程端跑 Lighthouse 卻看到綠燈，雙方其實可能都沒錯，只是看的資料層級不同。

Field data 是真實使用者資料

Field Data 來自真實使用者在不同裝置、網路、地區、瀏覽情境下的體驗。它更接近 Google 判斷 Core Web Vitals 狀態時要看的世界。

Field Data 的缺點是更新較慢，也需要足夠樣本。剛修完網站後，Search Console 不會立刻變好，因為它需要累積新的真實使用者資料。

Lab data 是模擬測試

Lab Data 是在固定測試環境中模擬載入與互動，用來找問題與驗證修復方向。Lighthouse 就屬於這一類。

Lab Data 的好處是可以重複測，工程師能用它確認 CSS、JavaScript、圖片、字型等改動是否有效。限制是它無法完整代表真實使用者的網路與裝置差異。

SEO 判斷應優先看哪個

SEO 狀態判斷優先看 Field Data，工程除錯優先用 Lab Data。這個規則可以避免團隊把工具分數當成唯一真相。

Core Web Vitals 不佳時，應該先修什麼？

Core Web Vitals 不佳時，優先修手機版、高流量頁、同模板頁、轉換頁，以及最嚴重的不良指標。

不要看到紅字就全站亂修。我的判斷是，CWV 優化最怕把工程資源花在低流量、低價值、難以驗證的頁面。先找出會影響最多使用者與最多營收的頁型，才是有效排序。

先看手機還是桌機

通常先看手機版。台灣多數消費型網站、內容網站與電商網站的手機流量占比高，手機裝置效能與網路條件也更容易暴露 LCP、INP、CLS 問題。

桌機也不能忽略，尤其是 B2B、SaaS、後台工具或企業採購型網站。但若手機版已經大量不良，通常應先處理手機。

先修流量頁、模板頁或轉換頁

優先順序建議是：高流量頁、共用模板頁、轉換頁，再來才是單一低流量頁。Search Console 的 URL group 可以幫你判斷問題是否來自同一種頁型。

如果 300 篇文章頁因為同一個首屏廣告造成 CLS，不該只修某一篇文章。應該修模板，讓整組 URL 受益。

先修 LCP、INP 還是 CLS

先修哪個指標，取決於嚴重度、頁型與使用者任務。內容頁通常先看 LCP 與 CLS，互動型頁面、電商頁、表單頁則要把 INP 提到前面。

如何改善 LCP？

改善 LCP 要先讓首屏主要內容更快出現，常見做法是壓縮圖片、改善伺服器回應、減少阻塞資源，並優先載入關鍵內容。

LCP 問題通常不只是一個「圖片太大」。它可能同時牽涉伺服器、模板、CSS、JavaScript、字型與首屏內容設計。最有效的做法，是先確認 LCP 元素是什麼，再處理造成它延遲的原因。

壓縮與正確尺寸圖片

如果 LCP 元素是首屏主圖或商品圖，圖片最佳化通常是第一優先。應使用正確尺寸、現代圖片格式、合理壓縮，並避免把桌機大圖直接丟給手機版。

圖片相關做法可延伸參考 圖片 SEO 最佳化，但在 CWV 脈絡下，重點不是只加 alt，而是讓主要圖片更快、更穩地出現。

改善伺服器回應

伺服器回應慢會拖延所有後續載入。若 TTFB 過長，前端再怎麼壓圖片，也可能無法讓 LCP 進入良好區間。

常見處理方向包含快取、資料庫查詢最佳化、減少後端阻塞、檢查過重外掛或模組。這部分屬於 技術 SEO 與網站架構維護的交界。

減少 render-blocking resources

阻塞渲染的 CSS、JavaScript 會讓瀏覽器延後顯示主要內容。工程師應檢查首屏必要資源，移除不必要的同步載入，並延後非關鍵 script。

常見問題包括全站共用 CSS 過大、第三方追蹤碼太早載入、首頁動畫套件阻塞主要內容。這些問題在視覺華麗的網站很常見。

優先載入主要內容

如果瀏覽器太晚發現 LCP 圖片或關鍵字型，可以用 preload、fetchpriority、適當的資源提示改善載入順序。

如何改善 INP？

改善 INP 要降低互動後的延遲，核心方向是減少 JavaScript 執行時間、拆分長任務、控管第三方 script，並釋放主執行緒。

INP 是最能暴露前端負擔的指標。很多網站把追蹤碼、聊天工具、廣告、彈窗、動畫與框架邏輯全部塞進頁面，最後使用者每點一下都要等瀏覽器忙完。

減少 JavaScript 執行時間

JavaScript 越重，主執行緒越容易被占滿。工程師應檢查 bundle 大小、未使用程式碼、重複套件、過早執行的功能。

對內容頁來說，許多互動功能其實不需要在首屏立即啟動。延後載入非必要 script，常能改善 INP 與 LCP。

拆分長任務

長任務會讓瀏覽器無法及時回應使用者互動。若一次執行太多計算、渲染或資料處理，使用者點擊後就會感覺卡住。

修復方向包含把大型工作拆成較小任務、使用非同步處理、減少同步阻塞，並避免在互動當下做不必要的重計算。

檢查第三方 script

第三方 script 是 INP 問題常見來源。廣告、分析、熱圖、客服聊天、A/B 測試工具都可能增加主執行緒負擔。

我的建議是每季盤點一次第三方 script。很多網站效能變差，不是因為主要程式變爛，而是多年累積了太多沒人敢刪的追蹤碼。

改善主執行緒負擔

主執行緒負責處理使用者互動、執行 JavaScript、計算樣式與更新畫面。它太忙，INP 就會變差。

• 檢查是否有超過 50ms 的 long task。
• 刪除或延後非必要 JavaScript。
• 避免互動時同步載入大量資料。
• 減少大型 DOM 更新與重複渲染。
• 確認第三方 script 是否真的有商業必要。
• 在表單、選單、購物車、篩選器等關鍵互動上優先測試。

如何改善 CLS？

改善 CLS 要避免內容在載入後突然位移，重點是替圖片、iframe、廣告、嵌入內容與字型保留穩定空間。

CLS 通常不是速度問題，而是版面承諾問題。使用者看到某個位置，就會預期它不會突然移動；網站打破這個預期，信任感會立刻下降。

圖片與 iframe 保留尺寸

圖片、影片、iframe 若沒有明確寬高或 aspect-ratio，瀏覽器在資源載入前無法預留空間，內容載入後就會把下方版面推開。

修復方式是替媒體元素設定 width、height 或 CSS aspect-ratio，讓瀏覽器在載入前就知道該保留多少空間。

廣告與嵌入內容預留空間

廣告、社群貼文、地圖、影片嵌入都可能晚於主要內容載入。如果沒有預留容器高度，版面位移會很明顯。

內容站與新聞站尤其要注意。廣告收益重要，但若廣告造成大量 CLS，使用者閱讀與搜尋表現都會受到影響。

避免動態插入內容推動版面

彈窗、推薦模組、會員提示、App 下載橫幅若突然插入在內容上方，很容易造成版面位移。

比較好的做法是讓新增內容出現在既有容器內，或從不影響文件流的位置顯示，避免把正在閱讀或準備點擊的內容往下推。

字型載入策略

Web font 載入也可能造成文字閃爍或位移。若備用字型與正式字型尺寸差很多，文字替換時就會推動版面。

網站經營者如何把 Core Web Vitals 變成可執行任務

網站經營者要把 Core Web Vitals 變成任務，應先由 SEO 判讀問題頁型，再由工程修復指標，最後由主管決定預算與優先順序。

Core Web Vitals 優化失敗，常不是技術不會修，而是沒有人把分數翻譯成任務。網站主問「為什麼 Search Console 紅了」，工程師回「Lighthouse 本機正常」，中間缺少任務拆解者。

SEO 團隊負責判讀與排序

SEO 團隊應負責判讀 Search Console、PageSpeed Insights 與 URL group，確認哪些頁型、裝置、指標正在出問題。

排序時要看流量、商業價值、模板影響範圍與嚴重度。也要檢查 內部連結策略，避免高價值頁面同時被效能與站內權重配置拖累。

工程團隊負責修復與驗證

工程團隊應負責定位技術原因、提出修復方案、在測試環境驗證，再部署到正式站。修復後先用 Lab Data 確認方向，再等 Field Data 累積。

若涉及安全、HTTPS、資源載入或第三方服務，也要同步檢查 HTTPS 與 SSL 設定，避免效能修復牽動其他技術問題。

主管負責頁型與預算決策

主管不需要逐行看程式碼，但要決定哪些頁型值得先修、哪些功能可以延後、哪些第三方工具需要保留或移除。

Core Web Vitals 常見誤解

Core Web Vitals 常見誤解包含把 Lighthouse 100 當成 Search Console 通過、只看桌機、只修首頁，以及把 CWV 當成唯一排名因素。

這些誤解會讓團隊浪費時間。更好的做法是把每個誤解轉成具體檢查：看哪個資料來源、哪個裝置、哪個 URL group、哪個指標、哪個頁型。

Lighthouse 100 不等於 Search Console 通過

Lighthouse 是 Lab Data，Search Console 主要呈現 Field Data。單次模擬測試滿分，不代表真實使用者在 28 天資料中都達到良好體驗。

桌機通過不代表手機通過

手機與桌機會分開判斷。手機裝置效能、網路、版面與互動方式不同，很多網站桌機綠燈，但手機仍然不良。

首頁通過不代表全站通過

首頁只是其中一個 URL。文章頁、分類頁、商品頁、搜尋結果頁、結帳頁可能使用不同模板，Core Web Vitals 狀態也可能完全不同。

CWV 不是唯一排名因素

Core Web Vitals 是 Page Experience 相關訊號之一，不是排名保證。內容是否滿足搜尋意圖、品牌信任、外部提及、搜尋點擊率與整體網站品質仍然需要一起看。