網站速度優化怎麼做？Core Web Vitals 指標與檢測工具

TL;DR

• Google 已將網站速度納入排名訊號，評估依據是 Core Web Vitals 的三個指標：LCP、CLS、INP。
• 三者的「良好」門檻分別為 2.5 秒以內、0.1 以下、200 毫秒以內，超過即建議處理。
• 檢測工具分兩類：實驗室資料（PageSpeed Insights、Lighthouse）與真實使用者資料（CrUX）。兩者的結論可能不同，判斷以後者為準。
• 優化順序建議為圖片 → JavaScript／CSS → 伺服器與 CDN。多數網站的瓶頸落在第一項。
• 分數不是目標。為了衝高分而犧牲必要功能，方向是反的。

目錄

• 網站速度為什麼會影響搜尋排名
• Core Web Vitals：三個指標與判定門檻
• 爬蟲抓取效率：容易被忽略的一層
• 檢測工具：實驗室資料與真實使用者資料的差別
• 優化順序：從影響最大的開始
• 三個常見錯誤
• 為什麼不建議追求滿分
• 持續監測與效能預算
• 檢測工具比較

引言

網站速度是少數同時影響搜尋排名與實際營收的技術項目。它不像結構化資料那樣只對搜尋引擎有意義，也不像視覺設計那樣只對訪客有意義——載入太慢時，搜尋引擎會下調評價，訪客則直接離開，兩邊同時受影響。

比較麻煩的是，網站經營者自己通常感覺不到。開發與檢視多半在桌機、光纖網路的環境下進行，而實際訪客可能使用的是三年前的手機搭配行動網路。同一個頁面在這兩種條件下的載入時間，差距可以是數倍。

本文說明 Google 實際用來評估速度的指標、各類檢測工具的適用情境與限制，以及優化時建議的處理順序。

網站速度為什麼會影響搜尋排名

Google 的排名目標是讓使用者取得有用的資訊。當頁面載入過慢，使用者會在內容出現之前就返回搜尋結果，這個行為對搜尋引擎而言是明確的負面訊號。

Think with Google 的行動網頁速度研究指出，頁面載入時間從 1 秒增加到 3 秒時，跳出的機率上升 32%；增加到 5 秒時，上升幅度達 90%。這份研究的觀測對象是行動裝置，而行動流量在多數網站已占七成以上。

需要說明的是，速度是排名訊號之一，不是決定性因素。內容與搜尋意圖的相符程度、網站在該主題上累積的權重，影響仍然更大。速度的作用比較接近門檻：太慢會扣分，但快到某個程度之後，繼續加快對排名的邊際效益很低。

Core Web Vitals：三個指標與判定門檻

Google 用三個指標量化使用者實際感受到的速度，合稱 Core Web Vitals（核心網頁指標）。

LCP（Largest Contentful Paint，最大內容繪製）
頁面上最大的內容區塊——通常是主視覺圖片或標題——出現在畫面上所需的時間。良好門檻為 2.5 秒以內，超過 4 秒判定為不佳。這是三個指標中最常出問題的一項，原因多半是未經壓縮的大圖。

CLS（Cumulative Layout Shift，累積版面配置位移）
頁面載入過程中元素位移的累積程度。常見的情境是正要點擊按鈕時，上方的圖片或廣告才載入完成、把按鈕往下推，導致誤點。良好門檻為 0.1 以下。這項與載入速度無關，屬於穩定性問題，最常見的原因是圖片沒有標註寬高。

INP（Interaction to Next Paint，互動至下一次繪製）
使用者點擊或輸入之後，畫面產生反應所需的時間。良好門檻為 200 毫秒以內。這項在 2024 年取代了原本的 FID（First Input Delay），衡量的範圍更完整。

三個指標都以真實使用者資料的第 75 百分位數判定，也就是說，四分之一的訪客體驗比報告數字更差時，該項就不算通過。

