Core Web Vitals 攻略：LCP、INP、CLS 優化實戰

Core Web Vitals 不會單獨解釋一個頁面為何卡在第二頁，但它能指出真實使用者在載入、互動與版面穩定度上的問題。這篇直接從實戰角度切入：怎麼量、怎麼診斷、怎麼修、修到哪裡該停。

重點摘述

• Core Web Vitals（核心網站使用體驗指標，簡稱 CWV）是 Google 用三個數字量化「使用者在頁面上體驗有多順」的指標：LCP 看載入、INP 看互動、CLS 看視覺穩定度。
• CWV 是 Google 頁面體驗訊號的一部分，但相關性仍是首要考量；好的 CWV 不保證排名，也沒有官方所稱的固定「同分決勝」機制。
• 三個指標的及格門檻分別是 LCP ≤ 2.5 秒、INP ≤ 200 毫秒、CLS ≤ 0.1。只要落在「Good（良好）」區間，再往上的邊際效益很低。
• 優化順序永遠是：先用 CrUX 實測數據確認問題、再對症下藥。最忌諱看到 Lighthouse 分數低就亂改一通。

Core Web Vitals 是什麼？Google 給你網站的「體驗成績單」

用一個比喻讓你秒懂。把你的網站想像成一家實體餐廳。訪客走進來，從「點完餐到第一道菜上桌」要等多久（這是 LCP，載入速度）；點餐過程中，服務生能不能立刻回應你的每一個問題、還是叫了半天沒人理（這是 INP，互動流暢度）；吃到一半，桌上的杯子突然被服務生挪來挪去，你連筷子都夾不穩（這是 CLS，視覺穩定度）。

Core Web Vitals 就是 Google 派來的「神祕客」，用這三個維度幫你的每一個頁面打分數。這套指標從 2020 年公布、2021 年中正式併入排名系統，到 2024 年 3 月又把互動指標從 FID 換成更嚴格的 INP，已經穩定運作好幾年了，各指標門檻定義可查 web.dev 的 Core Web Vitals 文件。它不是那種一閃即逝的演算法更新，Google 投資這套指標的時間與工程資源，說明它是長期的基礎建設。

換句話說，Google 的邏輯其實很單純：搜尋引擎的服務對象是人，不是機器。如果 Google 把使用者送到一個會卡頓、會跳動、會讓人等十秒的頁面，使用者下次就會改用別的搜尋引擎。所以 Google 非得把「頁面體驗」納入排名不可，這是它保護自己市佔率的防禦性設計，不是做慈善。

很多人把 CWV 當成「排名救星」，以為把分數衝到全綠就會飛上第一頁，這是誤解。Google 說明，頁面體驗是排名系統考量的一部分，但即使某些體驗指標不理想，高度相關的內容仍可能排名。把 CWV 當成使用者體驗與技術品質的基本功，不要拿它替代內容判斷，出處是 Google Search Central 對網頁體驗的說明。

為什麼速度會變成排名因素？從 2018 年 Speed Update 說起

要把這件事講清楚，得回到 2018 年。那一年 Google 推出 Speed Update，首次正式宣告「行動版搜尋排名會把頁面速度列入考量」。在那之前，速度只被當作「使用者體驗」的隱性因素，沒有獨立的排名權重。Speed Update 之後，Google 又花了兩年把抽象的「速度」具體化成可量測的三個指標，這就是 CWV 的由來。

web.dev 有一篇很經典的文章〈Why does speed matter?〉，裡面引用的研究數字值得一記：當頁面載入時間從 1 秒拉長到 3 秒，跳出率（bounce rate）會明顯攀升；到 5 秒以上，行動裝置的使用者多半已經不耐煩了。這並非 Google 刻意嚇人，背後是扎實的使用者行為數據。速度慢，人就走，這是物理。

但這裡要打一下「速度至上派」的臉。從實戰來看，CWV 對排名的「直接」拉抬力道其實有限。它更像是一個負向篩選器：

