網站速度怎麼測、怎麼優化？Core Web Vitals 與 PageSpeed Insights 解讀

2026-10-14

網站速度是 Google 排名的考量之一，但不會蓋過內容相關性。用 PageSpeed Insights 先看實際使用者資料：LCP、INP、CLS 三項 Core Web Vitals 都達標，就不必追 90 分；沒達標，從不合格的那一項修起，常見的原因是照片檔案太

關鍵要點

Core Web Vitals 是 Google 排名系統的考量之一，但 Google 會優先顯示最相關的內容
判斷網站速度好不好，先看 PageSpeed Insights 的實際使用者資料，不是效能分數
三項指標的良好門檻：LCP 2.5 秒內、INP 低於 200 毫秒、CLS 低於 0.1
速度優化先處理照片格式與尺寸、圖片預留空間、第三方程式碼與主機回應
Google 以手機版內容建立索引，測速一律先看行動裝置的結果

PageSpeed Insights 一測，分數一片橘紅，接著就開始懷疑是不是速度拖累了排名、要不要整個網站重做。先別急：PageSpeed 的分數和 Google 實際用來評估體驗的指標不是同一件事，很多網站分數不到 90，Core Web Vitals 卻早就通過。弄清楚該看哪個數字，才知道要不要修、先修哪裡。

網站速度會影響 SEO 嗎？會，但內容優先

網站速度會影響 SEO，但影響程度沒有內容相關性大。Google 說明，Core Web Vitals 和網頁體驗的其他層面，都是核心排名系統決定排名的考量要素（瞭解 Core Web Vitals 和 Google 搜尋結果）；同時也說明，沒有單一的網頁體驗排名信號，Google 會優先顯示最相關的內容，在相關選項很多時，良好的網頁體驗才有助於脫穎而出（瞭解 Google 中的網頁體驗）。

換句話說，一篇內容不夠好的文章，網站再快也排不上去；但兩篇內容差不多時，體驗較好的那篇比較有優勢。速度和其他排名因素的關係，見Google 排名因素。

網站速度怎麼測？用 PageSpeed Insights

測網站速度常用的是 Google 免費的 PageSpeed Insights，輸入網址就能看到兩種資料：實際使用者資料是真實 Chrome 使用者過去 28 天的體驗，Core Web Vitals 是否通過以它為準；實驗室資料是 Lighthouse 在模擬環境跑出的效能分數，用來找問題，不代表使用者實際感受。

到 PageSpeed Insights 輸入網址，結果分成行動裝置和電腦兩個分頁，上下兩區資料要分開看（關於 PageSpeed Insights）：

區塊	資料來源	用途
上方：實際使用者體驗	Chrome 使用者體驗報告（CrUX），過去 28 天的真實使用者	判斷 Core Web Vitals 是否通過
下方：診斷效能問題	Lighthouse 在模擬環境測一次	看效能分數（0–100）與改善建議，用來找原因

PageSpeed Insights 一次只測一個網址；要看整個網站，用 Search Console 的 Core Web Vitals 報表。這份報表根據實際使用者資料，把類似的網頁分成網址群組，依行動裝置與電腦標出「良好」「需要改善」「不良」（Core Web Vitals 報告）。Search Console 的其他報表，見Google Search Console 教學；GTmetrix 等其他測速工具，整理在SEO 工具推薦。

💡 萬智匯提提你：首頁分數好，不代表文章頁、產品頁也好。每種版型的網頁各挑一頁來測，才看得出問題出在哪一種頁面。

Core Web Vitals 是什麼？三項體驗指標

Core Web Vitals 是 Google 用來衡量實際使用者體驗的三項指標：LCP（最大內容繪製）衡量載入速度，良好門檻是 2.5 秒內；INP（與下一個顯示的內容互動）衡量回應速度，良好門檻是低於 200 毫秒；CLS（累計版面配置位移）衡量畫面穩定性，良好門檻是低於 0.1。

三項指標都以實際使用者資料的第 75 百分位判斷，三項都良好，才算通過 Core Web Vitals 評估（關於 PageSpeed Insights）。

指標	衡量什麼	良好	需要改善	不佳
LCP	畫面中最大的圖片或文字區塊多久顯示	2.5 秒內	2.5–4 秒	超過 4 秒
INP	點擊、輕觸、按鍵後，畫面多久有反應	200 毫秒內	200–500 毫秒	超過 500 毫秒
CLS	載入過程中版面跳動的程度	0.1 以下	0.1–0.25	超過 0.25

LCP：主視覺多久出現

LCP 量的是使用者打開網頁後，最大的那塊內容（通常是首屏大圖或標題）多久顯示出來。拖慢 LCP 的常見原因是首屏圖片檔案太大、主機回應慢，以及把首屏大圖設成延遲載入（loading=“lazy”），讓瀏覽器等到最後才載入它（最佳化 LCP）。

INP：點了之後多久有反應

