Core Web Vitals 欄位資料是什麼？CrUX 機制、差距原因與 GSC 數據更新完整指南
之前碰到一個電商客戶，GSC 的 Core Web Vitals 報告整片紅燈，但他們工程師用 PageSpeed Insights (PSI) 跑出來的分數卻是綠色的。第一反應往往是「Google 的工具是不是出包了？」但更常見的真相是：你用錯了指標在診斷問題。這篇文章就是來徹底釐清「欄位資料」是什麼、它從哪裡來、為什麼跟你手上的 Lighthouse 分數不一樣，以及當數據看起來不對勁時，你第一步該點開哪個工具。
你的 GSC 欄位資料亮紅燈，但 PageSpeed 分數是綠的？第一步先做這個
當你看到 GSC 的核心網頁動態報告出現紅色或橘色警示，但 PSI 分數卻顯示綠色時，不要急著懷疑數據。第一步是打開 GSC 的「網址審查」工具。具體操作路徑是：進入 Google Search Console → 左側選單點擊「網址審查」→ 輸入那個亮紅燈的具體網址 → 點擊「審查」。這份報告會直接顯示 Google 對該網址收集到的「欄位資料」狀態與樣本數，這是你判斷問題真實性與嚴重程度的最快起點。網址審查工具能告訴你，這個網址是因為真實用戶體驗數據不足（樣本數不夠）而顯示紅燈，還是其 CrUX 數據確實達到了「不良」的門檻。
欄位資料 vs. 實驗室資料：CrUX 機制與為何產生落差
欄位資料（Field Data）來自 CrUX (Chrome User Experience Report)，是 Google 從真實 Chrome 瀏覽器（在用戶同意的前提下）收集的使用者體驗數據，並以第 75 百分位數（P75）作為報告標準；實驗室資料（Lab Data）則是 Lighthouse 在受控的模擬環境中執行的單次測試。落差根源於：真實網路環境（如台灣中華電信或遠傳電信的 4G/5G 訊號波動）與裝置效能（如平價 Android 手機的處理能力）的極大多樣性、CrUX 的資料收集週期（28 天滾動視窗）與最低樣本數要求。具體來說，Lighthouse 模擬的是一台假設的中階設備在穩定的慢速網路上的表現，而 CrUX 則囊括了從高階旗艦機到入門款手機、從穩定 WiFi 到波動行動網路的所有真實用戶行為分布。
當 GSC 資料不足或為零時，有哪些工具可以取得更深入的欄位資料？
四種主要工具，依需求選擇：1) GSC「網址審查」(單網址快速診斷，查看 CrUX 狀態)；2) PageSpeed Insights (結合實驗室測試與 CrUX 報告，是觀察趨勢的快速窗口)；3) CrUX API (透過 BigQuery 或直接呼叫，適合程式化批量查詢大樣本數據)；4) 瀏覽器開發者工具 (Network 和 Performance 面板，可即時觀察單次頁面載入的真實效能指標)。選擇時請記住：GSC 和 PSI 是每日更新的監控工具，而 CrUX API（透過 BigQuery）通常提供的是每月匯整的歷史數據。當你的頁面流量不足以觸發 URL 層級的 CrUX 資料時，PSI 上方會顯示「Origin Summary」，這代表你可以先從整站（網域）的聚合數據來判斷整體健康狀態。
台灣站長特別注意：本地網路與裝置環境如何影響你的 CrUX 資料
GSC 欄位資料多久更新一次？如何解讀更新週期與資料延遲
GSC 的核心網頁動態報告中的欄位資料（基於 CrUX）通常每日更新，但其展示的數據是過去 28 天的滾動平均值。這意味著，你今天完成的優化不會立刻反映在報告中。改善是漸進式出現的：新一天的良好數據會逐步替換掉滾動視窗中 28 天前的舊數據。因此，如果你在 6 月 1 日修好了 LCP 問題，可能要到 6 月中旬才能在 GSC 中看到指標從紅轉橘，並在 6 月底左右才可能完全轉綠（假設修復有效且新樣本持續良好）。管理對此的預期很重要，不要因為隔週看 GSC 數據未變就認為優化無效。此時，應使用 PSI 每週記錄同頁面的 75th percentile 數值趨勢來驗證優化方向。
從發現到解決：完整診斷思維鏈與下一步行動
讓我們串聯一個完整流程：假設你收到 GSC 警報，某個重要產品頁的 INP 指標為「不良」。第一步，使用「網址審查」確認該網址的 CrUX 資料樣本數是否充足，以及具體的 P75 INP 數值。第二步，用 PSI 分別在「手機」與「桌面」模式下測試該頁面，觀察實驗室數據的 INP 分數與具體建議，並在 Performance 面板錄製一次互動操作，查看究竟是哪個 JavaScript 執行緒阻塞了互動響應。第三步，分析是否為台灣市場常見的裝置環境問題（例如，腳本在低階手機 CPU 上執行過慢）。第四步，決定行動：若是具體腳本問題，則優化代碼並部署；若是因流量或環境導致樣本不足，則可考慮透過 CrUX API 設定更長期的監測，並在優化後持續用 PSI 追蹤趨勢。問題的根源往往在於混淆了不同數據的意義，這步驟不能跳過。
常見問題
GSC 的核心網頁動態報告顯示「0 個網址」的資料，是有問題嗎？
這通常不代表你的網站有性能問題，而是流量門檻問題。CrUX 要求一個網址在 28 天內被足夠多的 Chrome 用戶瀏覽，才會產生 URL 層級的欄位資料。這可能因為你的網站剛上線、該頁面訪問量低，或是流量分散在許多不同網址。此時，你應該在 PSI 中查看「Origin Summary」（網域層級資料）來了解整站概況，並可使用「網址審查」工具確認特定網址的 CrUX 狀態。
為什麼我的 LCP 在 PageSpeed Insights 是綠的，GSC 卻是紅的？
因為兩者衡量的是完全不同的東西。PageSpeed Insights 下半部顯示的綠色分數來自 Lighthouse（實驗室資料），是模擬一次測試的結果。GSC 紅燈則來自 CrUX（欄位資料），反映真實用戶在過去 28 天的體驗分布。差距通常源於真實用戶的網路環境（如行動網路延遲）比 Lighthouse 模擬的更差，或你的主要用戶使用效能更低的設備。具體的差異分析可參考關於 LCP 最大內容繪製的說明。
手機版和桌面版的欄位資料是分開的嗎？我該優化哪一個？
是的，CrUX 和 GSC 都分別提供手機與桌面的數據。由於 Google 採用「行動裝置優先索引」，其排名主要依據手機版頁面的體驗。因此，你應該優先處理手機版的 Core Web Vitals 問題。通常手機版的指標更難達到「良好」，因為手機設備效能與網路條件的差異性更大。
我改了頁面後，PSI 的分數變好了，但 GSC 資料還是差，要等多久？
需要等待。這是正常現象。GSC 顯示的 CrUX 資料是 28 天的滾動視窗。你今天的修復，其產生的優質用戶數據會從明天開始逐步進入滾動視窗，但同時舊的數據也需要時間被移出。完全反映可能需要長達 28 天。在此期間，你可以用 PSI 每週追蹤同一網址的 75th percentile 數值（例如 LCP），只要趨勢是下降的，就代表你的優化方向正確。更多關於三大指標的細節，可參閱 Core Web Vitals 三個指標說明。
欄位資料達到了「良好」，但我的競品 Lab 分數比我高，這會影響排名嗎？
不會。Google 排名所使用的頁面體驗信號，依據的是「欄位資料」（CrUX），而不是 Lighthouse 的實驗室分數。你的欄位資料達標，代表排名信號已經合格。競品的 Lab 分數高低與排名信號無關。頁面體驗信號在排名中扮演的是「平局打破者」的角色，當內容品質相近時，更好的 CWV 會帶來優勢。
CrUX API 怎麼用？需要費用嗎？
CrUX API 本身免費，但需要一個 Google Cloud 帳號和 API 金鑰來呼叫。它提供 JSON 格式的回應，包含指定網址或網域的 75th percentile 數值。對於需要批量監控大量頁面，或是希望將數據納入自動化報表與告警系統的進階用戶，CrUX API 是比手動查看 GSC 或 PSI 更有效率的選擇。你可以透過 BigQuery 查詢公開的 CrUX 資料集，進行更靈活的歷史趨勢分析。