• 落在「Poor（差）」區間，表示至少四分之一的實際造訪未達建議體驗，應先確認影響範圍與商業頁面。
• 從「Poor」修到「Good」可能改善使用體驗，但排名或流量是否變動要另行量測，不能預設因果。
• 已在「Good」時，是否繼續優化應看轉換、錯誤率與工程成本，不必只為了排名追更低的數字。

換句話說，CWV 的投資報酬率是「先甜後淡」。把爛的修到及格，CP 值最高；把及格的修到滿分，多半是給自己找事做。這個觀念後面會用一整節來談「停止線」，因為太多站長死在追求滿分的路上。

想更深入理解 CWV 的基礎概念，可以先看這篇CWV 白話文介紹，它把 LCP、FID、CLS、INP 的定義講得很清楚。這篇要處理的，是定義之外更值錢的東西：怎麼量、怎麼修、怎麼取捨。

LCP、INP、CLS 的白話翻譯與及格門檻

官方定義這裡不再背一次給你聽，那對實戰沒幫助。改用「你會記得住」的方式重講一次，並把 Google 公布的及格門檻整理成一張表。這三個數字請務必記起來，後面所有的診斷都繞著它們轉。

指標	白話一句話	Good（良好）	Needs Improvement（需改善）	Poor（差）
LCP（Largest Contentful Paint，最大內容繪製）	頁面上那個最大的元素（通常是首圖或大標題）完整畫出來要花幾秒	≤ 2.5 秒	2.5 到 4.0 秒	> 4.0 秒
INP（Interaction to Next Paint，互動到下次繪製）	使用者每次點、按、輸入，畫面回應他所需的時間綜合表現	≤ 200 毫秒	200 到 500 毫秒	> 500 毫秒
CLS（Cumulative Layout Shift，累計版面位移）	頁面載入過程中，元素跳來跳去的總位移分數	≤ 0.1	0.1 到 0.25	> 0.25

三個指標各自對應一種「使用者最討厭的感覺」：

• LCP 對應「等」的焦慮。畫面一直空白，你不知道是不是壞掉了。
• INP 對應「卡」的挫折。你按了按鈕，它過了半秒才理你，你會懷疑自己是不是沒按到。
• CLS 對應「被偷跑」的憤怒。你想點 A 連結，結果畫面一跳，卻點到了旁邊的廣告。

這三種負面感受，剛好覆蓋了使用者跟頁面互動的完整旅程：進場、操作、停留。這就是為什麼 Google 精挑細選出這三個指標，數量不多不少。它們是「頁面體驗」這個抽象概念裡，最有鑑別度的三個切片。

一個關鍵觀念：這三個門檻看的是 75 分位數（p75），不是平均值。意思是 Google 會把你這個頁面所有訪客的數據排序，取第 75% 那個人的體驗當代表。這個設計很兇殘，它強迫你不能只照顧「多數人」，還得照顧到「那 25% 體驗最差的人」。如果你的頁面對某些裝置、某些網路環境特別不友善，p75 就會被拉高，即便平均數字看起來很漂亮也沒用。

量測篇》CrUX 實測數據 vs Lab 實驗室數據，你被哪個騙過？

這一節是整篇文章裡最值錢的一段，因為九成的站長在這裡栽過跟斗。CWV 有兩種數據來源，搞混它們，你會花一堆時間修錯問題。

第一種叫 Field Data（實測數據），來自 Chrome 使用者親身造訪你網站時回傳的真實數據，資料庫叫 CrUX（Chrome User Experience Report）。這是 Google 排名時真正看的數字。它的特色是真實、涵蓋各種裝置與網路，但缺點是「滯後」：它反映的是過去 28 天的累計表現，你今天改了東西，要等資料累積才看得到效果。

