網站速度及 Core Web Vitals 完整指南：LCP、INP、CLS 官方標準

網站慢，不只是「等一等」的問題。當訪客在頁面載入完成之前已經離開，再好的內容都無法被看見。這篇指南說明 Core Web Vitals 的三項指標、Google 對排名的官方立場、常見效能成因、實際優化手法，以及香港網絡環境下要特別留意的細節。

以下內容由 ADWire Agency 團隊整理，結合香港本地實戰經驗與最新行業數據。

一、網站慢不只是體驗問題，而是生意問題

很多公司把網站速度當成技術細節，交給工程團隊處理就算。但速度直接決定訪客會否留下。Google 過往曾引用流動頁面速度研究指出，約 53% 的流動用戶會放棄載入超過 3 秒的頁面。要注意，這個數字來自 2017 年、性質偏推廣性的研究，並非同行評審論文，引用時宜視為方向性參考，而不是「每慢一秒必定流失多少成交」的方程式。

換句話說，頁面每慢一點，都在流失本來可以成交的訪客。對電商、預約、查詢表單這類需要訪客完成動作的頁面，影響尤其直接。這也是為甚麼 Core Web Vitals 會被納入搜尋品質的討論範圍——它量度的正是訪客等待與互動時的真實感受。

來源：Google — 流動頁面速度資訊圖（2017 年數據，屬方向性參考）

二、Core Web Vitals 是什麼：三項指標與官方門檻

Core Web Vitals 由三項指標組成，分別量度載入、互動反應與視覺穩定：LCP（Largest Contentful Paint，最大內容繪製）反映載入速度；INP（Interaction to Next Paint，與下一次繪製的互動時間）反映互動反應；CLS（Cumulative Layout Shift，累計版面位移）反映視覺穩定。

三項指標都以「第 75 百分位」量度——意思是 75% 的頁面載入體驗須達標，換個角度講，就是不能只看平均值，必須連較慢的一批訪客也照顧到。手機與桌面分開評估，三項全部達標才算通過，任何一項落在「差」的範圍都不算。

來源：web.dev — Core Web Vitals、INP、LCP、CLS

INP 已正式取代 FID

如果你仍在使用舊的教學，可能會見到 FID（First Input Delay，首次輸入延遲）。INP 已於 2024 年 3 月 12 日正式取代 FID，FID 已經淘汰，不再是 Core Web Vitals 的一部分。

兩者的分別在於量度範圍。FID 只看用戶第一次互動時的輸入延遲，不包含處理與繪製的時間；INP 則觀察整次瀏覽中所有互動的回應時間。官方文件說明，對大多數網站而言，延遲最差的一次互動會成為 INP；但對於互動量很大的頁面，隨機的一次卡頓可能造成異常高的數值，因此官方會忽略一次最高延遲的互動，以免以偏概全。這是一個很實用的細節：它說明 INP 不必然等於「單純取最差的那一次」。

來源：web.dev — INP becomes a Core Web Vital、web.dev — INP

三、Google 官方對排名的立場（這一節最重要）

市面上不少文章把 Core Web Vitals 講成「達標就會排名上升」，這並不符合 Google 的官方說法。以下是 Google 官方文件的原意，值得逐點看清楚。

1. Core Web Vitals 確實是排名系統使用的訊號之一

Google 在頁面體驗（Page Experience）文件中表明，Core Web Vitals 由其排名系統使用，並建議站長為搜尋表現的目標而追求良好的 Core Web Vitals。所以速度並非完全無關——它是被納入考慮的其中一環。

2. 但沒有單一排名訊號

同一份文件明確指出：「There is no single signal」——並不存在單一的頁面體驗排名訊號，核心排名系統會同時考慮多項訊號。速度只是其中之一，它不會單獨決定排名。

3. 好成績不保證排名，追分數未必值得

Google 亦提醒，取得良好結果不保證頁面會排在最前，而且「單為了 SEO 原因去追求滿分，可能不是時間的最佳運用」。這句說話對很多公司都很實用——把資源全部投在把分數由 95 推到 100，回報通常遠低於處理真正影響訪客的效能問題。

4. 相關性優先於頁面體驗

最關鍵的一句是：Google 搜尋始終以顯示最相關的內容為先，即使該頁面的體驗未達理想。換句話說，內容與搜尋意圖的相關性，優先於頁面體驗。一個載入稍慢但完全切合查詢的頁面，仍可能排在一個很快但答非所問的頁面之前。

實際的結論是：速度優化應該與內容、關鍵字、技術基礎並行，而不是當成排名的萬能鑰匙。先把內容與技術基礎做對，再處理效能，次序才合理。

來源：Google Search Central — Page experience

5. 別忘了行動優先索引

Google 以手機版的內容作索引與排名。要準確理解這一點：行動優先索引指的是「索引與排名時採用手機版的內容」，例如你只在手機版顯示某段文字，Google 就可能把它當作頁面的主要內容。它不代表「所有裝置的 CWV 評估都只看手機」。Google 的量度是手機與桌面分開的，桌面體驗仍會被評估，只是索引內容的來源以手機版為準。實務上，兩者要同時做好：手機版要內容完整、體驗良好，桌面版亦要有對應的效能與體驗。

