網站太慢會影響排名，但沒有多數人想的那麼直接。Google 用 Core Web Vitals 三項指標衡量網頁體驗，並把它列為排名系統參考的訊號之一；可是內容與搜尋需求的相關性仍然優先，速度好不會讓答非所問的網頁排上來。速度真正的代價常在排名之外：手機上等太久，訪客在看到內容前就離開了。所以該做的不是追分數，而是先量出「慢在哪一段」，再決定該找主機、找設計，還是改內容。
這篇把三項指標的及格線、量法與改善順序一次講清楚，並附上我們 2026 年 9 月 30 日用 Lighthouse 12.8 實測本站 mani.tw 的數字——包括一個常被忽略的結果：本站首頁在手機模擬下最慢的那一段，跟圖片和主機都無關。
網站太慢真的會掉排名嗎？Google 怎麼算這三項指標
Core Web Vitals（核心網頁指標）是 Google 定義的三個使用者體驗數字，分別量「主要內容多久出現」「點了之後多久有反應」「畫面會不會亂跳」：
| 指標 | 量的是什麼 | 良好 | 需要改善 | 不佳 |
|---|---|---|---|---|
| LCP 最大內容繪製 | 畫面中最大的文字區塊或圖片，多久畫出來 | 2.5 秒以內 | 2.5～4 秒 | 超過 4 秒 |
| INP 與下一次繪製的互動 | 點按鈕、開選單之後，畫面多久有反應 | 200 毫秒以內 | 200～500 毫秒 | 超過 500 毫秒 |
| CLS 累計版面配置位移 | 載入過程中版面意外跳動的程度 | 0.1 以內 | 0.1～0.25 | 超過 0.25 |
INP 在 2024 年 3 月 12 日取代舊的 FID，成為正式的核心網頁指標。網路上還在教「FID 100 毫秒」的文章已經過時。
Google 評分時看的不是你用工具測一次的結果，而是真實 Chrome 使用者過去 28 天的資料（Chrome 使用者體驗報告，簡稱 CrUX），每項取第 75 百分位數：也就是四個訪客裡有三個的體驗要達到良好，才算良好。行動版與桌機版分開算，三項都良好，那一組網址才算通過。
這帶出兩個實務上的結論：
- 流量不夠的網站，Google 根本沒有你的現場數據。Search Console 的「核心網頁指標」報表會顯示「使用資料不足」。本站 2026 年 8 月查詢時，行動版與桌機版都是這個狀態。這種情況下，速度對排名的作用更談不上，但對訪客體驗的影響一樣存在。
- 速度是「同分比較」時的加分，不是主菜。兩個頁面都回答了搜尋者的問題、內容品質接近，體驗好的那一頁比較有優勢；如果內容本身沒回答問題，把 LCP 從 4 秒壓到 1 秒也救不了排名。所以排優先順序時，先確認內容能不能被讀到、能不能回答問題（自我檢查方式見網站 AI 體檢），速度排在後面，這個順序是刻意的。
Core Web Vitals 怎麼量？現場數據與實驗室數據不要混著看
量 Core Web Vitals 的工具分兩類，現場數據告訴你「真實訪客的體驗如何」，實驗室數據告訴你「在固定條件下慢在哪裡」。前者用來評分，後者用來找原因，兩者不能互相取代：
| 工具 | 數據類型 | 適合用來 |
|---|---|---|
| Search Console「核心網頁指標」 | 現場（CrUX，28 天） | 看全站哪幾組網址不及格、修完之後做驗證 |
| PageSpeed Insights | 上半部現場、下半部實驗室 | 單一網址的快速檢查；上半部沒資料就只剩實驗室分數 |
| Chrome 開發人員工具的 Lighthouse | 實驗室 | 找 LCP 是哪個元素、卡在哪一段、哪支腳本拖時間 |
| Chrome 開發人員工具的「效能」面板 | 自己操作的實測 | 在本機量 INP 的方式：實際點按鈕、開選單看反應時間 |
要特別知道的是，實驗室工具量不到 INP，因為 INP 需要真人操作。Lighthouse 改用「總封鎖時間」（TBT）當替代指標：載入過程中主執行緒被長工作佔住、無法回應使用者的時間總和，大約 200 毫秒以內算良好。
本站實測：同一個首頁，數字差了將近三倍
我們在 2026 年 9 月 30 日上午，用 Lighthouse 12.8.2 對本站幾個頁面各跑了數次。Lighthouse 的行動版預設會模擬慢速 4G 與中階手機：往返延遲 150 毫秒、頻寬約 1.6 Mbps、處理器降速 4 倍。結果如下：
| 頁面與條件 | LCP | TBT | CLS | 傳輸量／請求數 |
|---|---|---|---|---|
| 首頁，行動版模擬（第 1 次） | 4.2 秒 | 93 毫秒 | 0 | 250 KB／9 個 |
| 首頁，行動版模擬（第 2 次） | 4.1 秒 | 99 毫秒 | 0 | 250 KB／9 個 |
| 首頁，桌機版模擬 | 1.1 秒 | 0 毫秒 | 0.001 | 250 KB／9 個 |
| 首頁，不模擬降速（第 1 次） | 2.4 秒 | 0 毫秒 | 0 | 251 KB／9 個 |
| 首頁，不模擬降速（第 2 次） | 1.4 秒 | 0 毫秒 | 0 | 250 KB／9 個 |
| 文章頁，行動版模擬 | 4.2 秒 | 108 毫秒 | 0 | 248 KB／9 個 |
| 客戶案例頁，行動版模擬 | 4.5 秒 | 96 毫秒 | 0 | 1,018 KB／20 個 |
這張表至少說明三件事：
- 同一頁、同一台電腦、同樣設定，連測兩次就差了 1 秒（不模擬降速的 2.4 秒與 1.4 秒）。實驗室數字受當下網路與電腦負載影響很大，至少量三次、取中間值，不要拿單次結果下結論，更不要拿別人電腦上跑出的分數跟你的比。
- 行動版模擬的 4 秒多，不等於真實訪客要等 4 秒。模擬條件刻意設得嚴苛，用來放大問題；真實訪客的體驗要看現場數據。但反過來說，模擬結果超過 4 秒，代表網路差、手機舊的那群訪客確實會等比較久，值得找原因。
- 頁面重量多四倍，LCP 只慢 0.3 秒。客戶案例頁有 11 張作品縮圖、總傳輸量 1 MB，是首頁的四倍，LCP 卻只從 4.2 秒變成 4.5 秒。原因在下一節：它的 LCP 元素根本不是那些縮圖。
LCP、INP、CLS 各卡在哪？先找出元素與階段再動手
多數人一看到「網站太慢」就去壓縮圖片或升級主機，但這兩件事常常都打不到真正的瓶頸。該先做的，是在 Lighthouse 報告裡找到「最大內容繪製元素」，看它是什麼、時間花在哪一段。
LCP：拆成四段，只改占比最大的那段
LCP 的時間可以拆成四個階段，每一段對應不同的負責人與做法：
| 階段 | 意思 | 常見原因 | 通常誰處理 |
|---|---|---|---|
| 首位元組時間（TTFB） | 伺服器開始回傳網頁之前的等待 | 主機效能不足、沒有快取、資料庫查詢慢、多段轉址 | 主機與程式 |
| 資源載入延遲 | 瀏覽器多晚才發現要下載 LCP 圖片 | 主圖寫在 CSS 背景或由 JavaScript 插入、主圖被設成延遲載入 | 網頁設計 |
| 資源載入時間 | LCP 圖片本身下載多久 | 圖片太大、沒用 WebP 或 AVIF、手機也下載桌機尺寸 | 網頁設計與內容編輯 |
| 元素轉譯延遲 | 資源到齊之後，多久才真正畫出來 | 阻擋轉譯的 CSS 與字型、版面計算太重、腳本佔住主執行緒 | 網頁設計與前端 |
本站首頁的實測拆解是這樣的：LCP 元素是首屏那段服務說明文字，不是圖片，所以「資源載入延遲」與「資源載入時間」都是 0；行動版模擬 4.2 秒裡，首位元組時間約 0.65 秒（16%），元素轉譯延遲約 3.5 秒（84%）。同一段時間裡，主執行緒花在樣式計算與版面配置上約 0.88 秒，是所有工作中最多的一項。
這個結果直接排除了兩個常見做法：
- 壓縮圖片救不了這一頁的 LCP，因為 LCP 元素是文字。客戶案例頁也一樣：LCP 元素是 10 KB 的 LOGO（WebP 格式、已標為優先載入），下面 11 張 50～98 KB 的作品縮圖再重，也不在 LCP 的路徑上。Lighthouse 估計把那些縮圖改成新格式可省下約 353 KB，這對手機流量是好事，但不是 LCP 的解法。
- 升級主機也救不了。模擬的 0.65 秒首位元組時間，大部分是模擬網路的連線往返，不是主機在運算。我們在同一天用 curl 對首頁連量 5 次，扣掉連線與加密交握之後，伺服器實際準備網頁的時間只有 8～14 毫秒，整個網頁壓縮後約 20 KB（原始 76 KB）。
反過來說，如果你的網站拆出來是首位元組時間占大宗，而且在正常網路下就超過 0.8 秒，那才是該檢查主機與程式的時候。主機端要怎麼分辨「是主機慢還是程式慢」，虛擬主機完整指南的變慢一節有分診方式；WordPress 網站則照WordPress 網站很慢怎麼辦的 8 個檢查順序，從主機層查到外掛層。
INP：兇手通常是 JavaScript，尤其是第三方腳本
INP 不及格，幾乎都是主執行緒被長時間佔住：點了按鈕，瀏覽器還在忙著跑別的腳本，畫面就晚了才反應。常見來源是聊天外掛、廣告與追蹤碼、大型輪播與動畫套件。
本站的例子：首頁 9 個請求、共 250 KB 的傳輸量裡，Google 分析的追蹤腳本就占了約 180 KB，超過七成，比網頁本身的 20 KB 大得多；Lighthouse 估計其中約 68 KB 在這一頁用不到。TBT 93 毫秒仍在良好範圍內，但這說明了一件事：你以為的「網站」，常常只是傳輸量裡的一小部分。改善 INP 的順序是：先列出所有第三方腳本並刪掉沒在用的，其次讓必要的腳本延後載入，最後才是把自家程式裡的長工作切短。
CLS：九成的問題是圖片沒寫尺寸
版面跳動最常見的原因有四個：圖片或影片沒有寫寬高、廣告與嵌入內容沒有預留空間、網頁字型載入後換字造成行高改變、以及在內容上方突然插入的橫幅或提示。
本站這次實測的幾個頁面，CLS 都在 0 到 0.001 之間，做法很單純：圖片都寫上 width 與 height，讓瀏覽器在圖片下載前就先留好位置。這是改善成本最低、效果最確定的一項，老網站升級改成 RWD 版面時就應該一併做好。
網站速度的改善順序：哪些是主機的事、哪些是網頁設計的事
把上面的判斷整理成一個固定順序。每一步都有「怎麼判斷」，做完一步再量一次，確認有效才往下：
改善 Core Web Vitals 的 6 個步驟
- 先看有沒有現場數據。Search Console 的核心網頁指標報表或 PageSpeed Insights 上半部有資料，就以它為準；顯示資料不足，就改用實驗室工具，並且接受「只能找原因、不能評分」。
- 找出 LCP 元素與四個階段的占比。是文字還是圖片？時間集中在首位元組時間、下載，還是轉譯？這一步決定後面要找誰。
- 首位元組時間在正常網路下超過 0.8 秒，才查主機與程式。先排除多段轉址（http、www 應該一次 301 到正式網址），再看快取與資料庫。
- LCP 是圖片：主圖不要延遲載入、加上優先載入標記、改用 WebP 並依螢幕寬度提供不同尺寸。LCP 是文字：減少阻擋轉譯的 CSS 與字型，把首屏需要的 CSS 直接內嵌在網頁裡，字型改成不阻擋顯示的載入方式。
- 盤點第三方腳本。每一支都問「現在還有人在看它的數據嗎」，沒有就拿掉。
- 補齊圖片與嵌入內容的尺寸，再用 Search Console 的「驗證修正」送出，等 28 天的監控期結束看結果。
分工上，第 3 步多半是主機與程式的事，第 4～6 步多半是網頁設計的事。問題在於這兩邊常常是不同廠商：主機商說「我們的伺服器回應只要幾十毫秒」，設計公司說「程式沒問題，是主機慢」，兩邊都拿得出數字，網站還是一樣慢。這也是為什麼我們在網頁設計公司怎麼挑一文裡建議，把「Core Web Vitals 達標」寫進交付清單，並講清楚由誰負責量測。
三個常見的錯誤做法
- 為了分數刪掉有用的功能。把詢價表單、產品圖片拿掉，分數會變好看，生意也會變少。分數是手段，不是目的。
- 裝一堆「加速外掛」疊在一起。快取、壓縮、延遲載入各裝一支，彼此重複處理，反而可能讓 LCP 圖片被延遲載入。一個功能只留一個負責的工具。
- 只在自己的電腦、公司網路上測。辦公室光纖與新電腦上看到的永遠很快，真實訪客很多是用手機在行動網路上開你的網站。至少用 Lighthouse 的行動版模擬看一次。
瑪尼國際成立於 2004 年，深耕逾 20 年、服務逾 500 家企業，同時做主機與網站，量得到伺服器端與瀏覽器端兩邊的數字。如果你的網站慢，但不確定是主機、程式還是版面的問題，可以交給我們的網站代管先量一次再說；要整站改版或重新網頁設計，從主機、程式到版面由同一個窗口負責的一條龍服務，就不會出現主機商與設計公司互相推的情況。主機方案可參考Linux 虛擬主機。
常見問題
Q：網站太慢會影響 Google 排名嗎？
會，但影響的方式跟多數人想的不一樣。Google 的排名系統會參考 Core Web Vitals 這類網頁體驗訊號，可是內容與搜尋需求的相關性仍然優先：速度好不能讓答非所問的網頁排上來，速度差也不會讓真正回答了問題的網頁消失。速度真正的代價常常在排名之外——手機上等超過幾秒，訪客在看到內容之前就離開了，詢價表單也就不會有人填。
Q：Core Web Vitals 三項指標的及格標準是多少？
LCP（最大內容繪製）2.5 秒以內為良好、超過 4 秒為不佳；INP（與下一次繪製的互動）200 毫秒以內為良好、超過 500 毫秒為不佳；CLS（累計版面配置位移）0.1 以內為良好、超過 0.25 為不佳。Google 以真實 Chrome 使用者過去 28 天的資料、取第 75 百分位數來判定，行動版與桌機版分開計算，三項都達到良好，該組網址才算通過。
Q：Core Web Vitals 改善後多久會在 Search Console 看到結果？
通常要四週左右。Search Console 的核心網頁指標報表用的是真實使用者過去 28 天的滾動資料，改善上線當天，舊的慢速紀錄還在統計範圍裡，要等新資料把舊資料替換掉，數字才會跟著變。修好之後可以在報表裡按「驗證修正」，Google 會用 28 天的監控期確認問題是否消失；流量不夠的網站則會顯示使用資料不足，這時只能用實驗室工具自己驗證。