多數人心裡的「網頁速度」，還停留在快或慢的籠統印象，或者乾脆用 PageSpeed Insights 那個 0 到 100 分的數字打發，覺得分數愈高，網站就愈沒問題。但 Google 用來判斷網頁速度、進而影響 SEO 排名的方式，其實跟這個直覺差得很遠：它早就把「網頁速度」拆解成幾項具體的評估指標，寫進了排名系統裡，不是看你那個分數多漂亮。
只盯著分數衝高，反而容易抓錯重點，把力氣花在真正不影響排名的地方，卻漏掉 Google 真正拿去計算的那幾個環節。要真的看懂這件事，得先確認網頁速度算不算真正的排名因素，再看 Google 具體怎麼量這件事，最後才回到怎麼從這些指標下手改善，而不是只靠一次 PageSpeed 檢測的分數決定要不要動手。
最根本的問題是，網頁速度算不算一項真正的排名因素？
網頁速度真的是 SEO 排名因素嗎？
這件事 Google 已經做了超過十年，不是這一兩年才開始重視。2010 年 4 月，Google 官方部落格公告桌面版搜尋會把網站載入速度納入評分依據，理由很直接，使用者不喜歡等待，速度慢的網站在搜尋結果裡會被排到後面。2018 年 1 月，Google 進一步宣布把同樣的邏輯延伸到行動版搜尋，這項被稱為「速度更新」（Speed Update）的調整在同年 7 月正式生效，開始影響行動搜尋結果。到了 2021 年，Core Web Vitals 三項指標正式併入「頁面體驗」訊號，成為排名系統的一部分。從桌面版到行動版，再到把速度拆成三個可測量的具體指標，Google 對網頁速度的重視程度是逐年擴大的，不是最近才心血來潮。
這件事有多被當真？Google 的 John Mueller 就曾在 Reddit 上，直接回應外界「Core Web Vitals 只是兩個頁面平手時才拿出來用的加分項」這種質疑，他的原話是「It is a ranking factor， and it’s more than a tie-breaker， but it also doesn’t replace relevance.」，翻成中文，大致是速度確實是一項排名因素，而且份量比單純平手決勝更重，但它同樣不會取代內容本身的相關性。這句話把力道講得很清楚，速度不是拿來決定「兩個差不多的頁面誰贏誰輸」的小細節而已；但它也劃出了一條界線，速度優化的天花板，是在內容同樣優秀的頁面裡，跑得更快的那個勝出，內容本身寫得差，不會因為網站跑得快就翻盤。Mueller 在同一次討論裡也提到，Core Web Vitals 帶來的效益不只反映在排名上，使用者實際使用網站的體驗、願不願意留下來、下不下單，同樣受它左右，這條線索留到後面看實際案例時會更清楚。
除了直接影響排名分數，速度還有一條容易被忽略的間接路徑。Google 官方的檢索預算（crawl budget）文件裡提到，如果 Google 能更快載入、算繪你的頁面，就有機會讀到網站上更多的內容。反過來說，載入效率差的網站，Google 願意花在它身上的檢索資源就會變少，內容可能連被檢索、被排名的機會都拿不到。速度好不好，不只決定排名分數的高低，也決定了網站有沒有機會先被 Google 看見。
Core Web Vitals：把網頁速度拆成三個可測量的指標
Google 衡量網頁速度，用的不是一個籠統的「快不快」，而是把使用者瀏覽網頁的體驗拆成三個不同階段：主要內容多快出現、點擊或輸入之後多快有回應、畫面在載入過程中穩不穩定。Google 針對這三個階段各訂出一項指標，統稱 Core Web Vitals（核心網頁指標），是「頁面體驗」這個更大排名訊號底下的子集合。
三個指標各自都有一個「良好」門檻，而且要「同時」達標才算過關，不是任一項表現特別突出就能抵掉其他兩項的不足。這也是很多人容易誤解的地方，以為某一項分數高，整體體驗就沒問題，實際上 Google 是三項一起看的。
LCP：使用者要等多久，才看得到主要內容？
LCP（Largest Contentful Paint，最大內容繪製）測的是頁面上最大、最主要的內容區塊完整顯示出來的時間，通常是首屏的大圖或標題文字。Google 的門檻是 2.5 秒以內算良好，超過 4 秒就會被判定不佳。常見拖慢 LCP 的原因包括伺服器回應太慢、圖片檔案過大，以及 CSS 或 JavaScript 阻塞了主要內容的繪製。
INP：點擊、輸入之後，網頁多快有反應？
INP（Interaction to Next Paint，下一次繪製互動）在 2024 年 3 月正式取代了原本的 FID（First Input Delay，首次輸入延遲），成為 Core Web Vitals 的互動指標。換掉的原因不難理解，FID 只測使用者「第一次」互動的延遲，可是多數人瀏覽一個頁面時，點擊、輸入的次數遠不只一次；INP 會持續觀察整個造訪過程裡所有的點擊與輸入，取其中反應最慢的一次作為代表數值，更貼近真實的使用情境。Google 的良好門檻是 200 毫秒以內，超過 500 毫秒就算不佳，之所以看起來這麼嚴格，是因為它抓的已經是使用者體感最差的那一次互動。
CLS：畫面會不會忽然跳動、位移？
CLS（Cumulative Layout Shift，累積版面配置偏移）測的是頁面載入過程中，各個元素忽然移位造成的視覺不穩定程度。Google 的良好門檻是 0.1 以下，超過 0.25 就算不佳，常見成因是圖片沒有預先保留尺寸、廣告或字體延遲載入，導致使用者正要點的按鈕，突然被擠到別的地方去。這種問題不一定會拖慢速度本身，卻會直接影響使用體驗，甚至讓人誤觸到不想點的東西。
PageSpeed 分數高，不代表 SEO 沒問題
這是網站經營者最容易誤解的地方之一。以為 PageSpeed Insights 打出的分數愈高，SEO 就愈有保障，於是把「衝到 90 分以上」當成優化目標。但這個分數跟 Google 實際拿來計算排名的資料，其實來自完全不同的兩個來源，分數高不代表 SEO 就真的沒問題。
PageSpeed Insights 和 Lighthouse 這類工具，測的是「實驗室數據」（lab data）：在固定的模擬裝置、固定的網路條件下跑一次頁面載入，算出一個分數。這種數據很適合用來抓問題、比較改版前後的差異，卻不是 Google 排名真正採用的依據。
真正會影響排名的，是「真實使用者數據」（field data），業界通常稱為 CrUX（Chrome User Experience Report，Chrome 使用者體驗報告）。CrUX 收集的是實際用 Chrome 瀏覽器造訪你網站的真實訪客，各自的載入體驗，取其中第 75 百分位的表現，來判斷這個網站算不算「良好」。也就是說，就算 PageSpeed 分數再漂亮，只要多數真實訪客，尤其是網路較慢、裝置較舊的那一群，體感是慢的，Google 依然會判定這個頁面體驗不佳。
這裡還有一個常被忽略的前提，Google 排名判斷採用的是 Mobile-First Indexing（行動優先索引），也就是以行動版的內容與體驗為準。這也是為什麼檢測網頁速度時，一定要看行動裝置那個分頁，桌面版分數再漂亮，都不代表手機版沒問題。
PageSpeed Insights 還要不要用？
雖然 PageSpeed 分數不是排名依據，PageSpeed Insights 依然是免費又方便的第一線診斷工具，只是心態要調整，不必再把它當成排名指標，而是當成健檢報告來用。操作只要三個步驟：
- 輸入網站網址
- 點選「分析」
- 查看分數與診斷建議
畫面上方可以切換「行動裝置」與「電腦」兩個分頁，分別檢測兩種裝置的表現。承接前面提到的 Mobile-First Indexing，檢測時要優先看行動裝置那一分頁，這才是 Google 判斷排名時真正在意的版本，桌面版可以之後再對照參考。
拿到分數時，有個實務眉角容易被忽略，分數常常會被網站本身以外的因素拖累。分析工具、廣告聯播、嵌入影片、線上客服外掛，這些第三方腳本都會拉低 PageSpeed 分數，不是單靠換主機、壓圖片就能一路衝到滿分。心態上也不必執著特定門檻，而是把它當成一份健檢報告，優先處理有把握的項目，像圖片壓縮、程式碼精簡；至於一些看不懂的技術性診斷項目，可以先記下來，交給協助架站的工程團隊評估。真正該長期追蹤的成效指標，是 Google Search Console 裡「網站使用體驗」報表所呈現的真實使用者數據，而不是 PageSpeed 這一次跑分的結果。
從三個真實案例，看網頁速度優化的實際效益
排名因素聽起來還是有點抽象，那麼實際投入時間優化網頁速度，換回來的是什麼？以下三個公開可查的真實案例，分別對應不同情境。
樂天集團旗下、銷售日用品的線上商店 Rakuten 24，分析真實使用者資料後發現，良好的 LCP 表現，最多能讓轉換率提升 61.13%、每位訪客平均收益提升 26.09%。他們接著針對到達頁進行了一個月的 Core Web Vitals 優化 A/B 測試，優化版本相較原始版本，單次造訪收益提升 53.37%、轉換率提升 33.13%、平均訂單價值提升 15.20%。
俄語地區主要入口網站之一的 Mail.ru，花了數個月時間優化網頁體驗，CLS 達到「良好」門檻的網頁比例從 33% 提升到 93%，等於成長了 181%；平均工作階段時間提升 2.7%，核心版面的轉換率提升超過 10%，其中行銷橫幅的點閱率，因為算繪時間縮短而提升了 17.4%。
規模更大的一份研究來自 Google 委託 Deloitte 與 fifty-five 進行的「Milliseconds Make Millions」，涵蓋 37 個歐美品牌網站、超過 3,000 萬筆使用者工作階段。研究發現，四項速度指標只要各自改善 0.1 秒，零售業的平均消費金額就能提升 9.2%、旅遊業的訂房率能提升 10%，專門產生待開發客戶名單的網站，使用者走到表單填寫頁的比例能提升 21.6%。
這些數字談的不是排名往前跳幾名這種模糊說法，而是轉換率、營收、點閱率這些可以直接拿去跟老闆報告的商業指標，呼應前面 Mueller 提到的，Core Web Vitals 不只是排名因素，也直接牽動使用者願不願意留下來、願不願意下單。
想全面提升網頁體驗，可以從哪些方向下手？
清楚指標的定義之後，接下來的重點是先弄清楚自己的網站卡在哪一項，再對症下手，而不是四個方向一次亂調，分不清哪個動作真的有效。
- 伺服器回應太慢：主要對應的是 LCP。伺服器回應的第一時間，是所有指標共同的起點，如果主機等級偏低、資源被大量其他網站瓜分，這裡通常是最先該檢查的地方。
- 圖片太大、程式碼太肥：同樣主要拖累 LCP。壓縮圖片、精簡 CSS 與 JavaScript，是常見且見效快的做法。
- 外掛或程式碼佔用主執行緒：影響的是 INP。載入大量非必要的 JavaScript，會讓使用者點擊、輸入時感覺到延遲，這時該檢查有沒有功能重複的外掛、或不必要的第三方腳本。
- 圖片或廣告沒有預留版面空間：CLS 最常見的成因。在圖片、嵌入內容上正確設定寬高比例，多半就能大幅改善。
常見的誤區是，首屏的內容，也就是 LCP 元素，絕對不能設定延遲載入（lazy load）。延遲載入只該用在使用者要往下捲動才會看到的圖片，用在首屏，等於自己拖慢了 Google 判斷 LCP 的那個元素，反而讓分數變差。
網頁速度不是為了衝出一個好看的分數，而是三個具體、會被 Google 實際拿去計算排名、也會被真實訪客用行為投票的體驗指標，LCP、INP、CLS。建議的做法是，先用 Google Search Console 的「核心網頁指標」報表，找出自己的網站卡在哪一項，按優先順序逐一排查優化，會比死盯著單一分數更有效率，也更貼近 Google 真正在意的使用者體驗。這三個指標各自更深入的排查方法，都還值得再各自展開來講。