Web Vitals Chrome Extension 還能用嗎？2026 改用 DevTools 測 LCP、INP、CLS
Web Vitals Chrome Extension 已結束官方支援，核心功能已併入 Chrome DevTools。本文用工程實測流程說明 2026 年如何監測 LCP、INP、CLS，並比較 DevTools、PageSpeed Insights、CrUX 與第三方 extension 的使用邊界。
陳柏翰
網站效能工程師
先講結論：官方 Web Vitals Chrome Extension 已經不該當主工具
官方 Web Vitals Chrome Extension 的支援已結束。Google Chrome 團隊在 2024 年 9 月宣布，extension 的即時監測功能已完整移入 Chrome DevTools Performance panel，並在後續版本中正式停止維護舊 extension。這個決策來自 Chrome Developers 的官方支援結束公告，說明 DevTools Performance panel 已完整接手 extension 的所有核心功能。2026 年你如果打開 Chrome Web Store 還能找到標示「Web Vitals」的 extension，大概率是第三方開發者發布的工具，不是 Google 官方延伸程式。
這件事對工作流的影響很直接：以前靠 extension 的人，現在改開 DevTools 的 Performance panel 就好。指標數值一樣在，解讀方式一樣，但不需要再裝任何外掛。
如果你的同事還在說「裝 Web Vitals extension 來測一下」，先確認他說的是哪個。官方工具已移進 Chrome 內建功能，而第三方同名 extension 的品質差距相當大，不能直接畫上等號。
| 工具 | 目前狀態 | 在哪裡找 |
|---|---|---|
| Google 官方 Web Vitals extension | 支援已結束，功能移入 DevTools | 不再作為獨立 extension 維護 |
| Chrome DevTools Performance panel | 現行官方工具，持續更新 | Chrome 內建，F12 開啟 |
| 第三方 Web Vitals extension | 各自獨立維護，品質不一 | Chrome Web Store |
延伸閱讀：Core Web Vitals 三個核心指標：LCP、INP、CLS 完整解析
現在要怎麼測：Chrome DevTools 即時 Core Web Vitals 流程
Chrome DevTools Performance panel 從 2024 年 9 月起提供即時 Core Web Vitals 監測，開啟後不需要任何錄製操作就能看到 LCP、INP、CLS 數值。這個功能是官方 extension 關閉前所有功能的直接繼承者，原理一樣是在本機瀏覽器中追蹤 LCP 元素載入、INP 輸入回應時間與版面位移累積量。
以下是我測試一個頁面的標準五步流程：
- 開啟 Performance panel：按 F12 或 Ctrl+Shift+I 開 DevTools，點 Performance 分頁。面板頂端區塊會顯示 Local metrics。
- 重新整理頁面：按 Ctrl+Shift+R 做強制重整，讓 LCP 計算從頭開始。此時 LCP 指標會在頁面完成渲染後更新。
- 做真實互動：點擊頁面上的按鈕、展開折疊區塊、填寫表單。每次互動都會記錄到 Interactions log，INP 會即時更新。
- 記錄 LCP、INP、CLS 與觸發元素：面板會標示 LCP element 的連結，點擊可直接跳到 Elements panel 定位元素。
- 對照 Field data：若頁面有足夠 CrUX 資料，Performance panel 右側會顯示真實使用者的 p75 數值，讓你判斷本機結果是否代表大部分使用者的體驗。
注意：DevTools 測到的是這台裝置、這個網路、這個快取狀態下的體驗。如果結果比 PageSpeed Insights 好太多，先確認有沒有用網路節流，以及頁面是否有登入快取。CPU throttle 設定在效能差的裝置模擬上也很關鍵，4x 通常適合 mid-range Android，20x 才能模擬入門機。
相關閱讀：Chrome DevTools Performance 面板怎麼看：從 trace 找出 LCP、INP 與 JavaScript 瓶頸
Extension、DevTools、PSI、CrUX 差在哪？不要把四種數字混著看
DevTools 和 extension 測的是本機這一次的即時體驗，PageSpeed Insights 同時提供 Lighthouse lab diagnostics 與 CrUX 聚合的 field data，CrUX Vis 適合看真實使用者的歷史趨勢。把這四個工具的數字拿來互相驗證是正確的，但把它們的數字直接比較是錯誤的。
| 工具 | 資料類型 | 最適合做什麼 | 不應該拿來做什麼 |
|---|---|---|---|
| Chrome DevTools Performance panel | 本機即時 lab data | 定位本機可重現的 LCP、INP、CLS 瓶頸；查 LCP element、INP 慢在哪一段 | 代表所有真實使用者的體驗；當作 SEO 排名判斷依據 |
| Web Vitals 第三方 extension | 本機即時 lab data（視實作而定） | 快篩當前頁面是否有明顯問題 | 取代 DevTools 的詳細診斷；比較不同頁面間的結果 |
| PageSpeed Insights (PSI) | CrUX field data + Lighthouse lab run | 快速看某個 URL 的真實使用者體驗 + 診斷建議 | 精確追蹤每次部署後的細微改動；代表本機即時行為 |
| CrUX Vis | CrUX 歷史 field data | 看 28 天滾動的真實使用者趨勢；比較 origin 與 URL 的差異 | 定位具體的 HTML 元素或程式碼瓶頸 |
| web-vitals JavaScript library | 產品內 RUM（真實使用者監測） | 收集自家使用者的 LCP、INP、CLS 事件，送到 Analytics 或自訂 endpoint | 事前診斷（沒有使用者就沒有資料） |
SpeedPark 的做法是先用 DevTools 抓原因，再用 PSI 確認這個問題在真實使用者身上是否存在，最後用 CrUX Vis 追趨勢。如果三者指向同一個問題，優先處理的把握很高；如果只有 DevTools 顯示紅字但 CrUX 是綠色，可能只是你的測試環境不具代表性。
相關閱讀：PageSpeed Insights 分數為何每次都不一樣？Lab Data 和 Field Data 的差距說清楚
LCP、INP、CLS 在 DevTools 裡看到紅色，要先查哪裡？
LCP 紅字先查最大可視元素與資源載入；INP 紅字先查互動後的 main thread blocking；CLS 紅字先查無尺寸圖片、字體切換與插入式內容。每個指標的瓶頸模式不同，在 DevTools 裡找的地方也不同。
LCP 紅字（超過 2.5s）
Performance panel 的 Local metrics 區塊會直接標示 LCP element。點擊連結跳到 Elements panel，確認這個元素是圖片還是文字，然後回到 Network 面板找它的資源載入時間。
| 要先看的 | 要先改的 | 不要先做的 |
|---|---|---|
| LCP element 是什麼、它的資源從什麼時候開始載 | LCP 圖片加 fetchpriority="high"；確保圖片不被 lazy load | 全站壓縮圖片、全站改 WebP（先確認是不是這張圖的問題） |
INP 紅字（超過 200ms）
Performance panel 的 Interactions log 會顯示每次互動的延遲時間與觸發元素。找到最慢的互動，點擊 interaction target 定位元素，再按 Record 錄製一次 Performance trace，找到互動後緊接的 Long Task。
| 要先看的 | 要先改的 | 不要先做的 |
|---|---|---|
| Interactions log 最慢那筆；對應的 JavaScript function 名稱 | 把 Long Task 拆成小任務（scheduler API）；把第三方腳本移出事件處理鏈 | 把所有 click handler 都換成 async（不知道瓶頸在哪就亂動） |
CLS 紅字（超過 0.1）
CLS 比較難在 DevTools 裡精確定位，但 Performance panel 的 Local metrics 區塊會顯示目前累積的 CLS 值。錄製一次 performance trace 後，在 timeline 找到 Layout shift 區塊，展開可以看到是哪些元素在偏移。
| 要先看的 | 要先改的 | 不要先做的 |
|---|---|---|
| Layout shift 發生的時間點（載入時還是互動後）；偏移元素 | 圖片加 width/height 屬性；廣告和嵌入欄位保留空間（aspect-ratio 或 min-height） | 把全站圖片都加 aspect-ratio（先確認是哪張圖在動） |
延伸閱讀：LCP 優化實戰：四段時間模型幫你找到瓶頸，不再亂猜改哪裡
延伸閱讀：INP 優化：診斷主執行緒瓶頸並壓低互動延遲的工程師指南
我會怎麼跑一次實驗：baseline、單一變因、rerun
有效的 Web Vitals 測試不是看一次分數，而是先記 baseline，只改一個變因，再用同樣條件重跑，最後比較 LCP、INP、CLS 是否真的改善。這個做法在任何測量工具下都成立，不管你用 DevTools、PSI、Lighthouse 還是 WebPageTest。
我遇過一個常見錯誤：工程師在部署新版本後立刻跑 PSI，看到分數上升就宣告優化成功。但這個分數對比的是 CrUX 的 28 天滾動資料，新版本的影響要 2-4 週後才會完全反映。真正的前後對比要在 DevTools 裡用相同的節流設定，跑完 baseline 才能再跑優化後。
以下是一個典型電商首頁的示範測試記錄（示範數字，測試環境：MacBook Pro M2、Chrome 130、CPU 4x 節流、Slow 4G 節流，實際數字依站點而異）：
| 指標 | 改動前（baseline） | 改動後（rerun） | 變化 |
|---|---|---|---|
| LCP | 3.9s | 2.2s | -1.7s（-44%） |
| INP | 280ms | 160ms | -120ms（-43%） |
| CLS | 0.18 | 0.04 | -0.14（hero image 加了尺寸屬性） |
同一個改動在 PSI 上的 CrUX 數字要過幾週才能對應改善。這是為什麼工程師不能只靠 PSI 的 field data 來判斷部署效果。如果你需要快速驗證，DevTools 的 local measurement 是唯一能在部署當下告訴你「這個改動方向是否正確」的工具。
實驗規則：同一台機器、同一個 Chrome profile（清除快取）、相同節流設定、每個條件跑三次取中位數。一次測量的結果不要當成結論。
為什麼你的 extension 數字和 PageSpeed Insights 不一樣？
extension 或 DevTools 測的是當下這台瀏覽器的體驗，PageSpeed Insights 還可能顯示 CrUX 聚合資料；裝置、網路、快取、使用者互動和資料時間窗不同，數字本來就不會完全一樣。這不是任何工具的錯，是它們設計上服務不同問題。
具體造成差距的原因包括：
- 本機快取：你測試時頁面資源可能已快取，第一次訪客沒有。
- 裝置硬體：你的 MacBook Pro M2 的 CPU 遠快於大多數真實使用者的中階 Android。
- 網路條件：沒有節流的本機 WiFi 和真實使用者的 4G 載入時間差距可以是 2-5 倍。
- 互動模式：INP 是最大互動延遲，你的測試互動可能沒有觸發最慢的路徑。
- CrUX 時間窗：PSI 顯示的 field data 是過去 28 天真實使用者的 p75，不是今天你一個人跑的結果。
- URL vs Origin：PSI 有時顯示的是 origin（整個域名）的聚合資料而非單一 URL，尤其當 URL 流量不足時。
遇到「extension 綠色但 PSI 紅色」的情況，通常是你的本機環境太理想。建議先在 DevTools 開 CPU 4x 節流 + Slow 4G，跑一次，再看結果是否更接近 PSI 的 field data。
深入解析這個問題，可以看：PageSpeed Insights 分數為何每次都不一樣？Lab Data 和 Field Data 的差距說清楚
第三方 Web Vitals Chrome Extension 可以裝嗎？先看這 7 件事
第三方 Web Vitals extension 可以作快篩，但安裝前要先確認 7 個項目。Chrome Web Store 現在仍有多個標示「Web Vitals」的第三方 extension，品質和資料來源差距很大，不能只靠名稱判斷。
- 開發者身份：是否有可查核的組織或開發者名稱？是否是 Google Chrome 團隊發布？（現在應該沒有 Google 官方的了）
- 所需權限：extension 要求哪些 Chrome 權限？需要讀取所有網頁內容的 extension 風險較高。
- 最後更新日期：超過 2 年沒有更新的 extension 可能不支援 INP（2024 年才取代 FID）。
- 資料來源：extension 顯示的是本機計算的 metrics，還是從 CrUX / PSI API 抓的？這兩個是完全不同的東西。
- 隱私揭露：extension 是否聲明不上傳或不蒐集頁面內容？
- 指標清單：extension 顯示哪些指標？是 LCP、INP、CLS 三個，還是只有舊版的 FID？
- 是否可解釋計算方式：能看到 LCP element 是哪個、INP 對應哪個互動嗎？只顯示數字但沒有 debug 入口的 extension，對修復沒有幫助。
如果上面 7 點有任何一點不通過，建議放棄這個 extension，直接改用 DevTools，功能更完整而且沒有安全疑慮。
如果你要長期監測，不要靠 extension，改用 web-vitals library 或 RUM
Chrome extension 適合除錯，不適合長期監測。要追蹤真實使用者的 LCP、INP、CLS 趨勢，應把 web-vitals library 接到 analytics 或 RUM pipeline，再用 CrUX 或 PSI 做外部校準。extension 只能告訴你你自己測試時的數字，不能告訴你昨天有多少比例的使用者碰到了 INP 超過 200ms 的互動。
最快的做法是加入 web-vitals JavaScript library，把三個指標送到 Google Analytics 4。概念上只需要這樣：
<script type="module">
import {onCLS, onINP, onLCP} from 'https://unpkg.com/web-vitals@4?module';
function sendToGA({name, delta, id}) {
gtag('event', name, {
event_category: 'Web Vitals',
value: Math.round(name === 'CLS' ? delta * 1000 : delta),
event_label: id,
non_interaction: true,
});
}
onCLS(sendToGA);
onINP(sendToGA);
onLCP(sendToGA);
</script>這段 code 在瀏覽器端偵測真實使用者的 LCP、INP、CLS，並在每次頁面關閉前送出事件到 GA4。事件送出後，可以在 GA4 的 Events 報表看到發生次數，但要計算 p75 或中位數需要透過 GA4 Exploration、BigQuery 匯出或自訂 RUM dashboard 來做進一步分析，GA4 標準報表不會直接顯示百分位數。
注意幾個限制：
- 需要有流量才有資料，小站的資料量可能不夠切分到 URL 層級。
- INP 只有在使用者真的做了互動後才有值，頁面瀏覽量不等於 INP 資料量。
- GA4 的資料取樣在高流量下可能影響準確度，如果需要原始資料，考慮送到自家 endpoint。
外部資料可以參考：Measure a web page's Core Web Vitals with the web-vitals library（Google Codelabs）
2026 的建議工具組合：我會這樣分工
2026 年的實務分工是：DevTools 查本機原因，PSI 快速看 URL field/lab 狀態，CrUX Vis 看歷史趨勢，WebPageTest 看網路瀑布，web-vitals library 收產品內 RUM。不需要追求一個工具解決全部問題，這些工具回答的問題本來就不同。
| 工具 | 問的問題 | 使用時機 | 需要安裝？ |
|---|---|---|---|
| Chrome DevTools Performance panel | 這個頁面本機的 LCP/INP/CLS 原因是什麼？ | 每次部署後、定位瓶頸時、調整節流設定時 | 否（Chrome 內建） |
| PageSpeed Insights | 這個 URL 的真實使用者現況如何？Lighthouse 建議什麼？ | 部署後外部確認；快速產出診斷報告 | 否（web 工具） |
| CrUX Vis | 過去 28 天的真實使用者趨勢如何？Origin vs URL 差多少？ | 追蹤優化效果；看節日/促銷期的 CWV 變化 | 否（web 工具） |
| WebPageTest | 網路瀑布圖；不同地點、裝置的載入行為 | 深度分析 TTFB、資源載入順序、第三方腳本 | 否（web 工具） |
| web-vitals library + GA4 / RUM | 產品裡真實使用者的 LCP/INP/CLS 數字是多少？ | 長期追蹤；按頁面、裝置、地區分析 | 是（前端加入 JS） |
| 第三方 Web Vitals extension | 快篩這個頁面目前有沒有明顯問題 | 快速掃描時（確認來源後） | 是（但非必要） |
更多工具比較資源：
FAQ：Web Vitals Chrome Extension 常見問題
官方 Web Vitals Chrome Extension 已於 2024 年結束支援，功能移入 Chrome DevTools。第三方同名 extension 不是 Google 官方工具。extension 或 DevTools 的本機數字不影響 SEO 排名，Google 使用 CrUX field data 評估 Core Web Vitals。Search Console 的報表需要 2-4 週才能反映最新優化效果。
官方 Web Vitals Chrome Extension 已經停止支援了嗎？
是的。Google Chrome 團隊在 2024 年宣布官方 Web Vitals extension 的支援結束，即時 Core Web Vitals 監測功能已完整移入 Chrome DevTools Performance panel。2026 年起應以 DevTools 取代舊 extension 作為本機診斷入口。
Chrome Web Store 還有 Web Vitals extension，那是官方的嗎？
不是。官方工具已移入 DevTools，Chrome Web Store 現在的 Web Vitals 類 extension 都是第三方開發者發布的工具。使用前應確認開發者身份、所需權限與資料來源，不能假設等同官方工具。
extension 或 DevTools 顯示的分數，會影響 Google 的 SEO 排名嗎？
不會。本機 extension 或 DevTools 的數字只是你自己的體驗，不會被 Google 用於評估 Core Web Vitals 排名信號。Google 使用 CrUX 收集的真實使用者 field data，以 28 天滾動的 p75 數值作為 Core Web Vitals 評估依據。頁面體驗是排名相關信號之一，但不是唯一因素，本機測試的數字不構成任何排名依據。
為什麼 Search Console 的 Core Web Vitals 報表還是顯示「需要改善」，但 PSI 看起來是綠色？
Search Console 顯示的是 origin 或 URL 在 28 天 CrUX 資料中的狀態，改善後需要 2-4 週才會反映。PSI 也是查同一份 CrUX 資料，若 PSI 是綠色但 Search Console 還是紅色，通常是最近剛部署改動，CrUX 資料還在更新中。等幾週再看。
Mac 和 Windows 的測試結果不一樣是正常的嗎？
正常。CPU 效能、繪圖引擎、字體渲染方式都不同，即使是同一個頁面，Mac M2 上的本機 LCP 可能比 Windows mid-range 機快 30-50%。要讓結果更接近真實使用者，在 DevTools 開 CPU throttle，而不是只看本機裸跑的數字。
舊的 Web Vitals extension 還裝著，要移除嗎？
建議移除。支援已結束的 extension 不再更新，表示它的指標計算可能沒有跟上 INP 取代 FID 的規範修訂，顯示的數字可能誤導判斷。移除後改用 DevTools Performance panel，資訊更完整且沒有相容性問題。
CrUX Vis 和 Search Console 的 Core Web Vitals 報表顯示的資料來源一樣嗎？
是同一份 CrUX 資料，但呈現方式不同。Search Console 以「通過 / 需要改善 / 較差」的分類顯示受影響 URL 數量；CrUX Vis 以時間序列趨勢圖顯示各指標的 p75 變化，更適合追蹤優化前後的長期趨勢。