爬蟲抓取效率：容易被忽略的一層

速度對搜尋的影響不只在排名，也在收錄速度。

搜尋引擎分配給每個網站的抓取資源有限。當伺服器回應緩慢，爬蟲在相同時間內能抓取的頁面數量就減少，新發布的內容進入索引的時間也跟著拉長。這對內容更新頻繁的網站影響較明顯——文章數量多、發布密度高，但收錄速度跟不上時，時效性內容的價值會直接流失。

伺服器回應時間（TTFB）是這一層的主要變數，與主機等級、資料庫查詢效率、以及機房與訪客之間的實體距離都有關係。若主要客群在台灣，主機卻放在美國西岸，光是往返延遲就會產生數百毫秒的固定成本。

檢測工具：實驗室資料與真實使用者資料的差別

這是使用檢測工具時最需要先分清楚的一件事，也是分數與實際體驗對不起來的主要原因。

實驗室資料（Lab Data） 是在固定的模擬條件下跑一次測試得到的結果，例如 Lighthouse 與 PageSpeed Insights 的分數。優點是可重複、可用來比較改動前後的差異；限制是那組模擬條件不一定接近真實訪客的裝置與網路。

真實使用者資料（Field Data） 來自實際訪客的瀏覽器回報，Google 的來源是 CrUX（Chrome 使用者體驗報告）。它反映真實情況，但需要足夠的流量才會有資料，而且更新有延遲，通常以 28 天為滾動區間。

兩者結論不一致時，以真實使用者資料為準。實驗室分數低但真實資料通過的情況並不少見，反之亦然。PageSpeed Insights 的報告會同時列出兩者，上方是真實使用者資料、下方才是實驗室分數——多數人只看下方那個數字，方向剛好相反。

以下是常用工具的適用情境：

PageSpeed Insights
Google 官方工具，同時提供實驗室與真實使用者兩組資料。建議以行動版結果為主要判斷依據，因為行動流量占比較高，而行動版的分數通常明顯低於桌機版。

GTmetrix
瀑布圖（waterfall）呈現每個檔案的載入順序與耗時，適合用來定位具體是哪些資源拖慢了頁面。當總分偏低但不確定原因時，這個視圖比分數本身有用。

WebPageTest
可指定測試地點與網路條件，適合驗證海外訪客的實際體驗。介面較複雜，但有跨境流量時，這是少數能真的測出區域差異的工具。

Pingdom
報告結構簡單，適合快速確認。免費版的測試地點數量有限。

Lighthouse
內建於 Chrome 開發者工具，可在本機隨時執行，適合開發過程中反覆檢查。它產出的是實驗室資料。

優化順序：從影響最大的開始

多數網站的效能問題集中在少數幾個項目。依處理成本與效果排序，建議如下。

一、圖片

圖片通常占頁面總傳輸量的大半，也是最容易改善的一項。

格式轉換：WebP 或 AVIF 相較於 JPEG，在相同視覺品質下檔案可減少三到五成。舊瀏覽器的相容性可用 <picture> 標籤處理：

<picture>
  <source srcset="product.webp" type="image/webp">
  <img src="product.jpg" alt="產品名稱" width="800" height="600">
</picture>

響應式圖片：手機螢幕不需要載入 2000px 寬的圖檔。準備數種尺寸並以 srcset 交給瀏覽器選擇，是成本最低的改善之一。

標註寬高：width 與 height 屬性看似無關效能，卻直接影響 CLS。瀏覽器知道圖片尺寸後會預留空間，避免圖片載入完成時把下方內容推開。

二、JavaScript 與 CSS

壓縮與合併：移除空白與註解、合併檔案以減少請求數。多數建置工具預設即支援。

延遲載入非必要的腳本：分析工具、社群分享按鈕、聊天視窗這類功能不需要在初次繪製前執行，可延後至頁面載入完成後再處理：