第二種叫 Lab Data（實驗室數據），是 Lighthouse 這類工具在一個受控環境（通常是一台伺服器、固定的網速、固定的裝置）裡模擬跑出來的數字。它的特色是即時、可重現、適合debug，但缺點是「失真」：它跑出來的 LCP 不見得等於真實使用者的 LCP，因為你的真實訪客用的可能是 4G、舊手機、被廣告腳本拖累的瀏覽器。

比較項目	CrUX / Field Data（實測）	Lighthouse / Lab Data（實驗室）
資料來源	真實 Chrome 使用者	模擬環境跑一次
Google 排名看哪個	看這個	不看（但會被拿來當診斷參考）
即時性	滯後約 28 天	當下秒出
適合用途	判斷「要不要修」	判斷「問題出在哪」

實戰流程是這樣的：先用 Field Data 確認你的頁面到底有沒有問題、問題多嚴重，再用 Lab Data 去定位 root cause。順序不能顛倒。最忌諱的是打開 PageSpeed Insights 看到 Lighthouse 分數 55 分就緊張兮兮地改了一堆東西，結果進 Google Search Console 一看，CrUX 的 LCP 早就是 1.8 秒、INP 180 毫秒，全部綠燈，根本不需要動。

那個 55 分是 Lab Data 給你的「模擬分數」，它跟你真實訪客的體驗可以差到十萬八千里。Lab Data 是拿來找方向的，不是拿來評分的。把這句話記下來，你會省下幾十個小時的瞎忙。

要看你自己網站的 CrUX 數據，最直接的管道是 Google Search Console。GSC 裡有一個「網頁體驗」區塊，會直接列出哪些 URL 的 CWV 不及格，而且是分移動裝置與桌機給你看。如果想看公開的 CrUX 資料（包含競品），可以到 Google 官方的 CrUX Dashboard 或 PageSpeed Insights 貼網址。更多檢測工具的比較，可以參考這篇網站速度測試工具推薦。

行動優先索引是 Google 主要使用手機版內容進行檢索與索引，不是手機 CWV 自動取得額外排名權重。對 CWV 來說，真正該優先修哪個裝置，要看你的實際流量、轉換與 CrUX 問題分布；多數網站仍應重視行動裝置，因為手機常受較慢網路與較弱硬體影響。「桌機上開很快」不能代表手機使用者也有相同體驗。

LCP 攻略》找出那個「最慢的大傢伙」

LCP 是三個指標裡最容易理解、也最容易修的，但前提是你得先抓出「那個大傢伙是誰」。LCP 的全名是 Largest Contentful Paint，關鍵字是「Largest」。Google 會自動找出你頁面可視區域（viewport）裡，那個面積最大的元素，然後量它完整渲染出來的時間。這個元素通常是：

• 首屏的一張大圖（hero image）
• 一段大字號的標題或背景圖
• 一段影片的預覽縮圖
• 少數情況下，是一個被 CSS 背景圖撐大的區塊

優化 LCP 的第一步，是用 Chrome DevTools 的 Performance 面板或 PageSpeed Insights 找出實際的 LCP 元素，再檢查它的資源大小、載入優先序、伺服器回應與渲染延遲。不要在尚未定位瓶頸前直接更換主機或加裝快取工具；先確認問題來源，再選擇對應措施。

抓到兇手之後，修法依元素類型不同而不同。整理成一個決策路徑如下：

兇手是圖片（最常見）

這是 LCP 超標的第一大原因，修法也最標準。請依序檢查這幾件事：

1. 換格式：還在用 PNG/JPG 當首圖？改用 WebP 或 AVIF，檔案大小通常能壓掉 25% 到 50%，畫質幾乎無損。格式選擇的細節可以看這篇圖片格式深度比較。
2. 壓縮：即便換了格式，還要再過一次無損或輕度有損壓縮。工具選擇參考這篇圖片壓縮工具實測。
3. 設 priority：給 LCP 圖片加上 fetchpriority="high" 這個屬性，告訴瀏覽器「這張最重要，優先載」。這是很多人不知道的小開關，效果立竿見影。
4. 不要 lazy load 它：延遲載入（lazy loading）是雙刃劍，用在首屏以下的圖可以省頻寬，但用在你 LCP 那張圖上，等於叫瀏覽器先去做別的事再回頭載它，反而更慢。首屏圖絕對不要 lazy load。