INP 觀察使用者在網頁上所有點擊、輕觸、鍵盤操作的延遲，取最長的那一次（忽略離群值）（INP 說明）。INP 在 2024 年 3 月 12 日取代原本的 FID（首次輸入延遲），成為 Core Web Vitals 指標（web.dev）；網路上還在講 FID 的文章已經過時。INP 差，多半是 JavaScript 太多、主執行緒被長時間占用，點了按鈕要等一下才有反應。

CLS：畫面會不會亂跳

CLS 量的是載入過程中，內容突然往下推或位移的程度，例如正要點按鈕，上方的廣告或圖片載入完把按鈕擠走。常見原因是圖片、影片沒有設定寬高，以及廣告、嵌入的 YouTube 或 Google 地圖沒有預留空間（改善 CLS）。

PageSpeed 分數低要修嗎？先看實際資料

PageSpeed Insights 效能分數低，不一定要修。判斷依據是實際使用者資料：LCP、INP、CLS 三項都良好，Core Web Vitals 就已通過；只有某一項需要改善或不佳時，才針對那一項處理。

可以照這個順序判斷：

實際使用者資料三項都「良好」：不需要為了把效能分數拉到 90 分而大改網站，人力先放在內容與其他項目。
有任何一項「需要改善」或「不佳」：LCP 不合格先查首屏圖片與主機；INP 不合格查 JavaScript 與外掛；CLS 不合格查圖片尺寸與廣告版位。
網站太新或流量太少，沒有實際使用者資料：PageSpeed Insights 會改用整個網站的資料；連整個網站都沒有資料時，才以實驗室資料的建議當參考（關於 PageSpeed Insights）。

以萬智匯官網首頁的電腦版測試為例，實驗室的效能分數是 85 分，LCP 1.4 秒、CLS 0、總封鎖時間 230 毫秒。LCP 1.4 秒其實已經低於 Core Web Vitals 2.5 秒的良好門檻，卻被標成橘色，原因是 Lighthouse 對電腦版用另一套比較嚴格的評分標準（Lighthouse 效能評分）。實驗室分數的顏色和 Core Web Vitals 的門檻是兩套標準，看到橘色不必緊張，回頭確認實際使用者資料就好。

另外，實驗室測試沒有真人點擊，量不到 INP，報告裡的「總封鎖時間」（TBT）可以當作 INP 的參考，但本身不是 INP（INP 說明）。

網站速度怎麼優化？先處理圖片與主機

網站速度優化要依不合格的指標處理：LCP 慢，先縮小首屏圖片、照片改用 WebP，並改善主機回應或使用 CDN；CLS 高，替圖片、影片、廣告預留寬高；INP 差，減少外掛與第三方程式碼。

萬智匯獨家觀點：萬智匯檢查客戶網站速度時，最常見的拖慢原因很單純：照片用了 PNG 格式。PNG 適合圖示和需要透明背景的圖，拿來放照片檔案會很大；換成 WebP，通常就能明顯改善載入速度。我們會先給建議，客戶需要時再協助處理。

圖片：照片換 WebP、尺寸貼近版位

照片改用 WebP，檔案通常比 JPEG、PNG 小 25% 到 35%（使用 WebP 圖片）。上傳前先把尺寸裁到接近實際顯示的寬度，不要拿 4000 像素的原圖放在 800 像素的版位。各種圖片格式適合什麼用途、怎麼壓縮與寫 alt，整理在圖片 SEO 怎麼做。

首屏大圖：不要延遲載入

延遲載入適合頁面下方的圖片，但首屏大圖通常就是 LCP 元素，設成延遲載入反而會拖慢 LCP。web.dev 建議首屏主圖可以加上 fetchpriority=“high”，讓瀏覽器優先載入（最佳化 LCP）。

版面：替圖片、影片、廣告預留空間

圖片和影片加上寬高屬性，廣告、嵌入的影片或地圖用固定高度預留位置，載入時版面就不會被推動，這是改善 CLS 直接有效的做法。

程式碼與主機：減少外掛、縮短回應時間

外掛、追蹤碼、聊天視窗這類第三方程式碼越多，主執行緒越容易被占用，INP 跟著變差；定期清掉沒在用的外掛與追蹤碼。主機回應慢會拖累所有載入指標，訪客多在台灣就選台灣或鄰近地區的主機，或使用 CDN 讓內容從離使用者較近的伺服器送出（最佳化 LCP）。[需確認-工程：快取外掛與 CDN 的實際建議設定由工程確認，正文不寫特定產品]

手機版速度為什麼更重要？Google 看手機版

網站速度要先顧好手機版，因為 Google 是以智慧型手機爬蟲檢索的行動版內容，作為建立索引和排名的依據，也就是行動版內容優先索引（行動版內容優先索引系統的最佳做法）。所以用 PageSpeed Insights 測速時，先看行動裝置分頁的結果，Search Console 的 Core Web Vitals 報表也先看行動裝置。

Google 建議用回應式網頁設計（RWD），同一個網址、同一份內容，依螢幕大小自動調整版面，最容易實作和維護。如果網站另外有手機版網址，要確認手機版的內容、結構化資料和 meta 設定和電腦版一致，不要在手機版拿掉內容。