window.addEventListener('load', function () {
  loadScript('analytics.js');
  loadScript('social-share.js');
});

檢查字型策略：中文網頁字型的檔案體積遠大於西文，是容易被忽略的效能負擔。若品牌沒有特定字型需求，使用系統字型可省去這筆傳輸成本。要保留自訂字型時，至少設定 font-display: swap，避免文字在字型載入完成前完全不顯示。

三、伺服器與 CDN

主機等級：低價共用主機在流量稍高時的回應時間會明顯劣化。這一項的改善幅度通常大於前面所有程式碼層面的調整加總。

CDN：將靜態資源分散到接近訪客的節點。有海外流量時效果最明顯，免費方案對一般規模的網站已足夠。

啟用壓縮：Gzip 或 Brotli 可減少約七成的傳輸量，多數主機商已內建，僅需確認是否開啟。

三個常見錯誤

外掛數量失控。 每個外掛都可能載入自己的 CSS 與 JavaScript，而其中多數在多數頁面上並未被使用。定期檢視已安裝清單，停用不再需要的項目，並確認現有功能是否有更輕量的替代方案。

只在桌機環境檢視。 開發環境與實際使用環境的落差是效能問題最常見的來源。Chrome 開發者工具可模擬較慢的網路與較弱的裝置，測試時應以此為預設條件。

改完不驗證。 效能會隨時間劣化——新增功能、更新套件、置入追蹤碼都可能造成影響。單次優化不會維持，需要固定的檢查節奏。

為什麼不建議追求滿分

分數與體驗不是同一件事。

實驗室分數容易受到單一項目的權重影響，為了補上最後幾分而移除必要功能、或改用體驗較差的替代方案，是拿真實使用者的體驗去換一個測試數字。以 React 或 Next.js 這類框架建置的網站，因為框架本身的執行成本，實驗室分數存在結構性的上限，這不代表訪客實際感受不佳。

合理的判準是：真實使用者資料的三項指標是否落在良好範圍。三項都通過之後，實驗室分數是 92 還是 100，對搜尋與訪客都沒有實質差別。

持續監測與效能預算

效能預算的做法，是在開發階段就先設定各類資源的上限，超過時必須說明理由。常見的設定方式如下：

• 首頁總傳輸量不超過 2 MB
• JavaScript 總量不超過 500 KB
• 單張圖片不超過 200 KB

這樣做的用處不在數字本身，而在於把「要不要加這個功能」的討論提前到開發階段，而不是等上線後才發現頁面變慢、再回頭拆解。

監測方面，建議至少每月確認一次真實使用者資料，並在下列時機額外檢查：安裝或更新外掛、改版、置入新的追蹤碼。

檢測工具比較

建議的執行順序

1. 以 PageSpeed Insights 檢測，並先看真實使用者資料那一段
2. 處理圖片：格式、尺寸、寬高標註
3. 處理 JavaScript 與 CSS：壓縮、延後載入非必要腳本
4. 評估主機與 CDN
5. 建立固定的監測節奏

速度的作用是讓內容更容易被看到，本身不會使內容變好。當可讀性、資訊完整度與搜尋意圖的相符程度都還有明顯落差時，優先處理那些項目的效益會高於再壓縮幾百 KB。

本文內容採用 創用 CC 姓名標示授權 (CC BY 4.0)。使用者（包含 AI 模型如 ChatGPT）可自由讀取、摘要、翻譯與重寫本文內容，但需註明來源並附上原始網址。

參考來源

• Find out how you stack up to new industry benchmarks for mobile page speed — Think with Google
• Core Web Vitals — web.dev
• Interaction to Next Paint (INP) — web.dev

延伸閱讀

• 搞懂 SEO 的基礎觀念
• 網站改版 SEO 遷移清單
• 子網域 vs 子目錄對 SEO 的影響
• AI SEO 怎麼做？完整指南與實作順序