兇手是網頁字體（Web Fonts）

Google Fonts 雖然好用，但它會透過外部請求載入，瀏覽器為了避免「字載入一半、文字跳一下」的 FOIT（Flash of Invisible Text）問題，會把文字藏起來等字。這段等待時間會直接灌到 LCP 上。修法是把字體本機託管，或至少加上 font-display: swap 讓系統字先顯示。WordPress 站長可以參考這篇本機託管 Google Fonts 教學。

兇手是伺服器回應太慢（TTFB 過高）

如果 LCP 元素本身不大、載得很快，但 LCP 數字還是高，那問題往往出在「伺服器吐第一個位元組給瀏覽器之前就花了太久」，這叫 TTFB（Time to First Byte）。這時候才輪到快取、CDN、主機升級這些解法出場。網站快取的概念跟 CDN 加速原理可以一起看。如果是主機本身太弱，換到等級好一點的主機往往是最有感的單一改動，主機類型的選擇可以參考這篇四種虛擬主機類型比較。

一個實用的判斷口訣：LCP 高，先問「那個大傢伙是什麼」，再問「它從哪裡來」，最後才問「它怎麼被送過來」。這個順序對應到「元素、檔案、伺服器」三層，由淺入深，不會讓你一開始就掉進主機與 CDN 的深淵裡。

INP 攻略》2024 年取代 FID 的新魔王，為什麼這麼難修？

INP 是三個指標裡最年輕、也最棘手的一個。2024 年 3 月它正式取代 FID 成為 CWV 的互動指標，這個換替讓一大票原本「勉強及格」的網站瞬間掉進紅區。為什麼？因為 FID 跟 INP 量的是完全不同的東西。

FID（First Input Delay）只量「使用者第一次跟頁面互動時，瀏覽器多久才開始回應」。它只看第一次，而且只看「開始回應」的那一刻，不看後續。這給了網站一個很大的漏洞：只要第一次互動快，後面再卡都沒關係。

INP 不一樣。它量的是頁面整個生命週期裡，每一次互動的完整回應時間，然後取「最差的那次」（嚴格說是近似最大值，再取 p75）。換句話說，FID 是「起跑衝刺」，INP 是「全程不犯錯」。後者難太多了。這也是為什麼 INP 被稱為「新魔王」的原因，它把過去藏在地毯下的互動卡頓全翻了出來。INP 與 FID 的完整差異，可參考另一篇INP 取代 FID 的深度解析，這裡專注在「怎麼修」。

INP 卡頓的元兇，九成九是JavaScript 卡住了主執行緒（main thread）。瀏覽器是單執行緒跑 JS 的，當一段 JS 跑太久（超過 50 毫秒的任務叫 long task），使用者在這段期間的任何點擊、輸入都得排隊等它跑完。修 INP 的核心，就是想辦法讓主執行緒不要被綁架。

第一步：找出誰在霸佔主執行緒

打開 Chrome DevTools 的 Performance 面板，錄一段操作（點擊選單、送出表單），然後看 flame chart 裡那段長長的紅色長條，那就是 long task。常見的霸佔者有這幾類：

• 第三方追蹤碼（GA、Facebook Pixel、各種 retargeting tag）
• 廣告腳本（尤其 AMP 與 header bidding）
• 大型 SPA 框架的 hydration（如果用 React/Vue 做 SSR）
• 過多的 jQuery 動畫或頁面編輯器產生的肥大 JS

第二步：對症下藥

