GSC 的 Core Web Vitals 報表，到底在顯示什麼？
打開 Google Search Console，在左側選單的「成效」段落下，找到「Core Web Vitals」，你看到的就是這份報表。它顯示的不是實驗室裡模擬的分數，而是你網站所有使用 Chrome 瀏覽器的真實訪客，在他們自己的網路環境和裝置上，實際感受到的頁面載入與互動體驗。報表依據三大核心指標：LCP（最大內容繪製）衡量主要內容的載入速度，INP（互動到下一次繪製）衡量頁面對點擊或按鍵等互動的回應速度，CLS（累積版面位移）衡量頁面在載入過程中版面的穩定程度。系統會根據這三個指標的表現，將你的網址分為「良好」、「待改善」或「較差」三種狀態。
這份報表的數據來源是 Chrome 使用者體驗報告（CrUX），它收集的是真實用戶的「欄位資料」。這代表你在辦公室用高速網路測出來的分數，可能和報表上顯示的狀態天差地遠。舉例來說，台灣用戶常使用公共 Wi-Fi 或訊號不穩的行動網路，這些環境下的頁面載入體驗，會真實地反映在 CrUX 數據中，而這往往是造成 LCP 超標的常見原因。很多網站在台灣使用特定的外掛或版型時，容易因為載入未經優化的大型圖檔或執行過多腳本，導致在真實環境下 LCP 值飆高。
3 個步驟，解讀你的報表並找出問題根源
第一步，進入 GSC 左側選單的「成效」，然後點擊「核心網頁指標」。第二步，你會看到頂部有「手機」與「電腦」兩個分頁，請務必先從「手機」分頁開始，因為 Google 主要依據行動版網頁內容進行排名。第三步，觀察每個分頁下的「使用者體驗不佳的連結」數量，這是問題嚴重性的直接指標。點擊數字後，你會看到具體的 URL 群組列表，這些就是你最該關注的問題頁面。
進入特定指標（例如 LCP）的問題詳情頁後，你會看到一個按狀態分類的表格。這裡要特別注意圖表與表格數字的差異：圖表通常按網址計算（一個網址只算一次），而表格按問題計算（同一網址若有多項指標不合格，會被重複計算）。所以當你看到圖表說「50 個網址狀態不佳」，但表格顯示「120 個問題」時，這不是系統錯誤。這表示有些頁面同時存在 LCP 與 CLS 等多重問題。你需要點擊具體的「網址群組」連結，才能看到受影響的實際頁面列表。
修復從哪裡開始？依據這 2 個原則決定優先順序
在「較差」的群組中，進一步查看哪個指標的「不合格」比例最高。例如，如果一個 URL 群組有 80% 的問題來自 LCP，那就集中火力解決 LCP 問題，不要同時分心去調整 CLS。很多時候，一個根本原因會拖垮大量頁面。以台灣常見的電商網站為例，很多問題根源於未設定尺寸的橫幅廣告或彈出式視窗，這會直接造成 CLS 版面位移；或是使用了未經壓縮的產品主圖，導致 LCP 過高。先解決那個導致最多頁面「不合格」的單一問題，往往能收到最大的改善效果。
從指標紅燈到具體優化：下一步該做什麼？
當你確定 LCP 是主要問題後，優化的方向通常聚焦於兩點：減少伺服器回應時間與優化最大內容元素的載入。伺服器回應時間可能涉及主機方案選擇或快取設定，而最大內容元素通常是圖片。此時，你可以查閱 LCP 優化指南，裡面有針對圖片載入、字型阻塞等問題的具體解決步驟。如果主要問題是 INP，代表頁面互動回應慢，這通常與 JavaScript 執行效率有關，尤其是大量使用第三方腳本（如分析工具、行銷追蹤碼）時，它們會阻塞主線程，詳見 INP 優化指南。若問題出在 CLS，則需排查未預留空間的廣告、動態插入的內容或版型元件，CLS 版面位移優化 提供了系統性的檢查清單。
優化之後，怎麼知道有沒有用？
在你完成技術優化並部署後，下一步是驗證效果。直接在 GSC 的 Core Web Vitals 報表中，點進你剛修好的那個 URL 群組詳情頁，在頁面右上角會有一個「開始追蹤」按鈕。按下它，GSC 就會啟動為期 28 天的驗證監測。這是因為 CrUX 資料本身有 28 天的滯後性，新的良好體驗數據需要時間累積，同時舊的不良數據也要時間滾出視窗。在此期間，你可以使用 PageSpeed Insights 工具對具體頁面進行即時測試，它能提供當下的實驗室評估結果，作為優化是否生效的快速反饋，但請記得，最終能否在 GSC 報表中「變綠」，還是取決於真實用戶的長期數據。
28 天後，GSC 會顯示三種可能的結果：通過（Passed）、失敗（Failed）或資料不足（N/A）。如果通過，恭喜你；如果失敗，別灰心，這通常意味著還有潛在問題未被根除，或是修正未完全部署到所有相關頁面。回到問題詳情頁，查看哪些具體網址依然顯示「較差」，然後針對這些頁面重新進行診斷。驗證過程本身就是一個持續優化的循環，它能幫助你更精準地鎖定問題根源。
關於 GSC Core Web Vitals 報表的常見問題
為什麼我的 GSC Core Web Vitals 報表沒有顯示任何數據？
最常見的原因是你的網頁在過去 28 天內，缺乏足夠數量的真實使用者訪問數據來產生有意義的統計。CrUX 報告需要一個最低的流量門檻。此外，如果你的網站主要流量來自非 Chrome 瀏覽器，報告也不會生成。建議先確認 Google Analytics 中這些頁面的流量狀況。
GSC 報表中的「URL 群組」是怎麼劃分的？我可以自己定義嗎？
「URL 群組」是 Google 根據頁面的相似使用者體驗自動聚合的結果，而非依據你的網站目錄結構。你無法手動調整分組方式。一個群組的狀態是由群組內體驗最差的網址決定的。要找出問題根源，你需要點擊群組，查看其中列出的具體「範例網址」，然後逐一診斷。
GSC 說我網站「體驗不佳」，但 PageSpeed Insights 分數卻挺高的，這怎麼解釋？
因為兩者測量的東西完全不同。GSC 的數據來自真實使用者（CrUX），反映的是過去 28 天所有訪客的綜合體驗，包括使用低速網路或舊裝置的用戶。PageSpeed Insights 的「實驗室資料」則是基於一個固定的模擬環境（如中階手機、4G 網速）進行的單次測試。真實世界的變異性遠高於實驗室環境。
修完問題後，按了「開始追蹤」，為什麼報表狀態沒有立刻變成「良好」？
因為 CrUX 數據有 28 天的滯後期。你修復後的優良體驗數據需要時間累積，而舊的不良數據也需要時間滾出這個 28 天的計算窗口。在此期間，狀態可能維持不變，甚至短暫變差。請耐心等待追蹤期結束，同時可用 PageSpeed Insights 進行即時測試來驗證技術上的改善。
「體驗不佳的連結」數字很多，代表每個連結都有問題嗎？
不一定。這個數字是受影響的「網址群組」數量。一個群組代表一組具有相似使用者體驗問題的頁面。問題可能根源於一個共通的模板或腳本，影響了群組內的所有頁面。因此，找到一個群組的根本原因，往往能一次解決群組內大量頁面的問題，效率遠高於逐個頁面處理。