你用 PageSpeed Insights 測了自己的網站，看到一個分數——可能是 68、可能是 45——然後呢？

那個總分其實不是 Google 排名時看的東西。真正被納入排名訊號的是三個具體指標，它們有明確的合格標準，而且測量的是「真實訪客的實際體驗」，不是你按下測試按鈕那一次的結果。

這篇文章會說清楚這三個指標各自在測什麼、多少算合格、去哪裡看你網站的真實數據，以及一個很多人搞錯的問題：分數提高了，排名就會跟著上去嗎？

Core Web Vitals 是什麼

Core Web Vitals（核心網頁指標）是 Google 用來量化「使用者體驗好不好」的三個指標。它們是 Google 網頁體驗評估的一部分，也是明確被列入排名系統的訊號之一。

三個指標分別對應使用者在網頁上的三種感受：

• 載入夠不夠快——主要內容多久才看得到
• 反應夠不夠靈敏——點下去多久才有回應
• 畫面穩不穩——內容會不會突然跳動

這三件事都是使用者會直接感覺到的。Google 的邏輯很簡單：如果一個網頁讓人用得不舒服，就不該優先推薦給搜尋的人。

三個指標各自在測什麼

LCP：主要內容多久才顯示

LCP（Largest Contentful Paint，最大內容繪製）測量的是頁面上最大的那個元素多久才顯示完成——通常是主視覺圖片、影片封面、或一大塊文字區塊。

它反映的是「使用者多久之後覺得這頁載入好了」。

評等	標準
良好	2.5 秒以內
需要改善	2.5–4 秒
不良	超過 4 秒

常見的拖累來源：沒壓縮的大圖、伺服器回應太慢、字型檔案載入過久、或是主視覺被 JavaScript 擋住而延後顯示。

INP：點下去多久才有回應

INP（Interaction to Next Paint，互動到下次顯示）測量的是使用者點擊、輸入之後，畫面多久才給出視覺回饋。

這個指標在 2024 年 3 月取代了舊的 FID。差別在於：FID 只測「第一次互動」的延遲，而 INP 會觀察整個瀏覽過程中的所有互動，取其中表現較差的那些來評分——更貼近真實的使用感受。

評等	標準
良好	200 毫秒以內
需要改善	200–500 毫秒
不良	超過 500 毫秒

常見的拖累來源：過多的 JavaScript 在背景執行、外掛太多互相搶資源、第三方追蹤碼（廣告、聊天機器人、分析工具）拖住主執行緒。

如果你看到自己的網站在 INP 這一項不合格，第一個要懷疑的是外掛數量——判斷方式在〈WordPress 外掛怎麼選？中小企業必裝的 8 類外掛〉。

CLS：畫面會不會突然跳動

CLS（Cumulative Layout Shift，累積版面配置位移）測量的是載入過程中，畫面上的元素有沒有突然移位。

典型的災難場景：你正要點某個按鈕，上方突然載入一張廣告圖，整個版面往下推，於是你點到了別的東西。這是全世界共通的惱人經驗，而 CLS 就是在量化它。

評等	標準
良好	0.1 以下
需要改善	0.1–0.25
不良	超過 0.25

常見的拖累來源：圖片沒有指定寬高（瀏覽器不知道要留多少空間）、廣告或嵌入內容動態插入、字型切換造成文字重排、或是彈出視窗把內容往下擠。

CLS 是三個指標裡最容易改善的一個，因為多數問題只要幫圖片和嵌入元素預留固定尺寸就能解決。

一個重要的觀念：實驗室數據 vs 真實數據

這是很多人搞不清楚、也因此白忙一場的地方。

實驗室數據（Lab Data）

你按下 PageSpeed Insights 的測試按鈕，它會在模擬的環境裡跑一次——固定的裝置規格、固定的網路速度。得到的分數就是實驗室數據。

它的優點是可以重複測試、方便比較改善前後的差異；缺點是那不是真人的體驗。

真實數據（Field Data）

Google 會蒐集實際造訪你網站的 Chrome 使用者資料，統計他們遇到的 LCP、INP、CLS。這份資料叫做 CrUX（Chrome 使用者體驗報告）。

Google 排名時用的是這份真實數據，不是你測出來的分數。

兩個關鍵差異：

• 它以 28 天為週期滾動計算——你今天改好，數據要好幾週後才會反映出來。這是很多人「改完沒感覺」的真正原因。
• 流量太少的網站沒有這份資料——因為樣本不足，Google 不會顯示。新網站或小網站常常看不到真實數據，只能參考實驗室數據。

合格的判定方式

Google 取的是第 75 百分位——也就是說，要讓四分之三的訪客體驗達到「良好」的標準，這個指標才算通過。

這個設計的意思是：你不能只顧最好的那批訪客。如果多數人用手機、網路較慢，那些人的體驗才是決定分數的關鍵。

