網站載入速度真的會影響 SEO 排名嗎？Core Web Vitals 優化實戰指南
先說結論：速度影響排名，但不是唯一因素
很多人問我「網站慢一點真的會影響排名嗎？」答案是肯定的，但有個前提要講清楚。
Google 在 2021 年正式將 Core Web Vitals 納入排名演算法，到 2026 年這套標準已經相當成熟，評估的是「使用者在你的頁面上實際感受到的體驗」，而不只是後台測到的技術數字。
換句話說：你的競爭對手如果內容品質跟你差不多，但他的頁面載入更快、互動更順，Google 比較可能推他。
你需要先搞懂的三個指標
LCP（Largest Contentful Paint） 頁面最大內容元素（通常是主圖或大標題）出現的時間。目標是 2.5 秒以內。超過 4 秒就是「差」。
INP（Interaction to Next Paint） 2024 年正式取代舊版 FID，衡量使用者點按、輸入等互動後頁面回應的速度。目標是 200ms 以內。
CLS（Cumulative Layout Shift） 頁面載入過程中版面跳動的累積幅度。目標是 0.1 以下。你一定遇過那種剛要點按鈕、按鈕突然跑掉的網站，那就是 CLS 問題。
事前準備：診斷工具與基準線
在開始優化之前，你需要先知道自己的現況。
- Google PageSpeed Insights（免費）：輸入網址直接看分數，同時顯示 Lab 數據和 Field 數據（真實使用者數據）
- Google Search Console：左側「Core Web Vitals」報告，會按照頁面群組分類問題，是最貼近實際排名影響的數據來源
- Chrome DevTools Performance 面板：適合開發者進一步診斷哪段 JavaScript 拖慢了 INP
建議先跑 Search Console 報告，找出被標記為「差」或「需要改善」的頁面，優先處理流量最高的那幾頁。
步驟一：優化 LCP，讓主內容快點出現
LCP 慢通常有幾個主因：
圖片沒壓縮、格式沒轉換
2026 年，WebP 和 AVIF 已經是基本功。同一張圖從 JPEG 換成 AVIF，檔案可以小 50-70%，肉眼幾乎無差異。WordPress 用戶可以裝 ShortPixel 或 Imagify；自架站可以在構建流程中用 sharp 批次轉換。
沒設 fetchpriority="high" 給主圖
瀏覽器不知道哪張圖最重要，會照順序載入。你需要在 Hero 圖片的 <img> 標籤加上 fetchpriority="high"，讓瀏覽器優先處理它。
伺服器回應太慢（TTFB 高） 如果你的主機 TTFB 超過 600ms，再怎麼壓圖都有極限。考慮換快一點的主機，或啟用 CDN（Cloudflare 免費版就夠用）。
步驟二：修掉 CLS，讓版面停止亂跑
CLS 問題最常見的來源：
- 圖片或影片沒有預設寬高：瀏覽器不知道要保留多少空間，等圖片載入後就推擠其他元素。解法很簡單，在所有
<img>加上width和height屬性。 - 字型還沒載入就顯示：用
font-display: optional或font-display: swap控制字型載入行為，避免文字突然換字型時造成位移。 - 廣告或嵌入元素動態插入：如果你的頁面有廣告位，先用 CSS 把位置留好，不要讓廣告撐開版面。
步驟三：改善 INP，讓互動反應更靈敏
INP 是三個指標裡最難優化的，因為它跟 JavaScript 執行量直接掛鉤。
減少主執行緒阻塞 用 Chrome DevTools 的 Performance 面板錄製一次互動，找出「Long Tasks」（超過 50ms 的任務）。常見元兇是第三方腳本，例如聊天插件、行銷追蹤工具。
延遲載入不必要的第三方腳本
把非關鍵的第三方 script 改成 async 或 defer，或者在使用者第一次互動後才載入（稱為 Facade Pattern）。假設你有嵌一個 YouTube 影片，可以先顯示靜態縮圖，點擊後才真正載入 iframe，這樣能大幅降低初始載入的 JavaScript 執行量。
分割大型 JavaScript Bundle 如果是 React / Vue / Next.js 架構，記得用動態 import 做 Code Splitting，不要把整個 app bundle 塞進第一頁。
常見錯誤與怎麼避開
錯誤一：只看 Lab 數據，忽略 Field 數據 PageSpeed Insights 的分數是在受控環境下跑出來的，真實使用者的網路、裝置差異很大。Search Console 的 Field 數據才是 Google 實際用來評估你網站的依據。
錯誤二：優化桌機版，忘了手機版 Google 用行動版優先索引（Mobile-First Indexing），Core Web Vitals 評估以手機為主。PageSpeed Insights 預設就是手機版，記得兩個版本都要看。
錯誤三：裝太多 WordPress 外掛以為能解決一切 WP Rocket、W3 Total Cache 這類快取外掛確實有幫助，但如果你的主題本身塞了一堆沒用的 JavaScript，快取治標不治本。找一個輕量主題（如 Kadence 或 GeneratePress），比裝十個外掛更有效。
想了解更多關於網站 SEO 的整體架構，可以參考WordPress SEO 完整教學：技術面到內容面，一張地圖帶你走完，有助於把 Core Web Vitals 優化放在正確的位置理解。
檢查清單：優化完成後的驗收
- PageSpeed Insights 手機版 LCP < 2.5s
- CLS < 0.1，頁面版面不再跳動
- INP < 200ms，點按有即時回應感
- Search Console Core Web Vitals 報告無「差」狀態頁面
- 所有圖片已轉換為 WebP 或 AVIF
- 主圖加上
fetchpriority="high" - 第三方腳本改為非同步載入
- CDN 已啟用
結論：速度優化是持續維護的工程
Core Web Vitals 不是調一次就永遠解決的事。你每次新增外掛、換主題、嵌入新的第三方工具，分數都可能退步。
建議每季跑一次 Search Console 報告，把它當成定期健康檢查，有問題及早發現。SEO 排名從來不是單一因素決定的，但速度是一個你完全可以掌控、相對容易量化進步的維度，值得認真對待。
如果你還在研究連結策略，可以搭配內部連結怎麼做才有效？從結構到錨文字，SEO 內部連結完整教學一起看，兩個方向同時推進，效果會更明顯。
常見問題
Core Web Vitals 分數低一定會讓排名下降嗎？
不一定。Google 把 Core Web Vitals 視為排名因素之一，但它不是唯一指標。如果你的內容品質、反向連結明顯優於競爭對手，速度稍差也可能維持排名。但當競爭者條件相近時，速度分數就會成為差異點，此時優化就值得優先投入。
PageSpeed Insights 分數要到幾分才算夠？
沒有絕對標準，但 Google 建議手機版三個 Core Web Vitals 指標都達到「Good」區間（LCP < 2.5s、INP < 200ms、CLS < 0.1）。PageSpeed Insights 的總分只是參考，真正重要的是個別指標的 Field 數據是否在綠色區間。
用 WordPress 的話，有哪些外掛可以快速改善速度？
WP Rocket 是整合性最強的付費快取外掛，功能涵蓋快取、延遲載入、CSS 最小化。免費方案可以考慮 LiteSpeed Cache（需要 LiteSpeed 主機）或 W3 Total Cache 搭配 Cloudflare CDN。但要注意：外掛治標，輕量主題才是根本。
CLS 問題要怎麼快速找出是哪個元素造成的？
用 Chrome DevTools 開啟 Performance 面板，錄製頁面載入過程，在 Layout Shifts 欄位可以看到每一次位移發生的時間與元素。PageSpeed Insights 的「診斷」區塊也會直接點出主要的 CLS 來源元素，是最快的入門診斷方式。
分享這篇