霸佔者類型	修法	預期效果
第三方追蹤碼	延後載入（defer/async）或用 Partytown 移到 worker 執行緒	INP 明顯下降
廣告腳本	限制 header bidding 數量、延後廣告載入到使用者捲動後	效果中等（廣告是收益，要取捨）
頁面編輯器肥大 JS	停用用不到的 widget、改用輕量主題或調整載入策略	效果看網站規模
未壓縮的 JS	啟用 minify、code splitting、移除沒用到的那一半	效果明顯

一個關鍵提醒：INP 是「互動後」的回應速度，不是「互動前」的載入速度。很多人把 INP 跟 LCP 搞混，以為裝個快取外掛就能修 INP，結果毫無效果。快取能幫 LCP（檔案送得快），但對 INP 幫助有限（因為 INP 卡的是使用者已經在你的頁面上點東西之後、瀏覽器跑 JS 的時間）。要修 INP，你得真的去看 JS，沒有捷徑。

CLS 攻略》那個讓人誤點廣告的瞬間，其實最好修

CLS 是三個指標裡相對好修的，但也是被忽略得最嚴重的一個，因為它的痛感是「隱性的」。LCP 慢，使用者會罵；INP 卡，使用者會煩；但 CLS 跳，使用者往往只是「皺個眉頭、不小心點到廣告」，然後默默離開，不會跟你反映。可這個「默默離開」會吃掉你的轉換率與排名。

CLS 的全名是 Cumulative Layout Shift，量的是頁面生命週期裡，所有「非預期」的視覺位移加總。注意「非預期」三個字：使用者主動觸發的捲動或縮放不算，只有那種「頁面自己跳」的位移才算分。修 CLS 的核心觀念只有一句話：每個會佔空間的元素，都要在它出現之前就先把自己的位置「預訂」好。

實作上，CLS 超標的元兇幾乎集中在這四類：

1. 圖片與影片沒設尺寸

這是最經典的 CLS 來源。當一張圖片沒有寫死 width 與 height，瀏覽器一開始不知道要幫它留多大的空間，就先不留；等圖片載下來了，才把下面的內容往下推。修法很無腦：給所有圖片、影片、iframe 都加上正確的尺寸屬性。現代瀏覽器會根據這組尺寸計算 aspect ratio，在圖還沒載入前就先佔好位置。

2. 動態注入的內容（廣告、彈窗、cookie 橫幅）

廣告載入後突然把內容往下推、cookie 同意橫幅從上面滑下來擠壓首屏、聊天機器人視窗彈出把按鈕蓋住，這些都是 CLS 殺手。修法是為這些動態內容預留固定空間：廣告欄位先留一個固定高度的 container、cookie 橫幅改成覆蓋在最上層而不擠動內容（用 overlay 而非 push）。

3. Web Fonts 造成的高度跳動（FOUT）

系統字先顯示、網頁字載好後切換，如果兩種字的寬高不同，整段文字的重排會造成 CLS。修法是設定 size-adjust、font-display: swap 搭配 fallback 字體的 metric 調校，或乾脆本機託管字體減少切換。

4. 非同步載入的嵌入內容（embed）

社群貼文嵌入、YouTube 影片、地圖 widget 這類東西，往往在主內容之後才載入，載入時把周圍擠開。修法跟圖片一樣：先給它一個固定尺寸的容器。

CLS 的修法可以用一個口訣總結：「還沒出現的東西，先佔好位置；會變大的東西，先留好空間。」這兩句話涵蓋了九成以上的 CLS 場景。CLS 通常不需要動到主機或架構，只要在 HTML 裡多寫幾個尺寸屬性、在 CSS 裡多留幾個 min-height，就能修到綠燈，CP 值非常高。

三個指標互相打架時，該聽誰的？

這一節也是整篇文章裡最少人講的主題。前面把 LCP、INP、CLS 分開講，好像它們各自獨立。但實戰裡，三個指標會互相牽制，你修好一個，常常會把另一個弄壞。如果你不知道這些 trade-off 存在，就會陷入「修一個、壞一個」的無限迴圈。