去哪裡看你網站的數據

Search Console 的「網頁體驗」報表

這是最該看的地方，因為它顯示的是真實數據，而且會把有問題的網址分組列出來——例如「所有商品頁的 LCP 都不合格」。

報表會分成行動裝置和電腦兩份。優先看行動裝置那一份，因為 Google 是以手機版內容作為排名依據，相關說明在〈行動優先索引：手機版網站的重要性〉。

PageSpeed Insights

輸入單一網址就能測。畫面上方如果有真實數據會先顯示，下方才是實驗室測試的結果與改善建議。

看建議清單，不要只看總分。那個 0–100 的分數是實驗室數據算出來的綜合評分，跟 Core Web Vitals 的三個指標不是同一件事——分數 90 分但 INP 不合格的情況完全可能發生。

Chrome 開發者工具

按 F12 打開，Lighthouse 分頁可以在本機跑測試，Performance 分頁能看到更細的執行過程。這是工程師層級的工具，一般經營者用前兩個就夠。

分數提高了，排名就會上去嗎？

這是最需要誠實回答的問題：不一定，而且通常沒有你期待的那麼直接。

它是排名訊號，但權重不高

Google 自己說明過，網頁體驗是眾多排名因素之一，但內容的相關性和品質仍然是主要的判斷依據。

白話說：一篇速度普通但完整回答問題的文章，會贏過一篇飛快但內容空洞的文章。速度不會讓爛內容排上去。

它更像是「同分時的加分」

比較準確的理解是：當兩個頁面的內容價值相近時，體驗較好的那個會被優先推薦。所以它的作用在競爭激烈的關鍵字上才明顯。

但間接影響可能更大

這一點反而更值得注意。網頁載入時間從 1 秒拉長到 3 秒，跳出率就會明顯上升。訪客等不下去而離開，你損失的是實際的詢問和訂單——那個損失不需要透過排名，是直接發生的。

另外還有一個更隱蔽的路徑：如果你的伺服器經常回應緩慢或逾時，Googlebot 會逐漸降低來訪頻率，新文章要很久才被發現，舊文章的排名也會慢慢往下掉。這種下滑沒有任何警告，判讀方式在〈為什麼你的網站 Google 搜尋不到〉的原因七。

該從哪裡開始改？

三個指標的改善難度和投報率差很多，建議按這個順序：

第一優先：CLS

最容易改，效果最明顯。多數問題只要幫圖片和嵌入元素指定寬高就解決了——瀏覽器知道要留多少空間，就不會等圖片載入才把版面推開。

另外檢查有沒有全螢幕彈出視窗，那是 CLS 和使用者體驗的雙重扣分。

第二優先：LCP

主要靠圖片優化——轉成 WebP、上傳前先縮到合適尺寸、啟用延遲載入。這一項通常能帶來最大的秒數改善。

如果圖片都處理完了 LCP 仍然不合格，那要懷疑伺服器回應時間。這時候就不是網站端能解決的了。

第三優先：INP

最難改，因為它牽涉到 JavaScript 的執行效率。實務上能做的多半是減少外掛數量和移除不必要的第三方追蹤碼。

如果一定要用某個功能繁重的外掛，那可能要接受這一項不完美。

什麼時候問題不在網站端

如果你做完上面所有優化，LCP 還是超過標準，而且連後台登入畫面都慢——那是伺服器的問題，外掛救不了。

怎麼分辨是網站還是主機，〈網站速度慢怎麼辦？先分辨是網站還是主機的問題〉有三個判斷訊號和完整的十個做法。

常見的五個誤解

• 以為 PageSpeed 的總分就是 Core Web Vitals。那是實驗室的綜合評分，跟三個指標不是同一件事。
• 以為改完隔天就會反映。真實數據以 28 天滾動計算，要等好幾週。
• 只看電腦版分數。Google 以行動版為排名依據。
• 以為滿分就能排第一。它是眾多訊號之一，內容品質仍然是主角。
• 看不到真實數據就以為出錯了。流量不足的網站本來就不會顯示。

結語

Core Web Vitals 值得做，但要用正確的期待去做：它不會讓內容不足的網頁排上去，但會在其他條件相近時幫你加分，而且對訪客的實際留存有直接影響。

建議的執行順序是：先看 Search Console 的行動裝置報表確認哪一項不合格 → 從 CLS 開始改（最快見效）→ 處理圖片改善 LCP → 最後才動 JavaScript 和外掛 → 全部做完仍不合格就檢查伺服器。

改完之後不要每天測，那只會讓你焦慮。設一個提醒，四週後再回頭看 Search Console 的真實數據——那時候的數字才有意義。

如果檢查下來確認問題出在伺服器回應時間，或是不確定該從哪裡下手，歡迎與我們聯絡。5NET 提供台灣機房的虛擬主機服務，也可以協助你判讀目前主機的實際負載狀況。