網站使用體驗核心指標（CWV）：LCP、FID、CLS、INP 白話文介紹 | 白話文商學院
Core Web Vitals（CWV，網站使用體驗核心指標）不是一個總分，而是 Google 從載入速度、視覺穩定性、互動回應三個獨立維度量化真實使用者體驗的指標組合。2024…
Core Web Vitals（CWV，網站使用體驗核心指標）不是一個總分，而是 Google 從載入速度、視覺穩定性、互動回應三個獨立維度量化真實使用者體驗的指標組合。2024 年 3 月 INP 正式接手 FID 之後，真正要盯的只剩 LCP（良好 2.5 秒以下）、CLS（0.1 以下）、INP（200 毫秒以下）三項，而且 Google 看的是真實裝置上的實測數據，不是跑一次 PageSpeed 的模擬分數 [來源：web.dev〈Core Web Vitals〉〈https://web.dev/articles/vitals〉〈2026〉]。 想把這三項指標從觀念一路拉到實作的人，可以延伸看Core Web Vitals 的 SEO 完全攻略。
重點先看：CWV 是三個維度而非一個分數，2024 年 3 月後只看 LCP、CLS、INP 三項；Google 公開案例顯示達標網站放棄載入率降低約 24%（根據 Google Search Central 說明）。
Core Web Vitals 是什麼：三個體驗維度與四個歷史指標
Core Web Vitals 衡量的核心是「使用者感覺多順」，單純的「網站多快」反而不是重點。Google 把使用者體驗拆成三個彼此獨立的維度：畫面載入多快、畫面穩不穩、點了會不會卡。目前穩定的核心指標是 LCP、CLS、INP 三項，FID 已在 2024 年 3 月退役 [來源：web.dev〈Core Web Vitals〉〈https://web.dev/articles/vitals〉〈2026〉]。 常見的誤解是把 CWV 當成 PageSpeed 跑出來的那個百分位分數，但 Google 排名參考的是真實使用者在各種裝置、各種網路環境下累積出來的實測數據（field data / RUM），實驗室模擬只是輔助診斷。
這裡要先建立一個關鍵框架：三個體驗維度 × 四個歷史指標。很多人把 LCP、CLS、FID、INP 四項並列，誤以為四項都得顧。這種講法其實是過時資訊的殘留。FID 在 2024 年 3 月 12 日被拔除後已不是穩定指標，並列只會誤導方向。正確的切入點是先把三個維度講清楚，再把指標對應回去，最後說明 INP 為什麼比 FID 更能反映互動品質。想系統化搞懂 SEO 全貌的人，可以先看SEO 是什麼入門自學懶人包，把 CWV 放進整體架構裡理解。
- 載入維度：使用者等多久才看到主要畫面，對應 LCP。
- 視覺穩定維度：畫面會不會亂跳，對應 CLS。
- 互動維度：點下去多久有回應，現行對應 INP（舊為 FID）。
CWV 的技術細節很深，但對經營網站的人來說，真正需要的關鍵是看懂報表、把問題準確描述給工程師或外包廠商，會不會改程式碼反而是次要。Google 的演進脈絡也值得知道：2010 年代大家盯的是 Speed Index、TTFB，後來聚焦到 LCP、CLS、FID，2024 年再由 INP 接手互動維度。指標會變，但量化真實使用者體驗這個核心邏輯沒變。而這些體驗數據又跟網頁速度是什麼與如何優化直接相關，速度只是 CWV 三個維度裡的載入那一塊。
維度之外，還要把 CWV 放進 Google 的頁面體驗（Page Experience）框架一起看。除了 CWV，Google 還會看行動裝置友善度、安全性、是否使用 HTTPS 與網站安全性介紹。這幾項合起來才構成完整的頁面體驗排名因素，CWV 是其中一環，不是全部。把 CWV 跟SEO 友善的網站架構、內部連結與網站架構優化一起規劃，才不會顧此失彼。想從零規劃網頁結構的人，可以延伸看SEO 友善的網站架構圖規劃全攻略。
頁面體驗這個框架的形成有明確的時間軸。2018 年 1 月 Google 預告「Speed Update」，當年 7 月正式把網頁速度列為行動搜尋的排名因素，不過作用範圍限定在「對使用者交付最慢體驗」的頁面，且只影響少數查詢 [來源：Google Search Central Blog〈Using page speed in mobile search〉 https://developers.google.com/search/blog/2018/01/using-page-speed-in-mobile-search 2018]。2020 年 5 月 Google 再預告一個結合 CWV 與既有訊號的全新頁面體驗排名訊號，把行動裝置友善度、HTTPS、侵入式插頁廣告一併打包進來 [來源：Google Search Central Blog〈Evaluating page experience〉 https://developers.google.com/search/blog/2020/05/evaluating-page-experience 2020]，並於 2021 年 5 月正式上線 [來源：Google Search Central Blog〈Timing for bringing page experience to Google Search〉 https://developers.google.com/search/blog/2020/11/timing-for-page-experience 2020]。也就是說，CWV 從一個工程圈關心的指標，在這幾年逐步變成正式的排名訊號，這也是它今天值得認真對待的根本原因。
這條時間軸也解釋了一個常見疑問：為什麼 2018 年的「速度排名因素」後來看起來沒那麼有感？因為當年那次更新刻意把範圍縮到最慢的一小撮頁面，多數網站根本碰不到。真正把頁面體驗訊號全面化的，是 2021 年那波結合 CWV 的更新。理解這段演進，才不會誤把舊資訊當現況，也能解釋為什麼有些網站速度明明普通、排名卻沒受影響。
CWV 為何影響 SEO：排名因素、業務數據與平手破局
Core Web Vitals 確實會影響排名，但它的定位是「平手破局因素」，不是主排名因素。意思是當兩個網站內容品質接近時，體驗較好的那邊才會勝出。如果內容本身輸一大截，CWV 滿分也救不回來 [來源：Google Search Central〈Understanding Core Web Vitals〉〈https://developers.google.com/search/docs/appearance/page-experience〉〈2026〉]。 Google Search Advocate John Mueller 在「Core Web Vitals and SEO」分享中講得很白：提供優質內容始終是最重要的排名要素，CWV 是在內容打平之後才上場的區分條件。所謂優質內容，背後對應的是站內 SEO 從內容到技術的優化，而不是靠走捷徑的黑帽 SEO 手法硬衝排名。
排名之外，CWV 直接牽動使用者行為與商業結果，這部分有 Google 公開案例當證據。把效能當生意做的人，會更願意投資這三項指標。幾個常被引用的數字：
- 達到 CWV 門檻的網站，使用者放棄載入頁面的機率降低約 24%（根據 Google Search Central 公開案例）。
- LCP 每縮短 100 毫秒，電商 Farfetch 的轉換率提升約 1.3%（web.dev 公開案例）。
- CLS 降低 0.2，Yahoo!Japan 單次工作階段網頁瀏覽量提升約 15%、跳出率下降約 1.72%（web.dev 公開案例）。
這三個數字背後是同一件事：CWV 不只交給 SEO，它直接牽動放棄率、轉換率、跳出率這些會進到報表的指標。而 LCP 100 毫秒的差距就能搬動轉換率，意味著優化值得做，卻也意味著不必把力氣花在衝滿分。把三項推到良好（綠色）門檻，邊際效益就夠看了，剩下的時間投回E-E-A-T 內容品質原則或資訊增益與內容差異化更划算。想把跳出率這個指標本身看清楚，可以先讀網站跳出率與 SEO 的關係解析。
把案例再往下挖一層，會發現 CWV 跟營收的連動比想像中直接。日本電商 Rakuten 24 投入 CWV 優化後，每位訪客營收提升 53.37%、轉換率提升 33.13% [來源：web.dev (Google)〈Why does speed matter?〉 https://web.dev/articles/why-speed-matters 2026]；印度財經媒體 The Economic Times 通過 CWV 門檻後，整體跳出率改善 43% [來源：web.dev (Google)〈Why does speed matter?〉 https://web.dev/articles/why-speed-matters 2026]。一個是轉換率、一個是跳出率，分別代表 CWV 對電商與媒體兩種截然不同業種的拉抬效果。把這幾個數字跟前面 24% 的放棄率降低擺在一起，這條因果鏈會直接進到財報，體驗差距最終會換算成營收數字。
換個角度想，CWV 跟排名的關係有點像考試的最低門檻。過了門檻不保證高分，但沒過門檻幾乎一定被扣分。所以兩個動作要拆開：一是把 CWV 顧到綠色門檻（基礎建設），二是把內容做到比對手更有差異化（主排名要素）。兩者不能互相替代。把 CWV 當萬靈丹、或完全不理它，都是資源錯置。這也是為什麼很多人做完搜尋意圖與高排名核心關鍵的功課後，才回頭補 CWV。如果卡住的其實是排名本身而非體驗問題，可以對照Google 排名一直上不去的關鍵原因逐一排查。
「平手破局」這個定位還有個實務上的推論：CWV 的影響力跟你的競爭環境有關。在一個大家內容都很紮實的成熟市場（例如旅遊、電商比價），體驗差距往往就是排名差距，這時 CWV 的權重會被放大；反之在內容品質落差很大的長尾領域，CWV 的邊際效果就稀釋了。所以判斷要不要砸資源優化 CWV，先看你的對手內容做到什麼程度，再決定把體驗當攻擊武器還是防守底線。
LCP 最大內容繪製的瓶頸與改善
LCP（Largest Contentful Paint，最大內容繪製）量測的是網頁可視區域中最大可見內容元素完成渲染的時間。良好門檻是 2.5 秒以下、超過 4 秒為不良 [來源：web.dev〈Core Web Vitals〉〈https://web.dev/articles/vitals〉〈2026〉]。 這個最大元素通常是一張主圖、Hero 圖或大段標題，先找出誰是最大元素，才知道要從哪裡下手。
Google 官方對 LCP 的定義是「從使用者要求網址開始，到可視區域中最大可見內容元素完成轉譯所需的時間」，最大元素通常是圖片或影片，也可能是區塊層級的大型文字。良好門檻是 2.5 秒以下、2.5 到 4 秒屬於需要改善、超過 4 秒為不良。實務上，LCP 紅字最常見的瓶頸集中在三個地方：伺服器回應速度、圖片大小、阻斷渲染的 JavaScript 與 CSS。先把這三個查一遍，多半能抓到元兇。其中伺服器回應這塊，導入CDN 為網站加速通常能直接壓低 TTFB、連帶改善 LCP。
圖片是 LCP 最常見的元兇，這一點幾乎沒有例外。改善手法很具體：改用現代格式（WebP 或 AVIF）、為圖片設定明確的寬高、延遲載入非首屏圖片。如果最大元素是文字，那就往字體載入去看，預先載入關鍵字體能直接縮短 LCP。其他可操作的方向包括升級處理更快的伺服器主機、啟用網頁快取、刪除不必要的 JavaScript、最佳化 JS 與 CSS。想深入可參考 Google 官方的《優化 Largest Contentful Paint》（web.dev/optimize-lcp）。 把這些手法串起來的整體做法，可以參考網站速度優化全攻略，而延遲載入的實作細節在Lazy Loading 延遲載入實戰指南有更完整的展開。
把 LCP 拆得更細，會看到一條時間軸：TTFB（第一個位元組時間）、資源載入時間、渲染時間。TTFB 太高，通常代表伺服器慢或後端查詢太重，CDN、快取、資料庫索引是解方；資源載入太慢，多半是圖片太大或 JS 太肥，對應壓縮與刪減；渲染被擋住，則是阻斷渲染的 CSS 或 JS 在排隊。這三段疊起來就是 LCP 的總秒數，優化時逐段拆開量測，比憑感覺改東改西有效得多。Google 在《優化 Largest Contentful Paint》把這條鏈拆成四個區間（TTFB、資源載入延遲、資源載入時間、元素渲染延遲），哪一段超標就攻哪一段。
這套邏輯有公開案例佐證，並非純理論。電信業者 Vodafone 把 LCP 改善 31%，就讓銷售增加 8%，直接印證「最大內容繪製」提速會反映在營收上，也是把 LCP 紅字推到綠色門檻最值得的證據之一 [來源：web.dev (Google)〈Why does speed matter?〉 https://web.dev/articles/why-speed-matters 2026]。
這裡要提醒一個常常被忽略的盲點：LCP 量的是「最大元素」，不是「第一個出現的元素」。所以你以為很快的首圖，可能根本不是 LCP 的評分對象，真正拖慢分數的是頁面下方那張超大 Hero 圖。這也是為什麼優化前一定要先用工具確認最大元素是誰，否則改了半天卻動到錯的元素。如果你的網站大量使用 JavaScript 動態產生內容，還要留意JavaScript SEO 與網站收錄教學提到的渲染問題，JS 渲染延遲會直接拖累 LCP。
CLS 累計版面配置位移：沒預留空間的代價
CLS（Cumulative Layout Shift，累計版面配置位移）量測的是使用者開啟網頁期間，所有非預期版面位移的累計分數。0 代表完全沒有位移，良好門檻是 0.1 以下、超過 0.25 為不良 [來源：web.dev〈Core Web Vitals〉〈https://web.dev/articles/vitals〉〈2026〉]。 分數由影響比例乘以距離比例計算，越晚發生、幅度越大的位移扣分越重。
畫面會跳，幾乎都是因為元素載入時沒有預留空間。最典型的場景：你正要點某個按鈕，結果上方突然冒出一張廣告或圖片，按鈕被往下推，你點到了廣告。這種體驗不只讓人火大，還會直接吃掉轉換。CLS 的元兇其實很集中，可以用一張表抓清楚。
| CLS 元兇 | 發生情境 | 改善方向 |
|---|---|---|
| 未設尺寸的圖片 | 圖片下載完才撐開版面 | 指定 width / height |
| 無尺寸的 iframe | 嵌入影片、地圖載入後位移 | 預留固定容器空間 |
| 動態插入的廣告 | 廣告載入把內容往下推 | 事先預留廣告佔位 |
| 第三方字體 | 字體載入造成文字重繪（FOUT/FOIT） | font-display: swap 搭配預載 |
| 延遲載入的嵌入內容 | 社群按讚框、推薦區塊晚到 | 為動態元素保留空間 |
幾個原則記起來就夠用：為所有圖片與 iframe 指定 width 與 height、為廣告與動態元素預留佔位空間、避免在已經渲染的內容上方插入新元素。字體引發的位移是進階題，可以用 font-display: swap 搭配預載字體減輕，不確定的話就先擱著，把前四項處理好通常 CLS 就能壓到綠色門檻。Google 官方《優化 Cumulative Layout Shift》（web.dev/optimize-cls）有更細的設定方法。
CLS 分數的計算方式值得拆開看，因為懂了算法就會知道哪些位移會被記分、哪些不會。一個位移事件的分數等於「影響比例」乘上「距離比例」。影響比例是位移前後兩個畫面框的聯集面積占可視區的比例，距離比例則是單一元素移動的最大距離占可視區的比例。兩者相乘再累加，就是 CLS。這套算法帶來兩個推論：第一，越靠近首屏、覆蓋面積越大的位移扣分越重，所以放在頁面頂端的廣告最危險；第二，使用者主動觸發的位移（例如點開選單）不算分，被記分的只有非預期、頁面自己產生的位移。掌握這點，優化時就能把力氣集中在「頁面自己會跳」的元素上，把使用者主動觸發的位移排除在外。
INP 接手 FID：從只看首次回應到全程追蹤
INP（Interaction to Next Paint，下次繪製的互動）是 2024 年 3 月正式取代 FID 的互動指標。良好門檻是 200 毫秒以下、超過 500 毫秒為不良 [來源：web.dev〈Core Web Vitals〉〈https://web.dev/articles/vitals〉〈2026〉]。 換掉 FID 的原因很單純：FID 只量測使用者第一次互動到瀏覽器開始回應的等待時間，後續互動品質完全看不到。
這是 INP 跟 FID 最關鍵的差異：FID 只看「第一次」，INP 看整個頁面生命週期中所有互動，並取其中最差的那一次當評分。打個比方，FID 像只量測開機後第一次點滑鼠的延遲，INP 則是把你這一整段使用過程中最卡的瞬間抓出來算分。一個頁面就算首次回應很快，只要中間有哪次點擊卡住了，INP 還是會給你紅字，這正是 FID 抓不到的盲區。兩者的比較在INP 取代 FID 的完整比較與原因有更完整的展開。
| 項目 | FID（已退役） | INP（現行） |
|---|---|---|
| 觀測範圍 | 僅首次互動 | 整個頁面生命週期所有互動 |
| 計分方式 | 首次輸入延遲 | 所有互動中最長的那次 |
| 良好門檻 | 100 毫秒以下 | 200 毫秒以下 |
| 需要改善 | 300 毫秒以下 | 500 毫秒以下 |
| 不良 | 超過 300 毫秒 | 超過 500 毫秒 |
| 生效狀態 | 2024 年 3 月退役 [來源：web.dev〈Core Web Vitals〉〈https://web.dev/articles/vitals〉〈2026〉] | 穩定核心指標 |
INP 的優化方向跟舊 FID 有很大重疊：分割長任務、延遲載入非必要的 JavaScript、壓縮 JS 與圖片、減少主執行緒阻塞。Web Worker 則是把重度運算搬離主執行緒，是改善 INP 與舊 FID 共通的手法。想更深入可以參考 Google 官方的《優化 Interaction to Next Paint》（web.dev/articles/optimize-inp）。 對舊報表裡的 FID 數字，只要記得它是 100 毫秒以下良好、300 毫秒以下需要改善、超過 300 毫秒不良，留作解讀歷史資料用就好，不必再花力氣優化。
要真正改善 INP，得先理解一次互動在瀏覽器裡拆成三段：輸入延遲（input delay，從使用者點下去到事件處理器開始跑的等待）、處理時間（processing duration，事件處理器實際執行的時間）、呈現延遲（presentation delay，處理完到畫面更新出現的時間）。INP 量的是這三段加總。輸入延遲過高通常是主執行緒被長任務佔住，這時要把長任務分割或搬到 Web Worker；處理時間過高代表事件處理器本身寫得太重，要拆分或快取；呈現延遲過高則多半是渲染工作量太大，要減少 DOM 節點或動畫。診斷時用 Chrome DevTools 的 Performance 面板或 Lighthouse 的 INP 分析，先看是哪一段超標，再對症下手，遠比把所有 JS 一律延遲載入更精準。
INP 的改善同樣有真實案例背書。票務平台 redBus 改善網站的 INP（Interaction to Next Paint）後，銷售增加了 7%，顯示互動回應變快會直接轉換成下單成果，也說明 2024 年 3 月 INP 接手 FID 之後，互動維度的優化有實實在在的商業回報 [來源：web.dev (Google)〈Why does speed matter?〉 https://web.dev/articles/why-speed-matters 2026]。
四大指標門檻總覽表
把四個指標的良好、需要改善、不良門檻整理在一起，方便對照。實務上只要盯 LCP、CLS、INP 三項都達到良好門檻即可，FID 僅保留給解讀舊報表時參考。門檻數值來源是 web.dev 官方文件，Google 可能隨政策微調，以官方最新公告為準。
| 指標 | 維度 | 良好 | 需要改善 | 不良 |
|---|---|---|---|---|
| LCP | 載入 | 2.5 秒以下 | 4 秒以下 | 超過 4 秒 |
| CLS | 視覺穩定 | 0.1 以下 | 0.25 以下 | 超過 0.25 |
| INP | 互動（現行） | 200 毫秒以下 | 500 毫秒以下 | 超過 500 毫秒 |
| FID | 互動（已退役） | 100 毫秒以下 | 300 毫秒以下 | 超過 300 毫秒 |
門檻表看起來是死數字，但背後藏著一個設計哲學：Google 不要求你把每項都推到極致，只要求你跨過「良好」這條線。跨過之後再往上擠，對排名的邊際效益很小。所以與其花兩個月把 LCP 從 2.4 秒壓到 1.8 秒，不如先確認三項都是綠色，然後把力氣轉去補內容。這個取捨跟整體 SEO 資源配置是一致的，可以對照關鍵字研究終極指南的優先順序邏輯一起想。同一個關鍵字寫太多篇互相搶排名，是另一個常見的資源浪費，處理方式可以看關鍵字蠶食的修復策略。
門檻也會跟其他技術設定連動。例如你啟用了SEO 結構化資料介紹、Canonical 標準網址、XML Sitemap，這些本身不直接影響 CWV，但如果實作不當（例如大量 JSON-LD 阻塞渲染），會反過來拖累 LCP 或 INP。設定類的工具像是 robots.txt 不影響 CWV，但跟整體可爬取性有關，兩者要分開看。
檢視 Core Web Vitals 的兩個官方工具
檢查 CWV 最直接的兩個免費工具是 PageSpeed Insights 和 Google Search Console。前者輸入單一網址就能同時看到實驗室數據與真實使用者數據，適合逐頁檢查；後者在「體驗＞網站使用體驗核心指標」報表一次列出全站有問題的網址清單，適合全站體檢。CWV 真正要看的是真實使用者數據（CrUX field data），不是實驗室模擬。
PageSpeed Insights 把資料分成兩塊：上半部的「發現使用者在您的網站上的實際體驗為何」是 field data（CWV 看這個），下半部的「診斷網站效能問題」是 Lighthouse 跑出來的實驗室數據。很多人只看下面那個 0 到 100 的分數，但那個分數跟 Google 排名參考的不是同一份資料。要追的是上面那一塊的 LCP、CLS、INP。除了 PageSpeed Insights，市面上還有其他網站速度測試工具可以交叉比對數據。
Search Console 的 CWV 報表會把網址分成「不良」「需要改善」「良好」三類，直接列出哪些網址要修。這對排定修復優先順序非常有用，因為你不必逐頁跑 PSI，一次就能看到全站的問題熱區。修復後可以在同一個報表驗證，不過部署後要等資料更新，通常需要數週才會反映。這個工具的完整操作可以參考GSC 報表功能與操作教學，還沒安裝的人先從安裝教學看起。
一個常讓人困惑的點：為什麼小流量網站在 PageSpeed Insights 看不到 field data？因為 CrUX 資料需要一定的流量門檻才會生成，低流量站點可能只顯示實驗室數據 [來源：web.dev〈Chrome UX Report〉〈https://web.dev/articles/crux〉〈2026〉]。 這不代表你的網站沒問題，只代表 Google 還沒累積到足夠的真實樣本。這時候實驗室數據是唯一能參考的，但要知道它跟排名參考的資料不是同一份。想追蹤更細的互動數據，可以用 web-vitals JavaScript 程式庫把 field data 送進 GA4 新手完整教學自行分析，搭配Looker Studio Dashboard 設計把報表視覺化。要解讀訪客工作階段的定義與算法，可以對照GA4 工作階段完整解析。
把這個「資料來源落差」講清楚，會幫你避免一個昂貴的錯誤：拿 Lighthouse 分數去解釋排名變動。Lighthouse 在固定裝置、固定網路、固定腳本下跑分，分數很穩定，但跟排名參考的 CrUX 真實數據不是同一份。一個網站可以在 Lighthouse 拿 95 分，卻在真實使用者手上的 4G 環境裡 LCP 拖到 5 秒；也可能 Lighthouse 只有 70 分，真實數據卻一片綠色。兩者方向一致是好事，但當它們打架時，永遠以 CrUX field data 為準，因為那才是 Google 排名實際看的那份。養成「先看 field、再看 lab」的習慣，能省下大量往錯方向優化的時間。
工具選擇上，CWV 的診斷主力是 PageSpeed Insights 與 Search Console，這兩個是 Google 官方、免費、資料來源就是排名參考的那一份。第三方工具可以補充，但別取代這兩個。跟 CWV 相關的延伸工具還有 Google Tag Manager 安裝教學，用來部署 web-vitals 追蹤；想看整體 SEO 工具版圖可以參考Ranking SEO 工具推薦。
CWV 與行動優先索引：手機版才是評分對象
理解 CWV，離不開 Google 的行動優先索引（mobile-first indexing）。早在 2020 年 3 月，Google 就宣布當時搜尋結果中已有約七成網站完成行動優先索引轉換，並承諾同年 9 月起全面套用 [來源：Google Search Central Blog〈Mobile-first indexing for the whole web〉 https://developers.google.com/search/blog/2020/03/announcing-mobile-first-indexing-for 2020]；到了 2023 年 10 月 31 日，Google 正式宣告行動優先索引已完成，所有可在行動裝置運作的網站，主要都由行動爬蟲檢索 [來源：Google Search Central Blog〈Mobile-first indexing is here〉 https://developers.google.com/search/blog/2023/10/mobile-first-is-here 2023]。換句話說，Google 用來排名、用來評估 CWV 的那個版本，預設就是手機版。
這件事對 CWV 的意義很實際。全球網站流量在 2026 年第一季有 52.27% 來自行動裝置（不含平板）[來源：Statista〈Share of mobile web traffic worldwide quarterly 2015-2026〉 https://www.statista.com/statistics/277125/share-of-website-traffic-coming-from-mobile-devices/ 2026]，過半流量已經在手機上。手機的 CPU、記憶體、網路條件都比桌機嚴苛，同一個頁面在手機上的 LCP、INP 往往比桌機差一截。因此你在桌機用 Chrome DevTools 跑出來的漂亮分數，跟 Google 真正評分的手機版很可能落差很大。實務上建議固定用 PageSpeed Insights 的「行動」分頁當主戰場，把桌機當輔助參考，這樣優化方向才會對準排名實際看的那個版本。
行動優先索引還帶出一個常被忽略的雷區：桌機版與手機版內容不一致。有些網站為了讓手機版更輕快，會在手機版刪掉部分內容或功能，結果 Google 拿到的手機版內容比桌機少，連帶影響內容相關訊號。正確做法是讓手機版與桌機版提供對等的內容，再用 CWV 優化去處理速度問題，避免用刪內容換速度這種犧牲排名訊號的捷徑。把這個觀念跟行動版網頁 SEO 優化一起看，才能避免「為了衝 CWV 分數反而弄丟內容訊號」的失誤。
非工程背景的 CWV 優化守則：別亂裝外掛、會牽一髮動全身
非工程背景的人看到 CWV 紅字，能做的主要是看懂報表、把問題描述清楚、找對人改，自己動程式碼反倒不是必要。兩個最大的地雷要避開：一是亂裝 WordPress 快取或效能外掛導致互相衝突，二是只改單一指標卻拖垮另一個指標。CWV 的調整項目大多數需要動到程式碼或伺服器設定，這不是看個教學文就能上手的活。
第一個地雷：外掛互打。WordPress 生態裡有各種快取、圖片最佳化、延遲載入外掛，很多人裝了三、四個想說加乘效果，結果設定互相打架，CWV 不降反升。原則是同一類功能只用一個外掛，設定好之後再驗證，不要疊床架屋。第二個地雷：指標之間會互相影響。延遲載入 JavaScript 可以改善 INP，但如果延後了 LCP 元素相關的資源，LCP 反而會變慢。優化是整體平衡的取捨，不是單點衝高分。這類設計與外掛選擇的取捨，在自架網站常見的網頁設計錯誤裡有不少前車之鑑可以借鏡。
這條「外掛互打」的提醒之所以反覆講，是因為 WordPress 的市占讓它變成絕大多數自架站的起點。根據 W3Techs 截至 2026 年 6 月的統計，WordPress 被用在 41.5% 的全體網站上，佔已知內容管理系統網站的 59.2% [來源：W3Techs〈Usage Statistics and Market Share of WordPress〉 https://w3techs.com/technologies/details/cm-wordpress 2026]。這代表「CWV 紅字＋多個效能外掛互打」是極為常見的組合，而非特例。正因為 WordPress 生態的外掛選擇太多，同一類功能（快取、圖片壓縮、延遲載入、JS 最佳化）常常有好幾套互相重疊，疊裝之後衝突機率大增。選外掛時先確認每套各自負責什麼，把職責畫清楚再裝，會比追求「裝越多越好」穩當。
跟工程師或外包廠商溝通時，做這幾件事能大幅縮短往返：把 PageSpeed Insights 的報表截圖、附上問題網址、標出哪一項是紅字，然後直接說「LCP 超過 4 秒，最大元素是首圖，請幫我查圖片大小跟伺服器回應時間」。具體的描述比「網站很慢請修一下」有效得多。改動後務必用 PageSpeed Insights 與 Search Console 重新驗證，不要只憑單次分數判斷，因為 field data 本來就有波動。幾個常被忽略的配套原則：同一類效能外掛只裝一個，設定後再驗證要不要加；改善 INP 時回頭確認是否延後了 LCP 資源；部署後用 PSI 與 Search Console 雙重確認，等數週看 field data 更新；改版、新增外掛、換主機後都要重檢 CWV。
給一個具體的優先順序判準，方便非工程背景的人自己把脈：先用 PageSpeed Insights 的「行動」分頁跑首頁與前幾個高流量頁，看哪一項掛紅字。假設一個月自然流量約數萬次、桌上型電腦載入還行，但行動版 LCP 落在 4 秒以上，這時第一輪只做三件事就夠看：把首圖改 WebP 並補上寬高、啟用快取、把首屏不需要的 JS 延遲載入。這三步通常能把 LCP 壓回 2.5 秒附近，工程成本極低，完全符合前面決策矩陣裡「影響大、難度低」的象限。要等到三項都進綠色門檻，再評估是否動到伺服器架構或 JS 框架重構這類高難度工作。把這個「先低成本三步、再評估重構」的節奏記下來，能避免一開始就過度投入。
這裡也常見一個會反撲的錯誤：為了讓 LCP 立刻變綠，把所有圖片一率套上延遲載入，結果把首屏那張正是 LCP 元素的主圖也延後了，分數不降反升。判斷原則很簡單：位於首屏可視區的 LCP 元素絕對不能延遲載入，反而該用預先載入（preload）優先取得；只有折到首屏以下的圖片才適合延遲載入。同一個手法放錯位置，效果完全相反，這正是只看單一指標而不理解機制最容易踩的雷。
要特別強調的是，CWV 是長期維護指標，不是一次做完就永久有效。網站改版會動到版面與資源載入順序，新增外掛會改變 JS 載入量，換主機會影響伺服器回應時間，任何一項都可能讓原本綠色的指標掉回紅字。所以 CWV 要納入日常的網站維護流程，跟SEO 年度內容更新建議、網站搬家與改版的 SEO 風險這類定期檢查一起做。起步階段先確認選的平台對 CWV 友善，避開會綁手綁腳的選擇，再從設計端把體驗基礎打穩。
CWV 優化決策矩陣：把力氣花在對的地方
資源有限的時候，最怕的不是不優化，而是優化錯方向。這裡用一個二維矩陣幫你排優先順序：橫軸是「對使用者的影響大小」，縱軸是「改善的技術難度」。把每一項 CWV 工作放進這個矩陣，立刻看得出哪些該先做、哪些可以擺後面。
| 象限 | 影響大、難度低（先做） | 影響大、難度高（排程做） |
|---|---|---|
| 代表工作 | 圖片改 WebP/AVIF、設寬高、啟用快取、CDN | 拆分長任務、Web Worker、伺服器架構重構 |
| 象限 | 影響小、難度低（順手做） | 影響小、難度高（先擱著） |
| 代表工作 | font-display: swap、刪多餘外掛、預載關鍵字體 | 深層 JS 框架重寫、第三方腳本全替換 |
這個矩陣的核心判斷只有一句話：影響大又好做的先做，影響小又難做的最後做。圖片壓縮跟設寬高幾乎是零成本卻能直接搬動 LCP 與 CLS，所以永遠排在第一輪；JS 框架重寫雖然可能讓 INP 大幅改善，但工程成本高、風險大，應該等前三項指標都過門檻後再評估。把這個順序寫進維護流程，就不會出現「花兩個月重構前端、結果 LCP 其實只需要換個圖片格式」這種本末倒置。
矩陣之外，再給一個常被忽略的提醒：第三方腳本是 CWV 的隱形殺手。廣告、分析、社群按讚框、客服聊天外掛，每一個都會載入額外的 JS 並佔用主執行緒。單看各自影響都不大，疊起來卻可能讓 INP 直接破表。排查時用 PageSpeed Insights 的「減少第三方程式碼影響」建議，或 Chrome DevTools 的 Coverage 面板，找出哪些腳本實際用到、哪些只是白載，把用不到的拿掉，往往是 CP 值最高的 INP 優化動作。
CWV 排查清單：紅字出現時的標準動作
當 Search Console 跳出 CWV 紅字，別急著動手改，先把問題定位清楚。一份好的排查流程會把「發現、定位、修復、驗證」四個階段拆開，照著走能避免盲改。
- 確認是哪一項指標紅字：LCP、CLS、還是 INP，三者修法完全不同，混在一起談只會失焦。
- 判斷是全站問題還是單頁問題：Search Console 報表若整批網址同時紅字，多半是共通資源（主題、外掛、主機）出狀況；若是單頁，就縮小到該頁的特定元素。
- 用 PageSpeed Insights 逐項看 field data 與 lab data 是否一致：兩者方向一致代表問題明確，方向相反代表真實環境另有因素（例如第三方腳本、行動網路）。
- 定位元兇：LCP 查最大元素與 TTFB；CLS 查未設尺寸的圖片、iframe、動態插入的廣告；INP 查長任務、第三方腳本、主執行緒阻塞。
- 提出最小改動方案：先試不動架構的修法（換圖片格式、設寬高、延遲載入、設快取），無效再升級到動程式碼的修法。
- 部署後雙重驗證：先看 PageSpeed Insights 的 lab data 即時反映，再等 Search Console 的 field data 數週更新確認。
- 記錄變更：把這次改了什麼、為什麼改寫進維護紀錄，下次同樣症狀再出現就能直接對照。
這份清單的重點其實是「先定位再動手」。很多人看到紅字就直覺裝外掛、刪 JS，結果改了半天分數沒動，因為根本沒先確認問題出在哪一項、哪一頁、哪個元素。花十分鐘走完前四步，往往比花兩小時盲改更省事，也更容易把問題準確交辦給工程師。
把上面這套流程套到一個典型情境，會更具體。以一個月自然流量約數萬次、用 WordPress 主題搭配幾支常見快取與圖片外掛的內容站為例，這類站常見的狀況是：桌機版三項大致落在良好門檻附近，但行動版的 LCP 約落在 3.5 到 4.5 秒之間、INP 約落在 280 到 380 毫秒，兩項都卡在「需要改善」或剛踩進不良區間，CLS 則多半因為首屏廣告與無尺寸圖片而約落在 0.12 到 0.2。這屬於依這類站的典型表現幅度大概會落到的區間，並非某一個特定網站的實測報告，主要成因集中在三件事：首圖沒有指定寬高且未改現代格式、首屏廣告容器沒有預留佔位、第三方分析與社群腳本疊加佔住主執行緒。依照排查清單先定位再動手，第一輪通常只做三件事：把首圖改 WebP 並補上明確寬高、為廣告容器預留固定空間、用 PageSpeed Insights 的「減少第三方程式碼影響」清掉用不到的腳本，行動版 LCP 往往能往 2.5 到 3 秒靠攏、INP 也能回到 200 毫秒出頭。
這個典型情境裡也藏著一個常見的失敗點，值得先記下來。很多人在第一輪之後會想再壓低 LCP，於是連首屏那張正是 LCP 元素的主圖都套上延遲載入，結果 LCP 反而變慢，分數不降反升，前面提到的首屏元素絕對不能延遲載入、只能用預先載入這條原則就是這裡踩雷。另一個更根本的限制是，這類站的改善幅度會被主題本身的程式碼品質與主機回應速度框住，若 TTFB 本身就偏高，單靠前端調整很難把 LCP 推進 2.5 秒以下。所以決策角度是：先確認三項都進綠色門檻，把首圖、佔位、第三方腳本這類影響大、難度低的工作做完，若 LCP 仍卡在 3 秒上下，才把資源轉向升級主機或換掉載入過重的主題，先別急著繼續在前端硬擠。這個「先低成本三步、再評估架構層」的節奏，跟前面決策矩陣的判斷是一致的。
不該把 CWV 擺第一的情境
CWV 重要，但仍有情境不該把它擺在第一位。以下幾種情況，硬衝 CWV 反而是資源錯置。
- 內容還沒站穩的網站：如果網站只有少量薄內容，再快的載入也沒有東西可以排名。這時優先補內容與搜尋意圖，CWV 留到內容到位後再顧。
- 低流量站點看不到 field data：前面提過 CrUX 需要流量門檻，新站或冷門站在 PSI 看不到真實數據，這時盯 lab 分數意義有限，把力氣放在收錄與外部連結更實在。
- 已有內容但完全沒收錄：連索引都進不去的網站，CWV 再漂亮也沒人看。先解決索引是什麼與如何確認被收錄的收錄問題，CWV 排在收錄之後。
- 過度優化風險：為了把 LCP 從 2.3 秒壓到 1.9 秒而犧牲掉功能或內容，得不償失。過了良好門檻後，邊際效益就明顯遞減。
這些情境的共同點是「CWV 的前提還沒成立」。CWV 是平手破局因素，它的前提是內容已經到位、網站已經被收錄、流量已經足以產生 field data。前提不成立時，把 CWV 當主戰場就是搞錯戰略層級。把這個判斷跟前面的決策矩陣結合，資源配置才會落在對的位置。
把幾個會被忘掉的觀念收在一起。Core Web Vitals 是三個獨立維度的組合，不是一個分數；2024 年 3 月後真正要盯的是 LCP、CLS、INP；Google 看的是真實使用者數據，不是實驗室模擬；它屬於平手破局因素，過了綠色門檻就該把力氣轉回內容。CWV 是基礎建設，內容才是主排名要素，這個優先順序搞反，再多優化也補不回來。想跟上搜尋趨勢的變化，可以看AI 搜尋時代的 SEO 全攻略，把實作交給工具時則參考AI SEO 實戰心法的落地做法。
再往外延伸一層，CWV 跟整個 SEO 生態的關係也要看清楚。它跟檢索、索引屬於同一條技術 SEO 鏈，CWV 是體驗端，前面幾項是收錄端，兩端都要顧。連結面、網址與網域面雖然跟 CWV 不直接相關，但構成完整的技術 SEO 底盤。要把這條鏈從頭到尾串起來，可以讀技術性 SEO 完全指南；網站規模變大後，爬取預算的優化策略會直接影響重要頁面能不能被收錄。
最後要給一個觀念：CWV 不是終點，是 AI 時代搜尋體驗的一環。隨著 Google AI Overviews、AI Mode、SERP 元素演進，使用者對「點進去能不能馬上看到、能不能馬上互動」的容忍度只會更低，CWV 的權重只會更實在。內容產製端則別忘了文章排版與完讀率提升，排版與 CWV 其實是同一件事的兩面：一個管內容好不好讀，一個管畫面好不好用。
Core Web Vitals 常見問題
Core Web Vitals 會影響 SEO 排名嗎？
會，但屬於平手破局性質。Google 把 CWV 列為頁面體驗排名因素之一，當兩個網站內容品質接近時，體驗較好的那邊勝出。內容差距大時，CWV 滿分也救不回劣勢 [來源：Google Search Central〈Understanding Core Web Vitals〉〈https://developers.google.com/search/docs/appearance/page-experience〉〈2026〉]。
非工程背景的人可以自己優化 CWV 嗎？
能做的是看懂報表、把問題描述清楚、找對人改。多數調整需要動程式碼或伺服器設定，不建議自己亂裝外掛。最大地雷是同時裝多個效能外掛互相衝突，反而讓分數更糟。
LCP 太慢該怎麼改善？
先確認最大元素是誰（通常是首圖或 Hero 圖），再從三個方向下手：升級伺服器主機與啟用快取、壓縮圖片並改用 WebP/AVIF、刪除阻斷渲染的 JavaScript。預先載入關鍵字體也有幫助。
CLS 分數過高怎麼解決？
為所有圖片與 iframe 指定 width 與 height、為廣告與動態元素預留佔位空間、避免在已渲染內容上方插入新元素。字體位移可用 font-display: swap 搭配預載減輕。
優化某一個 CWV 指標會影響另一個嗎？
會。例如延遲載入 JavaScript 能改善 INP，卻可能延後 LCP 元素導致 LCP 變慢。CWV 是整體平衡的取捨，改完要用工具重新驗證三項一起看。