列出幾個最經典的衝突場景：

你想做的事	對誰有利	對誰有害	該怎麼解
對首屏以下圖片開 lazy loading	LCP（首屏更快）	CLS（圖載入時若無尺寸會推擠）	lazy load 同時補上 width/height
defer 所有 JS	LCP、INP（主執行緒更閒）	可能害互動功能延後啟動，體感變差	關鍵互動 JS 不要 defer，用 async 或 inline
載入更多第三方追蹤碼	（行銷數據）	INP（主執行緒被綁架）	用 Partytown 或延後載入，把行銷與體驗切割
廣告欄位留固定高度	CLS	（可能少賣一點廣告）	接受 trade-off，CLS 通常比多一格廣告值錢
用大尺寸 hero 圖提升質感	（視覺）	LCP（圖更大更慢）	用響應式 srcset，行動版給小圖

看出來了嗎？這些狀況很少是非黑即白的二選一，多半得同時做兩件事才能兩邊兼顧。lazy load 要配尺寸、defer 要分輕重、第三方要隔離。實戰裡，當你決定動一個東西時，腦袋裡一定要同時問：「這個改動會不會把其他兩個指標搞壞？」這個習慣一旦養成，你就不會再陷入「修一個壞一個」的迴圈。

衝突時的優先順序，實務上的判斷基準是：先修 CLS（最好修、影響最直接）、再修 LCP（CP 值高）、最後修 INP（最難、邊際效益最遞減）。這個順序背後的邏輯是「投入產出比」。CLS 修一次就穩了，LCP 改幾張圖就有感，INP 則要真的下去讀 JS 才動得了。當然，如果你的 CrUX 顯示某個指標特別糟（例如 INP 已經 600 毫秒），那就不管順序，先救那個紅燈。

更多關於網站速度的橫向知識，像是快取、壓縮、CDN 的整體策略，可以延伸閱讀這篇把網站速度做起來的方法，它跟本文是互補關係：那篇講「速度」這個大題目，本文專講 CWV 這三個指標。

WordPress 站長的 CWV 槓桿：主機、主題、外掛的真實影響

whoops.tw 的讀者有很大一部分是 WordPress 站長，所以這裡特別留一節講 WordPress 環境下的 CWV 槓桿。WP 的好處是生態成熟、幾乎每個 CWV 問題都有對應外掛能解；壞處是外掛裝太多本身就是 INP 殺手。這裡的關鍵是「用對工具，而不是用更多工具」。

主機層：被低估的單一槓桿

如果你的站還在跑最便宜的共享主機，TTFB 動輒 800 毫秒起跳，那不管你怎麼調外掛，LCP 都很難壓到 2.5 秒以下。主機是 CWV 的地基。升級到管理型 WordPress 主機或 VPS，往往是 LCP 一次到位的最有感的改動。選擇可以參考這篇雲端主機教學，它示範了從共享主機搬上雲端後，TTFB 與 LCP 的典型改善幅度。

主題層：肥大主題是原罪

有些「多功能主題」預載大量動畫、編輯器元件與字型選項，可能增加 JS、CSS 與 DOM 規模。選主題時不要只看品牌或宣稱的速度，要用實際頁面範本測量載入資源、LCP 與 INP；挑選方向可參考WordPress 主題推薦。

外掛層：快取與效能外掛是主力武器

快取與效能外掛可協助 page cache、延後腳本、lazy load 與字體優化，但每一項都要逐項測試，minify 或 defer 設錯也可能破壞版面與互動。選擇時可交叉參考快取外掛實測與WordPress 速度優化外掛推薦，不要同時疊加功能重複的工具。

外掛層的反面：裝太多就是自殺