來源：Google Search Central — Mobile-first indexing

四、真實研究數據怎麼說

以下是幾組常被引用的研究，但每一組都有其限制，引用時必須一併說明。

Deloitte《Milliseconds Make Millions》（2020）

Google 委託 Deloitte 進行的研究，涵蓋 37 個歐美零售、旅遊、奢侈品與 Lead-gen 品牌。結果顯示，流動速度改善 0.1 秒後，零售轉換率上升 8.4%、旅遊上升 10.1%；零售平均訂單價值上升 9.2%；奢侈品的「產品頁至加入購物車」比率上升 40.1%。

來源：web.dev — Milliseconds Make Millions

Web Almanac 2025（HTTP Archive）

HTTP Archive 於 2026 年 1 月發表的 Web Almanac 2025 指出，2025 年有 48% 的手機網站、56% 的桌面網站達到良好 Core Web Vitals；手機達標率由 2023 年的 36% 升至 48%。這說明兩件事：一是整體正在改善，二是手機樣本仍有過半未達標，而桌面樣本已有過半通過，手機明顯落後於桌面。

來源：Web Almanac 2025 — Performance

五、最常見的效能問題及成因

圖片：佔用頻寬最多，也最常被忽略

HTTP Archive 指出，圖片是最常被請求、佔用頻寬最多的資源類型；第 90 百分位的網站，桌面與手機的圖片總量都超過 5 MB。未壓縮的相片、直接上傳的原圖、過大的尺寸，都是常見成因。

來源：web.dev — Lazy loading images

字型：拖慢文字渲染，也造成版面位移

Web 字型未載入完成前，文字無法顯示，會延遲首次內容繪製與 LCP；而字型與後備字型的大小不一致，替換時就會造成版面位移，直接影響 CLS。

來源：web.dev — Best practices for fonts

JavaScript：直接影響 INP

過大的 JavaScript 檔案會拖慢頁面啟動，並長時間佔用主執行緒，令用戶點擊後遲遲未見回應，直接影響 INP。程式碼分割是常見的改善方向。

來源：web.dev — Code splitting

第三方腳本與動態內容：CLS 與 INP 的隱形來源

CLS 的常見成因包括圖片或影片沒有指定尺寸、字型與後備字型大小不一，以及第三方廣告或小工具在載入後動態改變大小。Web Almanac 2025 亦提到，高流量網站因功能複雜、第三方整合多、JavaScript 執行量大，INP 較難達標。

來源：web.dev — CLS、Web Almanac 2025

LCP 可以拆成四段來診斷

要真正改善 LCP，不能只說「壓縮圖片」。官方文件把 LCP 拆成四個時序階段：TTFB（首位元組時間，反映伺服器與網絡）、資源載入延遲（瀏覽器發現要下載的圖片或字型之時間）、資源載入時間（檔案本身大小）、以及元素渲染延遲（下載完成後到畫面繪製）。先量度四個階段各佔多少，才知道樽頸在伺服器、網絡還是前端。對於 LCP 圖片，應使用 fetchpriority="high" 提示瀏覽器優先下載，並避免把它設成 lazy load。

來源：web.dev — Optimize LCP

INP 要用 long task 診斷，不是只看圖片

INP 差通常來自三類問題：輸入延遲（主執行緒忙於處理其他工作）、事件處理時間過長、以及呈現延遲（畫面要等太久才重繪）。診斷方法是找出長工作（long task）——在 Chrome DevTools 的效能面板中，任何佔用主執行緒超過 50 毫秒的工作都會被標示。常見修法包括：把非必要工作拆成小塊、用 requestIdleCallback 或 web worker 移離主執行緒、減少初始 JavaScript、避免在事件處理程序中做大量同步運算。

來源：web.dev — INP、web.dev — Optimize long tasks

六、實際優化手法對照表

以下按常見問題整理對應手法與預期效果。效果屬技術層面的預期，並非業務成效承諾。

來源：web.dev — Choose the right image format、Lazy loading、HTTP cache、CDN、Code splitting

七、量度工具：實地數據與實驗室數據不可互換

量度工具分兩類：實地數據（field data）來自真實訪客的瀏覽紀錄，實驗室數據（lab data）則是在受控環境下的模擬測試。兩者用途不同，不可互相取代。

來源：PageSpeed Insights、Lighthouse、CrUX 方法論、Search Console Core Web Vitals 報告

排名用實地數據，不是 Lighthouse 分數

Google 提醒，排名所用的評估依據是實地數據，並非 Lighthouse 分數。Lighthouse 的滿分不等於訪客體驗良好，也不等於會被 Google 的排名系統認可。

CrUX 的 28 日視窗與資料資格

