網站速度對 SEO 的影響：Core Web Vitals 完整說明

客戶最常問的問題是「網站變快之後，排名會不會跟著上去」。
這個問題沒有一句話可以講完，因為 Core Web Vitals 跟排名的關係，比多數文章寫的還要曖昧一點。
這篇文章把這件事拆開來講清楚：
指標怎麼算、Google 怎麼用、實際案例長什麼樣子，
以及益盛在處理客戶網站改版時，實際會怎麼安排優化順序。

Core Web Vitals 是什麼

Core Web Vitals 是 Google 用來評估真實使用者體驗的一組指標，
主要看三件事：載入速度、互動反應、視覺穩定性。Google Search Central 說明，
網站應讓 LCP 在 2.5 秒內、INP 低於 200 毫秒、CLS 低於 0.1，才能提供較好的使用體驗。
這三項指標都以「第 75 百分位」計算，
也就是用真實訪客資料中，表現較差的那一群人的數字當基準，而不是看平均值或最佳狀況。
這個計算方式很多客戶不知道，但其實很關鍵：平均值好看不代表多數使用者體驗好。

LCP（最大內容繪製）

LCP 量的是頁面上最大的可見元素（通常是首頁的大圖、影片或大段文字）從使用者進入頁面到完整繪製出來所花的時間。
良好標準是 2.5 秒以內，2.5 到 4 秒算需要改善，超過 4 秒體驗就差了。
實務上 LCP 卡住的原因九成都是同一批：
圖片沒壓縮、伺服器回應慢、字型載入卡住渲染。

INP（下一次繪製互動）

INP 在 2024 年正式取代 FID，成為官方核心指標。
差別在於 FID 只看「第一次」互動的延遲，
INP 則是觀察使用者在整個頁面停留期間，所有點擊、輸入、觸控的反應時間，
取其中最慢的那一次當分數。
換句話說，就算第一次點擊很快，後面某次互動卡頓，INP 還是會被拖累。
良好門檻是 200 毫秒以內。

CLS（累計版面配置偏移）

CLS 衡量頁面在載入過程中，畫面元素「無預期」跳動的程度，
常見元凶是圖片沒設定尺寸、廣告版位延遲載入、字型置換造成的文字跳動。
良好標準是 0.1 以下。
要特別說明的是，使用者主動觸發的動畫，
或是點擊後 500 毫秒內發生的版面變化，並不計入 CLS，
這點常被誤解成「所有跳動都是扣分」，其實不是。

Core Web Vitals 跟排名的關係，沒有想像中直接

在 SEO 影響上，Core Web Vitals 不是唯一排名因素，
也不是「分數變高排名就一定暴衝」的魔法藥水。
Google 官方文件並沒有把 Core Web Vitals 描述成最主要的排名因素，而是把它放在頁面體驗訊號的一部分。
比較務實的理解是：
內容相關性與搜尋意圖仍然是 SEO 的核心，
Core Web Vitals 則是在內容品質接近時，
可能影響使用者體驗與搜尋表現的輔助因素。

實務上我們會把 Core Web Vitals 理解成一道「及格線」而不是「加分項」：
分數差到使用者體驗明顯不好，會拖累轉換與停留時間，間接影響 SEO 表現；
但分數從 90 分衝到 100 分，排名通常不會有感變化。
Google 也建議網站經營者改善 Core Web Vitals，
因為這和搜尋表現與整體使用者體驗有關，
這句話的重點其實在後半段：
使用者體驗本身就是目的，排名只是附帶結果。

數字會說話：實際案例對照

實務案例也顯示，速度優化不只影響 SEO，還會影響轉換。
web.dev 整理的案例中，Vodafone 改善 LCP 後，銷售成效提升；
把幾個常被引用的案例整理成下表，方便對照：

重要：
這些數字都是各品牌在特定條件下的結果，不是放諸四海皆準的公式。
不同產業、不同流量結構、不同起始基準，優化後的效益會有落差。
我們在跟客戶報告成效時，也一律會註明測量區間與比較基準，
避免用單一案例的數字暗示「做了一定會這樣」。