這是 WordPress 站長最容易踩的雷。每一個外掛都會注入自己的 JS 與 CSS，每一個都是潛在的 INP 霸佔者。實務上常見不少站長一口氣裝了二十幾個外掛，然後抱怨 INP 修不起來。第一個該做的，是打開外掛清單，逐個問自己「這個外掛過去三個月用過嗎？沒用就刪。」這比再裝一個新外掛有效多了。光是瘦身外掛清單，INP 就能掉一大截。

圖片優化在 WP 環境下也有專門的外掛能自動處理壓縮、格式轉換與 lazy load，例如這篇WordPress 圖片優化指南與Smush 外掛教學，能幫你把 LCP 那張大圖自動顧好。這類自動化外掛對非技術站長特別友善，因為它把「手動改 HTML」變成「裝一次設定好就不用管」。

頁面編輯器的選擇也會影響 CWV。視覺化編輯器若產生過多 DOM 節點或載入未使用的 JS，可能拖慢 LCP 與 INP。重度依賴編輯器時，應停用未使用元件、按頁載入資源並實測變更；選擇工具可參考頁面編輯器比較。

CWV 優化的停止線：什麼時候該收手，別再追 100 分

PageSpeed 的效能分數是實驗室環境下的診斷摘要，不等於 CWV 實測狀態。把分數從 92 推到 97 是否值得，應看它修掉了什麼問題、真實使用者指標與轉換是否改善；不能只憑五分差距推論排名或轉換回報。

為什麼？因為 Google 的門檻是「分階」的，並非線性累加。它看的是你的 p75 落在哪一階（Good / Needs Improvement / Poor），分數本身的高低不是重點。一旦你進了 Good 區間，你在這一階裡是第一名還是最後一名，對排名幾乎沒有差別。這就像考駕照，60 分及格拿到駕照，你考 95 分也不會比 60 分的人多一條車道可以開。

一條實用的停止線是：CrUX 的三個指標在主要頁面群組都穩定落在 Good，且沒有轉換、錯誤率或無障礙問題需要繼續處理，就把工程資源轉向更高優先事項。CrUX 報表使用 28 天滾動資料，這是量測視窗，不是「連續 28 天全綠就一定該停」的排名規則。

這也是為什麼 SEO 可以用「存錢而非花錢」來理解。CWV 是「補漏」，你把破洞補上，錢就不會再漏；但補完洞之後，要變有錢靠的是繼續存（內容與權威），不是把同一個洞補得更漂亮。理解這一點，你就不會在「追求滿分」的陷阱裡打轉。

當然，停止線有兩個例外。第一，如果你是電商網站，轉換率對互動流暢度極度敏感，即便 INP 已經在 Good，進一步壓低對結帳轉換可能還是有感，這時可以繼續微調。第二，如果你的 CWV 是「勉強壓線」（例如 LCP 剛好 2.4 秒），那它很容易在網路波動或新版外掛推出時掉回紅區，這種壓線狀態不算「穩定 Good」，還是要再往下修一點當緩衝。

AI 爬蟲與 Agent 也需要可存取的頁面，但別跟 CWV 畫上等號

AI 爬蟲與能操作網頁的代理也受頁面效能、語意結構與互動設計影響，但目前沒有官方依據顯示它們會直接使用網站的 CWV 分數決定是否抓取或引用。以下比較適合當成可存取性與穩健性的工程檢查，不是新增的排名聲稱。

搜尋與 AI 服務可能透過不同類型的自動程式存取網站，例如用於訓練的 GPTBot、用於搜尋索引的 OAI-SearchBot，以及使用者觸發的代理請求；各家用途與 robots token 不完全相同，可透過伺服器日誌分析 AI 爬蟲並回查官方文件。另一類 agentic browsing 工具則可能在使用者授權下操作頁面，例如展開選單、載入內容或填寫表單；相關設計議題可參考AI Agent 瀏覽時代。

這件事與一般效能和可存取性的關係，可以這樣檢查：

