Core Web Vitals（核心網頁指標）是 Google 用來評估真實使用者載入、互動和版面穩定性的三項指標：LCP、INP 和 CLS。合格判斷以行動裝置和桌面使用者的第 75 百分位為基準，良好目標分別是 LCP 2.5 秒內、INP 200 毫秒或以下、CLS 低於 0.1。改善時應先用 Google Search Console 查看實地資料，再用 PageSpeed Insights 按圖片、主機、JavaScript、字體和第三方工具逐項拆解。
首頁打開速度慢、手機版按鈕點擊後沒有反應、表單或 WhatsApp 按鈕在載入時跳位，這些都是香港企業主和 Marketing Manager 常見的網站問題。這些體驗問題不只令使用者感到不便，也可能影響他們完成聯絡、查詢或付款流程的意願。
PageSpeed Insights 顯示低分，不等於你已找到問題根因。工具分數、實地資料和實際轉換問題需要分開判讀，混淆三者只會導致錯誤的修正優先次序。
本文按「先量度、再定位、後修正、最後驗證」的順序整理改善清單，協助香港中小企業和網站管理員把速度問題連接到真正影響業務的頁面和操作流程。
Core Web Vitals 是甚麼？先用三個指標看懂網站體驗
Core Web Vitals 不是單純的伺服器速度測試。它是 Google 以使用者體驗為中心設計的測量框架，分別衡量主要內容的載入速度、使用者互動後的反應時間，以及視覺元素的穩定性。根據 Google Search Central 的官方定義，這三項指標是 LCP、INP 和 CLS。
以下是三項指標的快速對照：
| 指標 | 英文全名 | 白話問題 | 良好目標 | 主要影響來源 |
|---|---|---|---|---|
| LCP | Largest Contentful Paint | 最大內容多久出現？ | 2.5 秒或以內 | 圖片、主機回應、渲染阻塞資源 |
| INP | Interaction to Next Paint | 點擊後頁面多久有反應？ | 200 毫秒或以下 | JavaScript 長任務、第三方工具 |
| CLS | Cumulative Layout Shift | 頁面會不會突然跳位？ | 0.1 或以下 | 圖片尺寸、字體、動態內容插入 |
LCP 是甚麼？主要內容多久出現
LCP（Largest Contentful Paint）量度視窗內最大主要內容元素何時完成渲染。常見的 LCP 元素包括首頁主視覺圖、文章首圖、商品主圖或大型文字區塊，但每個頁面的實際 LCP 元素不同，需要用 PageSpeed Insights 或 Chrome DevTools 確認。
良好目標是 LCP 在 2.5 秒或以內完成。影響 LCP 的常見來源包括：首屏圖片體積過大、主機回應慢、渲染阻塞的 CSS 或字體，以及錯誤設定的延遲載入。根據 web.dev 的 LCP 指南，修正方向應從確認 LCP 元素開始，而不是泛化調整所有圖片。
INP 是甚麼？使用者點擊後多久有反應
INP（Interaction to Next Paint）量度使用者點擊、輸入文字或開啟導覽選單後，頁面顯示下一個反應所需的時間。以香港企業網站常見的情境為例：使用者點擊 WhatsApp 聯絡按鈕、提交表單，或開啟下拉選單時，INP 記錄的是這個互動到視覺反應之間的延遲。
INP 的良好目標是 200 毫秒或以下。JavaScript 長任務和第三方程式碼是常見的可能原因，但影響必須以實際測試確認，不能單憑外掛數量或腳本數目推斷。
CLS 是甚麼？為甚麼頁面會突然跳位
CLS（Cumulative Layout Shift）量度頁面載入過程中視覺元素位置突然改變的累積幅度。常見情境包括：圖片載入後把文字往下推、字體切換時按鈕移位、廣告或 Cookie 橫額插入後整頁跳動，以及浮動 WhatsApp 工具影響附近可點擊元素的位置。
CLS 的良好目標是 0.1 或以下，但這不代表零位移是所有情況下的必然要求。修正方向以「為元素預留空間」為核心，而非強制靜態版面。
Core Web Vitals 合格標準怎麼看？不要只追求 PageSpeed 分數
LCP 2.5 秒、INP 200 毫秒、CLS 0.1，這三個數字是根據 Google Search Central 官方文件定義的良好體驗目標。判斷方式是以行動裝置和桌面使用者各自的第 75 百分位計算，即該裝置類型上 75% 的使用者體驗必須達到良好標準。
「達標」是一個統計門檻，不等於 PageSpeed Insights 滿分，也不等於所有網頁都同樣合格。一個網站可以在桌面版達到良好，但行動版仍然不合格；也可以首頁合格，但服務頁或付款頁仍有問題。
按 web.dev 繁體中文文件的說明，實地資料反映真實使用者的累積體驗，而實驗室資料（如 PageSpeed Insights 的 Lighthouse 部分）則是在模擬環境下測試單一網址，兩者結果可能不同。
為甚麼 PageSpeed Insights 和 Search Console 的結果可能不同？
Google Search Console 的 Core Web Vitals 報告使用 Chrome User Experience Report（CrUX）的實地資料，按裝置類型和網址群組整合，反映一段時間內真實使用者的累積表現。報告需要足夠的實際使用者數據才能顯示，部分低流量頁面可能沒有實地資料。
PageSpeed Insights 則同時提供實地資料（如有）和 Lighthouse 實驗室測試結果。實驗室測試是在受控網絡條件下對單一網址進行，會受到測試時的網絡條件、裝置模擬和第三方工具狀態影響。
根據 Google Search Console 官方說明，兩者因數據來源、網址群組和測試條件不同，結果不一定相同，判讀時必須分開理解，而不是只引用一個分數作決策依據。
Core Web Vitals 會否影響 SEO 與網站轉換率？
Core Web Vitals 會影響網站在 Google 搜尋的可見度評估，但不是唯一的排名保證。簡短答案是：它是頁面體驗的一部分，而不是單獨決定排名的指標。
Google 如何看待網站速度和頁面體驗
根據 Google Search Central 的頁面體驗說明，Core Web Vitals 是頁面體驗信號的組成部分，搜尋系統同時考慮內容相關性、內容品質和其他排名信號。官方明確指出，良好的頁面體驗分數不能保證頁面取得最高排名。
這意味著改善 Core Web Vitals 是必要的技術維護工作，但不應被視為 SEO 的唯一槓桿。網站速度 SEO 的正確框架，是把速度改善放在整體技術 SEO 和內容策略之中，而不是獨立追分。
網站速度如何影響表單、WhatsApp 和購買流程
載入慢、互動延遲或版面跳動可能直接影響使用者完成操作的意願。以香港企業常見的轉換流程為例：LCP 太慢，使用者可能在主要內容出現前已離開；INP 過高，表單送出或 WhatsApp 按鈕點擊後沒有即時反應，使用者可能誤以為操作失敗；CLS 問題則可能讓使用者誤點錯誤按鈕，或令付款頁的確認元素在操作時移位。
實際影響需要以 GA4 事件追蹤、表單送出率、WhatsApp 點擊率和重要頁面離開率驗證。如需把速度問題系統性地連接到轉換追蹤，可參考 營收增長諮詢服務 了解分析和轉換優化的整合方向。沒有網站轉換追蹤資料時，任何轉換改善估計都屬推論，需要謹慎使用。
如何用 PageSpeed Insights 和 Search Console 找出問題？
正確的診斷順序是：先用 Search Console 定位受影響的頁面群組，再用 PageSpeed Insights 拆解單一網址的根因，修正後重新測試並記錄數據變化。
| 工具 | 資料類型 | 主要用途 | 限制 |
|---|---|---|---|
| Google Search Console | 實地資料（CrUX） | 按裝置和網址群組看整站狀況 | 需要足夠實際使用者數據 |
| PageSpeed Insights | 實地資料 + 實驗室診斷 | 拆解單一網址的具體問題 | 實驗室結果受測試條件影響 |
| Lighthouse | 實驗室資料 | 詳細診斷和 audit 報告 | 不反映真實使用者環境 |
| CrUX | 實地資料 | 匯總真實使用者體驗數據 | 低流量頁面可能無資料 |
第一步：先看 Search Console 的實地資料
進入 Google Search Console，選擇「Core Web Vitals」報告，分開查看行動裝置和桌面的狀態。優先標記狀態為「不良」的網址群組，再按曝光量、重要服務頁、Landing Page、表單頁和購物流程排序。影響大量網址的「不良」問題，比只影響低流量頁面的問題更值得優先處理。
第二步：再用 PageSpeed Insights 拆解單一網址
從 Search Console 找到代表性問題網址後，在 Google PageSpeed Insights 輸入該網址進行測試。記錄 LCP 元素（圖片或文字）、INP 相關的互動延遲診斷、CLS 的位移元素、TTFB 數值、主執行緒阻塞時間，以及第三方腳本清單。每次測試都記錄裝置類型和測試時段，作為修正前的基準數據。
第三步：修正後重新測試並追蹤回歸
修正完成後，以相同網址和相近測試條件重新測試，記錄修改前後的數據變化。避免只比較兩次條件不同的測試結果，因為網絡狀況、第三方工具狀態和伺服器負載都可能影響單次分數。修正後回到 Search Console 觀察驗證狀態，實地資料的改善通常需要數週才能反映在報告中。
網站速度優化應先修甚麼？按問題來源排序
不同的問題來源影響不同的指標。以下矩陣協助按優先次序找出根因，而不是泛化調整所有資源。
圖片和首屏主視覺：先處理最可能影響 LCP 的資源
圖片是 LCP 最常見的問題來源之一。修正方向包括：
- 確認 LCP 元素是否為圖片，並用 Chrome DevTools 找出實際圖片來源。
- 檢查圖片的實際顯示尺寸與檔案尺寸是否匹配，避免以 2000px 圖片顯示 400px 位置。
- 使用 WebP 或 AVIF 等現代格式減少檔案大小。
- 對首屏 LCP 圖片使用
fetchpriority="high"，並確保 LCP 元素沒有被錯誤設定為loading="lazy"。 - 使用響應式圖片（
srcset）按裝置提供合適尺寸。
根據 web.dev 的 LCP 最佳化指南，所有修正都應以 PageSpeed Insights 或 DevTools 測試確認效果，而不是基於假設。
主機、快取和網絡：檢查伺服器回應與資源傳送
TTFB（Time to First Byte）是診斷 LCP 的輔助線索，但它不是 Core Web Vitals 指標本身。主機回應慢、快取未設定或設定錯誤、沒有啟用壓縮（如 Gzip 或 Brotli），都可能拖慢初始回應時間。
修正方向包括檢查主機回應設定、快取策略、CDN 實作，以及伺服器與主要使用者地區的距離。需要注意的是，換主機或加 CDN 不一定自動改善 Core Web Vitals，實際效果取決於現有架構和問題根因，應在測試後才作決定。
JavaScript 和第三方工具：降低 INP 與主執行緒負擔
常見的主執行緒負擔來源包括：Google Analytics、Google Tag Manager、聊天工具、廣告腳本、影片嵌入、A/B 測試工具和 Cookie 管理器。根據 Chrome for Developers 的第三方工具說明，第三方程式碼可能增加載入和主執行緒負擔，但影響程度必須以實際測試確認。
修正方向不是直接移除所有第三方工具，而是按使用價值、載入時機和主執行緒影響逐項評估。可以考慮延後非必要腳本的載入時機、減少同時執行的長任務，以及移除已沒有實際用途的嵌入或追蹤代碼。
字體、CSS 和動態內容：避免 CLS 和渲染阻塞
CLS 問題通常來自以下來源：
- 圖片和 iframe 沒有設定明確的寬高比，載入後擠壓其他元素。
- 字體切換時文字重排，令按鈕或連結位置移動。
- 廣告、Cookie 橫額或動態插入內容沒有預留空間，突然佔用版面。
- 浮動 WhatsApp 工具在頁面載入後插入，影響附近可點擊元素。
修正核心是在 CSS 層面為動態元素預留空間，以及選擇對渲染阻塞影響較小的字體載入策略，例如使用 font-display: swap。
WordPress 網站速度：先診斷，不要直接堆疊外掛
WordPress 的速度表現取決於實際的佈景主題、外掛清單、圖片設定、主機配置、快取實作、資料庫和自訂程式碼，而不是平台本身。沒有測試前不應假設 WordPress 一定慢，也不應只憑外掛數量判斷問題來源。
建議的診斷順序是：先用 PageSpeed Insights 測試代表性頁面，記錄 LCP 元素、主執行緒阻塞和第三方腳本，再逐項停用外掛和切換主題，確認哪個變動對分數影響最大。沒有明確測試結果前，不推薦任何特定外掛、快取工具或主機方案。如需從架構層面評估 WordPress 網站的速度和技術基礎，可了解 LetsGetWeb 網頁設計服務 的診斷和重構方向。
Core Web Vitals 改善清單：由低風險到高技術
以下清單可直接複製到專案管理工具，按優先次序逐項核查：
| # | 核查項目 | 對應指標 | 負責人 | 驗證方式 | 優先級 |
|---|---|---|---|---|---|
| 1 | 用 Search Console 分開查看行動裝置和桌面的 Poor URL 群組 | LCP、INP、CLS | 網站管理員 | Search Console 報告 | 高 |
| 2 | 標記 Poor URL、Need improvement URL 和重要轉換頁（服務頁、表單頁、付款頁） | 全部 | 網站管理員 | Search Console | 高 |
| 3 | 確認 LCP 元素（圖片或文字）及其實際來源 | LCP | 開發人員 | PageSpeed Insights、DevTools | 高 |
| 4 | 檢查首屏圖片尺寸、格式、壓縮和 fetchpriority 設定，確保 LCP 元素沒有 lazy load | LCP | 開發人員 | PageSpeed Insights | 高 |
| 5 | 檢查伺服器 TTFB、快取策略、壓縮和 CDN 實作 | LCP | 開發人員/主機管理 | PageSpeed Insights、DevTools | 中 |
| 6 | 找出阻塞主執行緒的 JavaScript 和第三方資源，評估延後或移除 | INP | 開發人員 | PageSpeed Insights、DevTools | 中 |
| 7 | 測試表單、導覽選單、篩選器和 WhatsApp 按鈕的互動延遲 | INP | 開發人員 | 手動測試、PageSpeed Insights | 中 |
| 8 | 為圖片、iframe、廣告容器和動態元件在 CSS 設定明確尺寸或比例 | CLS | 開發人員 | PageSpeed Insights、DevTools | 中 |
| 9 | 檢查字體載入策略和文字重排，考慮使用 font-display: swap | CLS | 開發人員 | PageSpeed Insights | 低 |
| 10 | 記錄修改前後的測試條件（網址、裝置、工具、時段），修正後回到 Search Console 等待驗證 | 全部 | 網站管理員 | Search Console 驗證 | 持續 |
香港中小企何時應自行修正，何時找技術 SEO 或網站開發團隊？
部分問題可由內容管理員或網站管理員自行處理，但技術層面的問題需要開發團隊介入。以下框架協助分配工作：
可自行處理（前提是有備份和回復方式）：
- 更新圖片尺寸和壓縮設定。
- 移除已沒有使用的嵌入內容或非必要外部腳本。
- 修正明顯的圖片版面跳動問題（補充 width/height 屬性）。
- 整理 Google Tag Manager 中已過期的標籤。
應找技術 SEO 或開發團隊：
- 伺服器回應時間慢、主機設定或快取架構需要調整。
- 跨頁面模板的渲染阻塞或 JavaScript 長任務問題。
- 複雜的第三方追蹤架構重構，例如 GA4 事件標籤和 GTM 結構。
- WordPress 主題重構或 PHP 層面的效能問題。
- 結帳流程、表單或付款頁的互動延遲，因為改動風險影響轉換追蹤。
如需把速度診斷連接到整體技術 SEO 和網站健檢，可參考 LetsGetWeb SEO 優化服務 了解代碼層級優化的服務範疇。
哪些情況未必需要立即重建網站
如果問題只出現在非核心頁面（如舊文章或未獲流量的分類頁），或網站沒有足夠的實地資料讓 Search Console 顯示不良狀態，直接重建網站未必是最合適的第一步。同樣，如果改動會影響現有的付款流程、表單追蹤或 CRM 整合，應先完成範圍清晰的診斷和優先級排序，確認根因和風險，再決定是否需要重建。在沒有確認問題來源和影響範圍前，大規模重建可能引入新的技術問題。
LetsGetWeb 如何把速度測試接到網站、SEO 與轉換優化？
LetsGetWeb 是香港數碼增長代理，官方服務頁面列出技術 SEO、網站速度測試、代碼層級優化、Google Analytics、Google Search Console、Schema 結構化資料和 CRO 等服務定位；網站設計服務亦涵蓋響應式網站、網站報告和速度測試。這些服務以整合系統運作，把搜尋流量連接到查詢和業務轉換，而不是分散處理單一指標。
本文由 LetsGetWeb 編輯，品牌亦提供網站設計、技術 SEO 和營收增長諮詢服務，讀者可按自身需要比較方案。如對特定服務範疇有疑問，可直接參考官方服務頁面核對最新功能說明。
Core Web Vitals 常見問題
Core Web Vitals 是甚麼？ Core Web Vitals 是 Google 用來衡量真實使用者載入速度、互動反應和視覺穩定性的三項指標，分別是 LCP、INP 和 CLS。
LCP、INP 和 CLS 的良好標準是多少？ 良好目標是 LCP 2.5 秒內、INP 200 毫秒或以下、CLS 低於 0.1，以第 75 百分位的使用者體驗判斷，行動裝置和桌面分開計算。
Core Web Vitals 達標是否代表 SEO 一定變好？ 不代表。Core Web Vitals 只是頁面體驗的一部分，Google 搜尋系統同時考慮內容相關性、品質和其他信號，良好分數不保證最高排名。
為甚麼 PageSpeed Insights 和 Search Console 的分數不同？ 兩者使用不同資料來源、網址群組、裝置和測試條件，Search Console 反映真實用戶的累積實地資料，PageSpeed Insights 同時提供實驗室測試結果，結果不一定相同。
LCP 太高應該先檢查甚麼？ 先用 PageSpeed Insights 或 DevTools 確認 LCP 元素，再按首屏圖片大小、主機回應時間、渲染阻塞資源和資源載入順序逐項診斷。
INP 太高是否代表 JavaScript 太多？ 不一定。JavaScript 長任務、互動元件設計和第三方工具都可能是原因，影響程度必須以實際測試確認，不能只憑腳本數量判斷。
CLS 太高如何改善？ 先為圖片、iframe、廣告容器和動態元件在 CSS 層面預留明確尺寸，再檢查字體載入策略和載入後才插入的內容。
WordPress 網站要刪除外掛才會變快嗎？ 不一定。應先用 PageSpeed Insights 測試，再按佈景主題、外掛、圖片、主機、快取和自訂程式碼逐項診斷，確認實際影響後再決定。
網站速度會影響轉換率嗎？ 網站速度可能影響使用者完成表單送出、WhatsApp 點擊或付款流程的意願，但實際影響幅度需要以 GA4 事件追蹤或轉換數據驗證，沒有第一方數據前屬於推論。
香港中小企需要找技術 SEO 團隊嗎？ 如問題涉及伺服器設定、複雜 JavaScript、跨頁面模板或重要轉換流程異常，找具備網站開發和技術 SEO 能力的團隊通常比單獨調整內容更合適。
結語：由最影響轉換的頁面開始修正
Core Web Vitals 應被視為網站體驗和技術決策工具，而不是一個需要追求滿分的單一 SEO 指標。診斷的起點是 Search Console，先找出 Poor 且影響重要頁面的問題，再用 PageSpeed Insights 定位根因。
下一步三項清單：第一，記錄目前各指標的實際數據和受影響網址。第二，按優先次序修正最影響重要頁面的問題，從低風險圖片和尺寸問題開始。第三，修正後重新測試，並在 Search Console 觀察實地資料的驗證進度。
如果你的網站已有明顯的速度問題，或希望把技術診斷連接到業務轉換追蹤，可先 預約網站速度健檢 了解適合的診斷範圍。任何改善幅度都無法在測試前保證，因為結果取決於網址、裝置、測試條件和現有的轉換追蹤架構。