網站慢不只讓訪客流失，更直接吃掉轉換與排名。本文從實證數據談起，拆解 Core Web Vitals 三指標(LCP、INP、CLS)的技術機制與判定門檻，說明真實使用者資料與第 75 百分位怎麼運作，並整理常見拖慢元凶、判斷誤區，以及不用工程師也能自己動手的檢查與改善方向。
搜尋平台不公開固定權重，也沒有能套用所有產業的流量或轉換增幅。以 Search Console、商家檔案與實際詢問紀錄建立基準，一次調整一個項目，再比較查詢、曝光、點擊與有效詢問，會比引用沒有原始資料的平均值可靠。
Google 到底怎麼把速度算進排名
很多人以為測速工具給的分數就是 Google 用來排名的依據，這是第一個要澄清的誤會。Google 判定的不是你某一次在辦公室電腦上跑出來的成績，而是真實使用者的體驗資料(field data)——它蒐集全世界瀏覽器使用者實際造訪你網站的紀錄，彙整成一份滾動 28 天的資料集。也就是說，重點不是「最快能多快」,而是「大多數人來的時候順不順」。
更關鍵的是它取的是第 75 百分位:要有七成五以上的造訪都落在「良好」區間，這個指標才算通過。這個設計很有工程上的道理——它逼你面對的是尾端體驗，而不是平均值。一個網站平均載入 2 秒聽起來不錯，但如果有三成訪客因為網路差、裝置舊而卡在 5 秒，你在 Google 眼中依然不及格。要提醒的是，速度只是 Google 上百個排名訊號的其中一環，它比較像同分時的那張門票：內容夠好、速度又通過的頁面，會贏過內容差不多、但慢半拍的對手。別指望把速度衝到滿分就一飛沖天，但也別讓它成為明明可以避免的扣分。
拆解 Core Web Vitals 三個核心指標
Google 把「使用者體驗」濃縮成三個可量測的指標，合稱 Core Web Vitals。搞懂它們各自在量什麼、被什麼拖垮，你才分得清問題出在前端、圖片，還是伺服器，而不是瞎槍打鳥。
LCP:主要內容多快出現
LCP(最大內容繪製)量的是頁面上最大那塊內容——通常是首圖或大標題——多久才畫出來，理想要低於 2.5 秒，超過 4 秒就算差。它其實是三段時間的總和：伺服器回應第一個位元組的時間(TTFB,理想低於 0.8 秒)、把圖片或字體等資源下載回來的時間，再加上瀏覽器實際繪製的時間。所以 LCP 慢，可能是主機太遠太弱、可能是首圖太肥、也可能是一堆 CSS/JS 擋在前面害內容出不來。前面那家餐廳就是最典型的「圖太肥」型。
INP:點下去多快有反應
INP(互動到下次繪製)在 2024 年 3 月正式取代了舊的 FID,量的是你點按鈕、展開選單、送出表單之後，畫面多快給出視覺回應，理想低於 200 毫秒，超過 500 毫秒算差。它幾乎是純粹的 JavaScript 問題：瀏覽器處理互動、更新畫面，都得用到主執行緒(main thread),而如果這條唯一的通道正被一段跑很久的長任務(long task)佔住，你的點擊就只能排隊等它跑完，體感上就是「按了沒反應、卡一下才動」。INP 一直是三項裡最難搞定的一項，因為它考驗的不是靜態載入，而是網站在互動當下的運算負擔——第三方追蹤碼、聊天外掛、過度肥大的前端框架，都是常見兇手。
CLS:畫面會不會亂跳
CLS(累積版面位移)量的是頁面載入過程中，元素會不會突然位移害你點錯，理想低於 0.1,超過 0.25 算差。最常見的情況是圖片沒有事先宣告寬高，瀏覽器不知道要留多少位置，等圖一載進來就把下面的文字整個往下擠；廣告、延遲載入的字體、後插入的橫幅，也都會製造這種「手指懸空點擊卻撲空」的惱人體驗。CLS 通常是三項裡最好修的，因為多半只要把尺寸先講清楚就解決了。
把網站拖慢的幾個真兇
- 沒有節制的圖片:手機原圖動輒 4 到 6 MB,是中小商家網站最普遍、也最好解的病灶。同一張照片，轉成 WebP 通常能比 JPEG 再小 25% 到 34%,換成更新的 AVIF 甚至能省下 30% 到 50%,肉眼卻幾乎看不出差別。
- 阻擋渲染的 CSS 與 JavaScript:瀏覽器讀到還沒標記為延後的腳本或樣式，會先停下來把它處理完才繼續畫頁面。一堆非必要的腳本擠在最前面，內容自然出得慢。
- 塞爆主執行緒的第三方碼:分析工具、再行銷像素、客服機器人、社群外掛，每一個都在搶那條唯一的運算通道，這是 INP 過不了關的最大來源。
- 沒有快取、沒有 CDN:每位訪客每次都回到那台原始主機重抓一次，海外或離主機遠的客人特別吃虧；主機本身太弱、太遠，TTFB 就先輸在起跑點。
幾個容易踩的判斷誤區
- 只盯著測速分數衝滿分:工具給的分數多半是「實驗室資料(lab data)」,在固定條件下模擬出來，方便除錯，但 Google 排名看的是真實訪客的 field data。兩者常常對不上，拿實驗室 95 分沾沾自喜，真實使用者卻卡在 INP,是很常見的錯位。
- 改完就期待馬上見效:因為 field data 是滾動 28 天的累積，你今天修好，官方報表上的通過與否可能要等好幾週才反映出來。別改兩天沒動靜就以為白做。
- 只測桌機版:南台灣的在地客戶九成以上是拿手機找你，手機的處理器與網路都比桌機弱，一定要以行動版為準。
- 盲目追最新格式:AVIF 檔案更小沒錯，但編碼運算比 WebP 慢上好幾倍，相容性也略低一截；實務上多半是「優先給 AVIF、退回 WebP、再退回 JPEG」的多層備援，而不是一律換成最新的就好。
不靠工程師，自己就能先檢查
把網址丟進 Google PageSpeed Insights,它會同時給你兩塊資訊：上半部是真實使用者的 field data(有沒有通過三項指標),下半部是實驗室模擬的診斷與改善清單，而且行動版與桌機版分開列。想看得更細，用瀏覽器內建的 Lighthouse 再跑一次，它會把每個拖累項目和預估可省下的時間攤開給你看。如果你有架設 Google Search Console,裡面的「網站使用體驗核心指標」報表會直接告訴你哪些頁面群組出問題、影響多少網址，這是唯一從 Google 官方角度回看自己網站的地方。記得每一項都先看「行動版」。
投報率最高的幾個改善方向
- 先從圖片下手:壓縮並轉成 WebP 或 AVIF、在標籤上明確寫死寬高(直接解掉 CLS)、第一屏以外的圖片延遲載入(lazy load)。光是把那張 6 MB 的招牌菜壓到 200 KB 上下，前面那家餐廳的 LCP 就從 5 秒多掉到 2 秒內，跳出的客人肉眼可見地少了。
- 把靜態資源交給快取與 CDN:圖片、樣式、腳本這類不常變動的檔案設定長時間快取，前面再擺一台 CDN 就近供應，回頭客和遠地客都受惠，也替原始主機卸掉負擔。
- 精簡並延後 JavaScript:把非必要的腳本標記為延後或非同步、拆分程式碼只載入當下需要的部分、清掉沒在用的套件與第三方碼，把主執行緒讓出來，INP 才有機會過關。
- 顧好伺服器這條起跑線:選對主機等級與機房位置、開啟伺服器端壓縮、對關鍵資源預先連線與預先載入，把 TTFB 壓進 0.8 秒以內。
查核資料
- Web Vitals web.dev · 2026-08-12