• 伺服器回應與內容輸出，應避免逾時、錯誤或把主要內容完全綁在脆弱的前端流程上。這有助於各類爬蟲取得內容，但不能由 LCP 分數推論是否會被引用。
• 互動元件，應提供清楚的 HTML 結構、鍵盤操作與可預期的狀態。這對真人與自動化工具都有幫助，但 INP 不是 AI 代理的公開採用指標。
• 視覺穩定度，能降低版面移動造成的誤操作。這是介面品質問題，不能直接推導為 AI 搜尋訊號。

換句話說，修正逾時、錯誤與難以操作的元件，主要收益仍是更穩定的真人體驗；同樣的工程品質也可能讓自動化工具更容易操作頁面。這是可存取性層面的合理推論，不等於修好 CWV 就能提高 AI 引用機率。

不過要誠實提醒：AI 爬蟲目前對 CWV 的「直接評分」機制，還沒有像 Google 排名那樣有公開、穩定的文件佐證。這裡談的是根據爬蟲行為特性推導出的合理判斷，官方並未證實這是一條演算法權重。把它當成修 CWV 的額外動機就好，別過度延伸成「修好 CWV 就會被 ChatGPT 引用」這種保證。想系統性理解傳統搜尋排名的全貌，這篇SEO 完整指南跟Google 演算法全解析可以一起看；想搞懂更廣的技術面，這篇技術性 SEO 指南是好的入口。

六步行動方案：從今天開始的 Core Web Vitals 衝刺

講了這麼多，給你一個可以直接照做的行動方案。這六步是 CWV 健檢的標準流程，按順序做下來，通常能在兩到四週內把紅燈轉綠。

1. 連上 GSC，定位問題頁。打開 Google Search Console 的「網頁體驗」報表，匯出所有 CWV 不及格的 URL，優先處理流量高、排名接近第一頁的那些。別從流量最低的頁面開始修，那是浪費力氣。
2. 分清楚 CrUX 與 Lighthouse。對每個問題頁，先確認 CrUX 的實測數字（這才是排名看的），再用 PageSpeed Insights 的 Lab 區塊定位 root cause。記住：Lab 是診斷，不是評分。
3. 對症下藥修 CLS。檢查所有圖片、影片、iframe 有沒有設尺寸，檢查廣告與 cookie 橫幅有沒有預留空間。CLS 是 CP 值最高的修法，通常一天內能全綠。
4. 對症下藥修 LCP。找出每個頁面的 LCP 元素，依「元素 → 檔案 → 伺服器」三層順序診斷。圖片先換 WebP/AVIF 再壓縮，首屏圖加 fetchpriority="high" 且不要 lazy load，字體改本機託管，最後才考慮主機與快取。
5. 對症下藥修 INP。用 DevTools Performance 找 long task，最常見的元兇是第三方腳本與過多外掛。延後或隔離第三方追蹤碼、刪除用不到的外掛、minify 與 split JS。INP 最難修，但只要主執行緒空出來，效果立現。
6. 等 28 天，驗證再收手。修完之後，等 CrUX 資料累積一個週期，確認三個指標都穩定進入 Good。一旦穩定，就停止 CWV 優化，把資源轉到內容深度、站內 SEO、與站外權威建設。那才是排名真正的戰場。

CWV 是基本功，不是選配，這句話值得反覆強調。一個會卡、會跳、會讓人等的網站，再好的內容也會被打折。但反過來說，CWV 也只是基本功，修好它不會讓你一夕登頂，它只是幫你把「不該丟的分數」拿回來。真正決定排名高度的，永遠是你能不能為搜尋者提供別人給不了的價值，以及你有沒有用對的方法讓 Google 看懂這份價值。

現在，打開你的 Google Search Console，去看看你的網頁體驗報表吧。那些紅燈，就是你的網站今天最該修的地方。把基本功補起來，你才有力氣去打真正的仗。