網頁設計 公司視角：技術與內容怎麼一起做

益盛在處理客戶網站改版時，常遇到一種情況：
客戶想優化 Core Web Vitals 分數，沒打算動內容架構，
結果分數提升了，排名卻沒什麼變化。
原因很簡單，內容品質與關鍵字布局還是排名的主要變數，
速度優化解決的是「使用者願不願意留下來」，
不是「Google 覺得這頁內容值不值得排前面」。
實務建議是把兩件事一起排：
改版時同步處理資訊架構、內部連結與頁面速度，
而不是先做完一邊再回頭補另一邊。

另一個常被忽略的細節：
行動裝置與桌面版的分數要分開看。
多數客戶的網站桌面版 Core Web Vitals 都不錯，
行動版卻常常卡在 LCP 超標，
原因多半是行動版圖片沒有單獨優化、或是行動版載入了桌面版用不到的腳本。
Search Console 的報表會分開列出兩種裝置的數據，這是判斷問題出在哪一端的第一步。

優化策略：從伺服器到前端

怎麼測、怎麼長期監控

效能優化需要實驗室測試與真實數據兩種工具搭配使用，單看其中一種容易誤判。
PageSpeed Insights 與 Lighthouse 提供實驗室環境的分數與改善建議，適合開發階段反覆測試；
Search Console 的 Core Web Vitals 報表與 Chrome UX Report 則反映真實使用者的數據，
是判斷網站「目前實際表現」的依據。
兩者數字常常對不上，原因是實驗室測試用的是固定的網路與裝置條件，
真實使用者的網路環境千差萬別。

網站正式上線後，
建議導入 Lighthouse CI 或類似工具，把效能檢測排進部署流程，
每次改版自動跑一次測試，分數明顯下滑時及早發現，
而不是等到排名或轉換率下滑才回頭追查原因。

益盛怎麼安排這類專案

我們在處理客戶的 Core Web Vitals 優化需求時，通常分三階段進行：
第一階段先用 Lighthouse 與 Search Console 抓出全站的效能瓶頸，
並與同產業競品網站做基準比對，產出書面的問題清單；
第二階段依優先順序處理圖片、程式碼與伺服器設定，
每項改動都會個別驗證效果，
避免一次改太多項目反而難以追蹤是哪個改動有效；
第三階段導入監控機制，
確保改善後的分數不會隨著後續改版又悄悄退步。
三個階段所需時間會依網站規模與既有技術狀況調整，
一般中小型企業網站約需要一到兩週完成檢測與優化實作，
正式網站可以參考我們的 SEO 服務頁面進一步了解服務範圍，
或透過 LINE 預約初步諮詢。

常見問題

Core Web Vitals 分數不好，網站一定會掉排名嗎？

不一定。
Core Web Vitals 是排名的眾多訊號之一，權重不如內容相關性高。
分數差通常先反映在跳出率與轉換率上，對排名的影響是間接且漸進的，
不是立即性的懲罰。

三項指標裡，哪一個最該優先處理？

沒有固定答案，要看 Search Console 報表顯示哪一項超標最嚴重。
一般來說 LCP 最容易透過圖片優化與伺服器設定快速改善，
CLS 次之，INP 通常需要動到程式邏輯，處理難度較高。

FID 已經被 INP 取代了，舊資料還有參考價值嗎？

FID 數據可以作為歷史對照，
但現行的官方標準與 Search Console 報表都已改用 INP 評分，
建議優化方向直接以 INP 門檻為準。

多久應該重新檢測一次 Core Web Vitals？

建議每次網站改版或新增功能後立即檢測一次，
平時則可每月透過 Search Console 報表追蹤一次趨勢，避免分數在沒注意的情況下緩慢下滑。

益盛在改版專案中會怎麼處理速度優化？

我們會把速度優化排進整體改版流程，做法可參考前面「益盛怎麼安排這類專案」的說明，
也歡迎透過 LINE 直接討論您網站的現況。