CrUX 是 Google 的官方實地數據集，透過公開的 Chrome 使用者體驗報告收集。它的數據以滾動 28 日視窗計算，因此反映的是「近四星期」的表現，而不是某一日的即時數字；這也解釋了為何你修好問題後，CrUX 數據通常要等數天至數星期才反映出來。此外，CrUX 只收錄公開可被索引、且達到最低訪客量的頁面與來源；未能達到最低流量的網站可能完全沒有 CrUX 數據。在這種情況下，可以自行部署 RUM（Real User Monitoring）收集實地數據，而不必只依賴 Lighthouse 的實驗室數據。

來源：Chrome UX Report 方法論、web.dev — Optimize LCP

八、香港的網絡環境考慮

香港的網絡環境有一個明顯特徵：固網極快，流動是瓶頸。根據 Speedtest Global Index 過去公布的香港快照，香港固網寬頻中位下載速度曾達約 462.90 Mbps、排名全球前列；流動網絡中位下載速度則約為 155.10 Mbps、名次明顯較後。要留意的是，這個指數每月更新，上述為過往快照數字，並非今日的即時排名；引用時應附上月份與存檔。

這個落差對優化策略有直接影響。若你只在辦公室的光纖網絡上測試，會得到一片樂觀的數字；但你的客戶很可能正在地鐵、商場或舊區以流動網絡瀏覽。Core Web Vitals 的手機與桌面分開評估，正是因為手機在頻寬、記憶體與處理器上都較弱，表現通常較差——Web Almanac 2025 的數字（手機 48%、桌面 56%）也印證了這一點。

實務建議是：以手機與流動網絡為主要測試情境，並參考 CrUX 或自建 RUM 的實地數據，而非只信桌面測試結果。同時要明白，香港的整體網速快，並不能推出「你的網站沒有樽頸」——樽頸可能來自伺服器回應、圖片大小、CPU 處理或第三方腳本，這些都要用自身量度去定位，不能靠國際排名代替。

來源：Speedtest Global Index — Hong Kong（每月更新；本文所引為過往快照）、web.dev — Core Web Vitals、Web Almanac 2025

九、建立基線與持續監測

在決定重建還是優化之前，先建立基線是最實際的一步。做法很簡單：為網站的主要頁面模板（例如首頁、產品頁、文章頁、表單頁）各自量度一次，記錄 LCP、INP、CLS，並註明測試裝置與網絡情境。有了基線，日後任何改動都可以比較，也不會單憑感覺決定要重建整個網站。

監測方面，CrUX 的 28 日滾動視窗適合作為長期趨勢的參考；若需要更即時或更細緻的數據，自建 RUM 可以按頁面、裝置、地區切分。要留意，新增的第三方腳本、圖片或功能，往往會令指標再次變差，所以效能監測應該納入日常運作，而不是一次性的項目。

十、網站重建還是優化？

這個問題沒有 Google 官方文件提供決策準則，以下屬行業實務判斷，並非官方指引。

Google 的官方立場是相關性優先、頁面體驗為輔助，先確保內容與技術基本正確。從這個前提出發，判斷可以簡化為兩類：

個別可修正項，應先優化

例如圖片未壓縮、未設快取、JavaScript 過大、圖片未指定尺寸。這些都是局部改動，成本較低，見效亦較快。

架構性問題，較適合重建或更換平台

例如主題或外掛過於臃腫、載入了大量無法控制的第三方腳本、或現有平台的渲染方式根本無法改善。這類問題逐項修補往往事倍功半。

來源：Google Search Central — Page experience、web.dev — Optimize LCP

十一、常見問題

十二、總結

網站速度值得投資，但要把期望放在正確的位置。Core Web Vitals 的 LCP、INP、CLS 三項指標，以第 75 百分位量度、手機與桌面分開評估，三項全達標才算通過；門檻包含等號（LCP ≤2.5 秒、INP ≤200 毫秒、CLS ≤0.1）；INP 已於 2024 年 3 月取代 FID。這些都是可以量度、可以改善的技術目標。

但 Google 的官方立場同樣清楚：Core Web Vitals 是排名系統使用的訊號之一，卻沒有單一排名訊號，而且相關性優先——即使頁面體驗未達理想，Google 仍會優先顯示最相關的內容。速度優化應該與內容、關鍵字、技術基礎並行，而不是當成排名的萬能鑰匙。

對香港的公司而言，還有一點要記住：固網快、流動相對慢，而 Google 以手機版內容作索引與排名。所有測試與優化，都應以手機與流動網絡為主要情境，並以實地數據而非實驗室分數作判斷。

若你需要專人協助診斷網站效能、判斷該優化還是重建，或把速度、SEO 與內容一併規劃，可以了解我們的 網站開發及優化服務。我們會先以 CrUX 與 PageSpeed Insights 取得基線，再按實際情況提出建議，而不是一律叫你重建整個網站。

主要來源及查核日期（2026 年 10 月 3 日）：web.dev Core Web Vitals、web.dev INP、web.dev Optimize LCP、CrUX 方法論、Google Page experience、Mobile-first indexing、Web Almanac 2025。