文章目錄
網頁速度對 SEO 排名的影響：PageSpeed Insights 怎麼看、Core Web Vitals 怎麼救
網頁速度確實是 Google 的排名因素，但它不是「一速定江山」。Google 從 2010 年把桌面版速度列入排名、2018 年 7 月再把行動版速度納入考量，真正用來判斷的是 Core Web Vitals 三大指標（LCP、INP、CLS）是否同時過門檻，而不是你在 PageSpeed Insights 看到的那個 0 到 100 分。把分數死磕到 100、排名卻一動不動，是這個領域最常見的冤枉路。
TL;DR：速度是「平手決勝」因素，內容旗鼓相當時才發揮作用。重點是把 LCP 拉到 2.5 秒以下、INP 壓到 200 毫秒以內、CLS 守住 0.1，這套 Core Web Vitals 過門檻就及格，再上去的邊際效益接近零。Amazon 傳聞 100 毫秒延遲就掉 1% 營收的案例被引用了十幾年，當個方向感就好，別把它當鐵律。
網頁速度到底是不是 Google 排名因素？是，但份量沒你想的大
先把結論講清楚：速度是排名因素，但它屬於「平手決勝」那一類，不是「只要快就能贏」。當你和對手的內容相關性、權威性、反向連結差不多時，速度更快的頁面才會勝出。單靠把 Lighthouse 跑到滿分就想衝到第一頁，這個假設從一開始就不成立。
Google 的態度其實很一致。2010 年官方公告把桌面版速度列為排名因素之一，2018 年 7 月再把行動版速度納入。當時很多人緊張到砸錢換主機、上 CDN，結果發現排名根本沒有因為速度變快就暴衝。問題不在速度沒用，而在大家誤解了它的份量。如果你對 SEO 排名因素的全貌沒有概念，很容易把單一訊號當成萬靈丹。
直接影響 vs 間接影響，這兩條路別搞混
速度影響排名有兩條路徑，搞混就會用錯力氣。
- 直接路徑：Core Web Vitals 三指標是否同時達標，這是 Google 公開列為「頁面體驗」訊號的一部分。沒過門檻，排名會被扣分；過了門檻，才算拿到基本盤。
- 間接路徑：速度慢會拉高跳出率、壓低停留時間、拖垮轉換率，這些使用者行為訊號回過頭來影響 Google 對頁面品質的判斷。你看到的「速度變快排名也變好」，很多時候是這條路徑在發揮作用。
用白話說，直接路徑是 Google 明文規定的及格線，間接路徑是使用者用行為投出來的票。兩者都要照顧，但順序是先衝過直接路徑的門檻，再去最佳化體驗。這也是 頁面體驗這幾年從「加分項」被升級成「基礎」的原因。
反迷思：Lighthouse 100 分不等於排第一
我遇過一個接案工程師，把客戶網站的 Lighthouse 分數從 45 拉到 98，開開心心回報，結果客戶問「那為什麼排名還在第二頁」。問題出在他看錯地方。Lighthouse 的實驗室分數和真正列入排名的實地 Core Web Vitals 資料是兩回事，這個區別後面會講。先記住一句話：決定排名的三大因素始終是內容、連結與使用者意圖，速度只在這三者打平時才上場當裁判。
Core Web Vitals 是什麼？2026 年 Google 看速度就看這三個指標
Core Web Vitals 是 Google 用來衡量網頁使用體驗的三個核心指標，簡稱 CWV。LCP 看載入速度、INP 看互動回應、CLS 看視覺穩定。三者同時過門檻才算合格，這也是 Google 實際用來判斷速度排名的依據。如果你想看更完整的定義，可以參考Core Web Vitals 專文，這裡先把實戰要用的門檻講清楚。
為什麼要強調「同時過門檻」？因為單項優秀不夠。LCP 1.8 秒漂亮，但 INP 卡到 450 毫秒，使用者點了按鈕半秒沒反應，Google 照樣判定這個頁面的體驗不及格。三指標是 AND 不是 OR，這是很多人會漏掉的邏輯。
2024 年 3 月 INP 正式取代 FID，只看這三項就好
如果你看到的教學文還在講 FID（First Input Delay），那它過時了。Google 在 2024 年 3 月正式讓 INP 取代 FID 成為 Core Web Vitals 的互動指標。原因很實際：FID 只量測使用者「第一次」互動的延遲，但真實使用者在頁面上會點好幾次，第一次順不代表每次都順。INP 量測整個工作階段中所有互動的最差表現，更貼近真實體驗。
所以 2026 年你只需要關注 LCP、INP、CLS 這三項，不用再回頭研究 FID 怎麼最佳化。這也是為什麼近兩年的Google 演算法更新方向，愈來愈多力氣放在使用者真實互動訊號上。
| 指標 | 全名 | 良好門檻 | 需要改善 | 主要看什麼 |
|---|---|---|---|---|
| LCP | Largest Contentful Paint | ≤ 2.5 秒 | 2.5 – 4.0 秒 | 最大元素載入完成時間 |
| INP | Interaction to Next Paint | ≤ 200 毫秒 | 200 – 500 毫秒 | 互動後到頁面回應的時間 |
| CLS | Cumulative Layout Shift | ≤ 0.1 | 0.1 – 0.25 | 載入過程的版面位移量 |
三個門檻都是 Google 在 web.dev 官方文件明訂的，不是網路上流傳的數字。把這張表記下來，後面看 PageSpeed Insights 報告時會一直用到。
LCP、INP、CLS 各自代表什麼？門檻與改善方向一次看懂
三個指標的改善方向完全不同，看錯指標下錯藥是常見悲劇。LCP 看主機與圖片、INP 看 JavaScript、CLS 看圖片尺寸與廣告版位，這三者沒有交集，得逐項處理。
LCP 最大內容繪製：通常卡在主圖或大標題
LCP 量測的是頁面上「最大的可見元素」載入完成的時間，通常是首圖、Hero 圖或大標題。門檻 2.5 秒，意思是使用者在 2.5 秒內要看到這個最大元素完整出現，超過就會被判定體驗不佳。
改善方向有三個：一是主機回應速度（TTFB），伺服器太慢，後面再怎麼最佳化都救不回來；二是圖片最佳化，把那張首圖轉成 WebP、壓到合理大小，這件事圖片替代文字與圖片 SEO 一樣關鍵；三是關鍵資源預載入，用 preload 或 fetchpriority 告訴瀏覽器「這張圖最重要，先載」。
INP 互動至下一次繪製：2026 年最容易翻車的指標
INP 量測使用者點擊、輸入、捲動後到頁面「真的回應」的時間，門檻 200 毫秒。200 毫秒聽起來很短，對 WordPress 這種外掛成群的網站來說卻很硬。多數網站的 INP 問題都出在 JavaScript 太重，主執行緒被佔滿，使用者點下去要等 JS 跑完才輪得到畫面更新。
改善方向是減少 JavaScript 執行時間：拆分長任務、延遲載入非必要的腳本、把第三方程式碼（分析、廣告、客服聊天外掛）往後丟。這裡要小心一件事：延遲載入用過頭，會把本來該即時回應的功能也延後了，反而把程式碼最佳化的好意變成 bug。
CLS 累積版面位移：那個會把按鈕推走的惱人現象
CLS 量測頁面載入過程中元素跳動的程度，門檻 0.1。你一定遇過：想點某個按鈕，結果頁面突然跳了一下，點到旁邊的廣告。那就是 CLS 太高。這個指標門檻看起來抽象，其實改善方法很具體。
- 圖片、影片、嵌入框都先設好寬高，瀏覽器才知道要預留空間。
- 廣告版位先佔位，不要等廣告載入才把內容往下推。
- 避免在既有內容上方動態插入新元素，特別是通知列和彈窗。
這三件事做完，CLS 通常就會降到門檻內，是 CP 值最高的改善項目之一。WordPress 網站如果還在用會彈出覆蓋的Pop-up 廣告，CLS 跟 SEO 一起賠。
PageSpeed Insights 怎麼用？分數、實驗室資料、實地資料的差別
PageSpeed Insights（簡稱 PSI）一次給你兩種資料：上半部是「實地資料（CrUX）」，來自真實 Chrome 使用者，這才是 Google 用來判斷排名的依據；下半部是「實驗室資料（Lighthouse）」，是模擬環境跑出來的檢測與改善建議。要看的是上半部的 Core Web Vitals 是否過門檻，下面的 Lighthouse 分數只是診斷參考。
這個區別是整篇文章最重要的一段話。你可以直接打開 PageSpeed Insights 官方工具輸入網址，對照下面的說明看。如果想看 PSI 整合 Lighthouse 的歷史脈絡，這篇舊文有完整記錄。
實地資料（CrUX）才是排名依據
實地資料來自 Chrome 使用者體驗報告（Chrome User Experience Report, CrUX），是真實訪客在你網站上累積出來的資料。Google 排名判斷用的是這份，不是 Lighthouse 那個 0 到 100 的分數。你可以在Search Console 的 Core Web Vitals 報告看到整站的實地資料彙總，這比單頁 PSI 更全面。
實驗室資料（Lighthouse）是診斷工具，不是 KPI
Lighthouse 在一個受控的模擬環境裡跑你的頁面，給出分數和一堆改善建議。它的價值在「告訴你哪裡有問題、怎麼修」，而不是「給你一個可以拿去跟老闆交差的分數」。把 Lighthouse 分數當 KPI 死磕到 100，是這個領域最大的時間浪費之一。
| 比較項目 | 實地資料（CrUX） | 實驗室資料（Lighthouse） |
|---|---|---|
| 資料來源 | 真實 Chrome 使用者 | 模擬環境（固定網速、裝置） |
| 用途 | 排名判斷依據 | 診斷與改善建議 |
| 需要的樣本量 | 要達門檻才會顯示 | 單頁立即產生 |
| 會不會波動 | 累積 28 天，相對穩定 | 每次跑可能不一樣 |
| 該怎麼用 | 看 LCP/INP/CLS 是否標綠 | 看診斷建議決定改什麼 |
分數 90 幾卻排名沒動，多半是看錯區塊
最經典的誤判是這樣：PSI 下半部 Lighthouse 顯示 95 分，行銷人員以為速度滿分、問題不在这里。結果上半部實地資料根本沒過 CWV 門檻（或流量太少根本沒資料），真正影響排名的訊號是紅的，他卻在看綠的那一塊。反過來也有，Lighthouse 分數只有 70，但實地 CWV 全綠，這種頁面排名其實沒事。看錯地方，就是白忙一場。
我的習慣是：先用 Search Console 看整站實地 CWV，找出不及格的頁面群，再用 PSI 針對那些頁面跑 Lighthouse 拿改善建議。工具是這樣接的，順序不能顛倒。
為什麼分數已經 90 幾了，排名還是不動？速度的真實影響邊界
因為速度是「平手決勝」因素。當你的內容相關性、權威性、外部連結輸給對手時，速度再快也不會讓你贏。CWV 過門檻之後，繼續把分數從 90 拉到 100 對排名的邊際效益接近零，這時應該把心力轉回內容與連結，而不是死磕分數。
邊際效益遞減：過了門檻就該停手
把速度最佳化想成考試及格就好。CWV 三指標全綠，等於 60 分及格，你拿到了參與排名的基本資格。從 60 衝到 90（Lighthouse 分數）對「這個訊號」的邊際效益已經很低，衝到 100 更是幾乎無感。真正拉開排名差距的，從來不是 90 跟 100 的差別，而是內容有沒有比對手更切中搜尋意圖、連結有沒有更扎實。
什麼時候該繼續最佳化速度
- CWV 還沒過門檻，尤其是行動版 INP 紅字。
- 對手網站速度明顯比你快，你們內容卻打平。
- 自然排名與轉換因為速度流失（結帳頁、報名頁特別敏感）。
什麼時候該停手
- CWV 已經全綠，Lighthouse 分數 90 以上。
- 排名卡住，但對手的內容明顯比你深、連結比你多。
- 繼續最佳化的成本（改主機架構、重寫 JS）遠高於補內容。
停手不等於放棄，是把資源挪去 CP 值更高的地方。老實說，多數小網站的速度最佳化，做到「CWV 全綠」就該收工，剩下的時間去補內容深度跟外部連結，回報率會高得多。
怎麼判斷速度到底是不是你現在的瓶頸
很多人一看到排名不動就直覺怪速度，但真相是速度只有在「本來不及格」時才是瓶頸。判斷方法很樸素：開 Search Console 的 Core Web Vitals 報告，看你的網址群組是標綠、標黃還是標紅。全綠就代表速度這個訊號已經達標，再最佳化也擠不出排名；標紅或標黃，才有動手的意義。
另一個訊號來自點擊率與自然流量的異常衰退。如果某個頁面點擊率正常、跳出率卻異常高，而且內容沒問題，那有機會是速度或互動卡頓把人逼走，這時去查 INP 跟 LCP 通常會看到端倪。這類使用者行為訊號，正是 Navboost 這類排名系統會收集的資料，把數字串起來看，比單看一個 Lighthouse 分數準得多。說到底，速度最佳化要不要繼續，是資料問題，不是信仰問題。
這裡要誠實承認一個限制：速度無法單獨決定排名，也沒有任何人能保證「速度拉到多少就會上升幾名」。遇到保證排名的話術，心裡要先打個問號，SEO 公司能不能信，看的是方法論不是承諾。
WordPress 網站速度最佳化清單：2026 年可執行的改善步驟
WordPress 提升速度的優先順序是：主機、快取、圖片、JavaScript、CDN，由上到下處理。CP 值最高的是前三項，多數網站光是換主機加快取加圖片最佳化，就能把 CWV 拉過門檻。下面這份清單是實戰順序，不是隨便堆疊的建議。
第 1 層：主機回應速度（TTFB）是 LCP 的地基
主機回應太慢，後面全白搭。選 SSD 硬碟、機房離台灣近、支援 HTTP/2 與最新 PHP 版本的主機，這是 LCP 的地基。便宜共享主機的 TTFB 動輒 800 毫秒以上，LCP 要進 2.5 秒會很吃力。HTTP/2 這類傳輸協定的支援度，也直接影響資源載入的並發能力。
第 2 層：快取外掛直接降 LCP
頁面快取能讓回訪者直接拿到靜態 HTML，跳過資料庫查詢與 PHP 運算。WP Rocket、LiteSpeed Cache、W3 Total Cache 都常見，選一套就好，不要疊裝。快取做好，LCP 通常立刻有感。WordPress SEO 整體最佳化這件事，快取永遠是前段班。
第 3 層：圖片最佳化，同時改善 LCP 與 CLS
圖片是 WordPress 網站最大的頻寬兇手。三件事一起做：轉檔成 WebP 或 AVIF、設好寬高屬性、非首屏圖片延遲載入。WebP 比 JPEG 小約三成，畫質差不多，現代瀏覽器都支援。設寬高直接解決 CLS 的圖片跳動問題，是最划算的一改。圖片最佳化做完，記得回頭檢查網站架構裡的圖片替代文字有沒有寫，速度跟 SEO 一起顧。
第 4 層：JavaScript 與外掛瘦身，降 INP
WordPress 用久了外掛一定愈裝愈多，每裝一個就多一批 JS。把沒在用的外掛刪掉（不是停用，是刪掉）、把會載入前端腳本的外掛做條件載入、延遲非必要的腳本。這層做完 INP 才會明顯改善。這裡要小心，過度延遲會把關鍵功能也延後，技術 SEO 常見錯誤很多就出在這。
第 5 層：CDN 縮短資源傳輸時間
CDN 把你的靜態資源快取到全球各節點，讀者從最近的節點抓檔，傳輸時間縮短。Cloudflare 免費版對小站就夠用，不用一開始就砸錢。流量大、跨區讀者多、或有大量圖片影片的網站，CDN 的回報才會明顯。想順手把HTTPS、安全標頭一起處理，Cloudflare 後台也能搞定。
非 WordPress 網站也能套用的同一套邏輯
就算你不是用 WordPress，這五層順序一樣成立。Shopify、Wix、自架的 Next.js 專案，差別只在於「能不能改」。SaaS 平台主機與快取幾乎不能動，你能下手的主要是圖片最佳化與 JavaScript 瘦身；自架站則五層全開放。先確認自己能控制哪幾層，再把力氣花在能動的地方，不要對著不能改的主機乾瞪眼。
實務上我會建議每次只動一層，動完跑一次 PSI 對照前後數字，確認有效再進下一層。一次改五層，出問題會分不清是哪層闖的禍。這個紀律聽起來慢，其實是最快的方法，因為你不用花時間回頭 debug 誰搞壞了 INP。把它當成網站最佳化流程的基本動作就好。
| 層級 | 項目 | 主要影響指標 | 難度 | CP 值 |
|---|---|---|---|---|
| 1 | 主機（TTFB） | LCP | 低（換就好） | 極高 |
| 2 | 快取外掛 | LCP | 低 | 極高 |
| 3 | 圖片最佳化 | LCP、CLS | 中 | 高 |
| 4 | JS 與外掛瘦身 | INP | 中高 | 中 |
| 5 | CDN | LCP（傳輸） | 低 | 中 |
如果你不知道現在卡在哪一層，先用 Site Kit by Google 或直接到 PSI 跑一次，看 LCP、INP、CLS 哪個紅字，再回頭對照這張表決定動手順序。
最佳化網頁速度常見的 5 個錯誤：別把力氣花錯地方
這些錯誤的共同點是「看錯指標、用錯力氣」，把可量化的分數當成唯一目標，反而沒解決真正影響排名的問題。看過太多人掉進同一個坑，整理成清單讓你少走冤枉路。
錯誤 1：死磕 Lighthouse 100 分
把分數當 KPI，每天跑 PSI 看分數漲了沒。問題是 Lighthouse 分數跟排名不是等號，前面講過了。把這份心力拿去看實地 CWV 是否過門檻，效率高十倍。
錯誤 2：只最佳化桌面版，忽略行動版
Google 是行動優先索引，排名判斷以行動版為準。你在桌面看到分數漂亮，不代表手機版也漂亮。行動版的 CPU、網速都弱很多，同一個頁面在桌機 LCP 1.5 秒，到手機可能變 4 秒。每次檢測都看行動版那欄，這是基本功。
錯誤 3：狂裝快取外掛，外掛本身拖慢速度
快取外掛裝一套就好，有人為了「效果疊加」同時開兩三套，結果設定互相衝突、資料庫被寫爆，速度反而更慢。技術 SEO的原則是少即是多，先砍掉重複功能的外掛再說。
錯誤 4：過度延遲載入，LCP 反而變慢
延遲載入（lazy load）是雙面刃。首圖、Hero 圖這種 LCP 元素絕對不能延遲，一延遲 LCP 直接爆掉。延遲載入只該用在折疊以下、使用者要捲才看得到的圖片。搞錯目標，好心變壞事。
錯誤 5：只追分數不追排名，沒設觀察期
改了速度卻不知道有沒有效，因為沒設基準點。正確做法是記錄改動前的排名與 CWV，改完後觀察 7 到 28 天，再對比。沒有觀察期的最佳化，等於閉著眼睛開車。這也呼應改善 SEO時該有的紀律：動一刀、看一刀、再決定下一刀。
AI 搜尋時代的速度策略：Google AI Overview 出現後要調整什麼
AI 搜尋普及後，速度策略的「基本盤」沒變，Core Web Vitals 一樣要過門檻，但優先級要微調。行動版速度的份量更重，因為 AI 搜尋大量發生在手機上；同時要確保頁面結構清晰、關鍵答案放在開頭，讓 AI 爬蟲快速抓到重點。簡單說，速度仍是地基，但 AI 時代要把「結構化內容」與「行動版體驗」的優先級往上提。
有個常被忽略的細節：AI 引擎抓頁面跟傳統 Googlebot 一樣吃速度。頁面太慢，爬蟲在有限時間內抓不完整內容，AI 自然引用不到你。這代表速度最佳化的目標不只是人類讀者，還包括決定要不要引用你的 AI 系統。把首屏關鍵答案、結構化標記放好，等於幫 AI 省下抓取時間，也提高被收進答案的機率。
行動版權重持續上升
Google AI Overview與 AI Mode 的查詢大量來自手機，行動版的速度與體驗比過去任何時候都關鍵。如果你還在用桌機版做決策，等於在跟一半的流量對賭。行動優先不是口號，是 2026 年的生存條件。
結構化內容：答案放開頭，讓 AI 抓得到
AI 爬蟲跟傳統爬蟲一樣，都希望用最少的資源抓到最準的答案。把結論寫在開頭（Answer-First）、用 H2/H3 與清單組織內容、加上結構化資料標記，這些做法同時對AEO（答案引擎最佳化）和速度友善。頁面結構清楚，AI 不用翻完整頁就能抓到重點，等於變相減少了「認知載入時間」。這也是 GEO 與 AI SEO 在 2026 年的核心戰場。
INP 在 AI 時代更重要
互動卡頓會讓使用者直接跳出，而跳出訊號會回頭影響 Google 對頁面品質的判斷，包括 AI 要不要引用你的內容。INP 這個指標在 AI 時代的份量只會更高，不會更低。把它顧好，等於同時照顧了使用者體驗與 AI 引用的資格。這也呼應了 Google Web Guide 強調的方向：基礎體驗沒做好，再多 AI 最佳化都是空中樓閣。
不要為了 AI 放棄基礎 SEO。速度、內容、連結這三件事仍是地基，AI 搜尋 SEO 指南講的結構化、可引用性，是建立在地基之上的加值。順序錯了，加再多 AI 戰術也撐不起排名。
網頁速度與 SEO 排名的常見疑問（FAQ）
整理 6 個最常被問的疑問，每題直接給結論。如果想看更廣的SEO 入門脈絡，這些答案會串得起來。
行動版跟桌面版的速度，到底看哪個？
看行動版。Google 採行動優先索引（Mobile-First Indexing），排名判斷以行動版內容與體驗為準。桌面版分數漂亮不等於手機版沒問題，每次檢測都先看行動版那一欄。想搞懂背後機制，可以讀行動優先索引的完整說明。
PageSpeed Insights 分數多少算及格？
沒有絕對的及格分數。真正要看的是 Core Web Vitals 三指標是否過門檻（LCP≤2.5 秒、INP≤200 毫秒、CLS≤0.1），Lighthouse 分數 90 以上已經很夠了，不必死磕到 100。分數是診斷參考，CWV 門檻才是及格線。
CWV 過了門檻之後，還要做什麼？
把心力轉回內容、關鍵字、內外部連結。CWV 過門檻代表速度這個訊號已經及格，繼續最佳化的邊際效益很低。這時去補頁面 SEO、內部連結、E-E-A-T，回報率會高得多。
改善速度之後，多久能看到排名變化？
通常觀察 7 到 28 天，而且前提是「速度原本就是瓶頸」。如果你的網站 CWV 本來就全綠，排名卡住的原因根本不是速度，改再多速度也不會動。設好基準點再觀察，才看得出因果。
免費工具夠用嗎？一定要付費嗎？
多數網站，PageSpeed Insights 加 Search Console 就夠了，都是 Google 官方免費工具，資料直接來自排名系統。想看更細的使用者行為，再搭配 Google Analytics 即可；想觀察關鍵字趨勢變化，Google Trends 是免費補充。付費工具的價值在大量監控與歷史追蹤，小站用不到那個量級。
INP 跟 FID 差在哪？為什麼現在只看 INP？
FID 只量測使用者「第一次」互動的延遲，INP 量測整個工作階段中所有互動的最差表現。INP 更貼近真實體驗，所以 Google 在 2024 年 3 月用 INP 取代了 FID。現在只需要關注 INP，不用再回頭研究 FID。
結語：先把 Core Web Vitals 顧過門檻，再回去打仗
講了這麼多，其實只有一個行動訊號：先確認你的 Core Web Vitals 三指標是不是全綠，不是就按 WordPress 五層清單動手；是了，就把心力轉回內容與連結，別再跟那個 Lighthouse 分數過不去。速度是地基，地基穩了，上面蓋的主題叢集、站外 SEO、SERP 排版策略才站得住。
到頭來還是提醒一句，如果你不知道該從哪個指標先動手，回到一個原則：哪個指標紅字就先處理哪個，不要一次想全部解決。速度最佳化做完，記得給它 7 到 28 天的觀察期，配合 Search Console 的實地 CWV 報告追蹤變化。沒有觀察期的最佳化都是盲打，有觀察期才知道這一刀砍得對不對。如果你正在煩惱整體策略該怎麼排優先順序，零點擊搜尋與 AI 引用的流量佈局也值得一起盤點，會比單獨死磕速度清楚很多。需要有人幫你把網站的速度、內容、連結一起體檢，也歡迎找我們聊聊，至少能幫你少花半年冤枉錢。
