網站速度優化 2026｜Core Web Vitals 合格線與八個修法
網頁公司說要加錢做速度優化，老闆看着 PageSpeed 上那個四十幾分，不知道哪些是自己動手就做得到、哪些真的要付錢。這篇文章把合格線、失守位置與八個修法逐項寫明，並標出每一項由誰執行。
直接答案：2026 年 Google 的合格線是三項同時達標——LCP ≤ 2.5 秒、INP ≤ 200 毫秒、CLS ≤ 0.1，而且要在真實使用者數據的第 75 百分位達標（web.dev 官方文件）。按 HTTP Archive Web Almanac 2025（CrUX 2025 年 7 月）全球數據，手機版三項全部達標的網站只有 48%，桌面版 56%；最常失守的是 LCP，手機版達標率只有 62%。香港中小企網站未有分地區的公開統計。八個修法之中，前四項不需要改動程式碼；本文逐項標明由誰執行。
網站速度要多快才算合格？
Core Web Vitals（網站體驗核心指標）是 Google 用來量度真實使用者體驗的三項指標。三項各有一條明確的數值線，沒有「接近合格」這回事：達標就是達標，超過就是不達標。
三個名詞第一次出現，先各給一句定義。LCP（Largest Contentful Paint，最大內容繪製）＝頁面上最大那一塊內容畫出來所需的時間，通常是首屏的主圖或大標題。INP（Interaction to Next Paint，互動至下次繪製）＝使用者按下按鈕或展開選單之後，畫面出現回應所需的時間；它在 2024 年正式取代了舊有的 FID。CLS（Cumulative Layout Shift，累積版面配置位移）＝頁面載入途中內容突然跳動的累積幅度，是一個沒有單位的比值。
| 指標 | 合格 | 需要改善 | 差 | 量的是甚麼 |
|---|---|---|---|---|
| LCP | ≤ 2.5 秒 | 2.5–4.0 秒 | > 4.0 秒 | 載入速度 |
| INP | ≤ 200 毫秒 | 200–500 毫秒 | > 500 毫秒 | 互動回應 |
| CLS | ≤ 0.1 | 0.1–0.25 | > 0.25 | 畫面穩定度 |
三條線之外還有一條規則，比數值本身更常被忽略：判定取的是第 75 百分位，手機與桌面分開計算。換句話說，四個訪客之中最慢那一位的體驗，才是您網站的成績。用一部新款手機接公司光纖量到的數字，通常遠比判定值樂觀。
為甚麼 PageSpeed 90 分，Google 仍然判定不合格？
因為兩邊量的不是同一件事。PageSpeed Insights 那個 0 至 100 的分數屬於實驗室數據：在一部模擬裝置、一條模擬線路上跑一次，用來診斷「甚麼拖慢了這一頁」。Google 判定合格用的是真實使用者數據——Chrome 使用者體驗報告（CrUX）收集過去 28 日真實訪客的數值，再取第 75 百分位。
所以有兩個實務結論。第一，不要用分數向網頁公司驗收，要用 CrUX 的三項數值與量度日期；分數可以靠測試環境調得好看，28 日的真實訪客數據不可以。第二，修好之後不會即日反映——CrUX 以 28 日滾動窗口計算，改動要等到窗口內舊數據退出才會完整顯示。要求「下星期就見到分數上升」的合約條款，寫的人不了解這個機制。
要查自己的判定值，最直接是開 Search Console 的「網站體驗核心指標」報告：它按網址群組列出合格、需要改善與差的頁數，而且用的正是 CrUX 數據。若網站流量太低，CrUX 沒有足夠樣本，報告會顯示無數據——那種情況下只能用實驗室數據做代理，並在報價單上寫明這一點。
哪一項指標最容易失守？
有公開數據可以回答這條問題。HTTP Archive 的 Web Almanac 2025 以 CrUX 2025 年 7 月的數據分析全球網站，結果相當一致：失守的通常是 LCP，而不是大家以為的互動卡頓。
| 項目 | 手機版達標率 | 桌面版達標率 | 讀法 |
|---|---|---|---|
| 三項全部達標 | 48% | 56% | 約一半網站不合格，並非少數情況 |
| LCP 達標 | 62% | — | 三項中最低，優先處理這一項 |
| INP 達標 | 77% | — | 多數由第三方腳本造成 |
| CLS 達標 | 81% | — | 最高，而且通常最便宜修好 |
以上數字引自 HTTP Archive Web Almanac 2025 · Performance 章節，2026 年 9 月查閱。
三項個別達標率分別是 62%、77%、81%，但三項同時達標只有 48%——因為合格要求三項全中，任何一項失守都會拉低整體。這也解釋了一個常見誤會：網頁公司只修好 CLS 就報告「已優化」，而判定結果原封不動。驗收時要逐項核對，不要接受一個總結論。
香港方面未有公開的分地區達標統計，本文因此引用全球數據作為基準。若需要自己網站的實際位置，Search Console 的報告就是唯一可靠來源。
一次載入慢在哪一段？
LCP 是一個總時間，本身不指出病因。Google 在官方的 LCP 優化指南中把它拆成四段，並給出一個健康網站應有的比例：伺服器回應約四成、資源開始延遲少於一成、資源下載約四成、元素繪製延遲少於一成。
把這四段對照上面那張八個修法的次序，就會得出一條務實的判斷規則：如果最長的一段是「資源下載時間」，問題在圖片，壓縮就解決，不需要換主機；如果最長的一段是「伺服器回應」，壓縮圖片再多次也不會有明顯改變，該動的是快取與主機。很多網站在錯誤的一段上花了錢，正是因為沒有先做這一步拆解。
四段的數值在 Chrome 開發者工具的效能面板可以直接讀出，不需要付費工具。要求網頁公司在報價前先提供這四個數字，是把「速度優化」由一個模糊名目變成可核對項目的最快方法。
八個修法：哪些自己做得到？
下面八項按難度由低至高排列。前四項不需要改動程式碼，後台或內容管理系統內就做得到；後四項需要能改主題檔或伺服器設定的人。
| # | 修法 | 做法 | 由誰執行 |
|---|---|---|---|
| 1 | 壓縮圖片並改用 WebP／AVIF | 首屏主圖控制在 200KB 以內，上載前先壓縮 | 自己 |
| 2 | 為每張圖寫死 width 與 height | 瀏覽器預先留位，避免圖片載入時整頁跳動 | 自己 |
| 3 | 首屏圖片不要延遲載入 | lazy load 用於下方圖片；首屏那張要立即載入 | 自己 |
| 4 | 刪去已停用或重複的外掛 | 每個外掛都會加入自己的腳本與樣式 | 自己 |
| 5 | 字型自存並預載，設定 font-display | 避免字型未到時文字不顯示或換字跳動 | 開發人員 |
| 6 | 第三方腳本延後或改為互動後載入 | 對話工具、像素、影片嵌入是 INP 的主要來源 | 開發人員 |
| 7 | 開啟頁面快取與伺服器壓縮 | 直接縮短伺服器回應那一段 | 開發人員 |
| 8 | 更換主機或加設 CDN | 最貴的一步，只在前七項做完仍不達標時才動 | 開發人員 |
次序有實際理由：第八項是唯一會產生長期經常性支出的一項，而它解決的只是四段之中的第一段。先把前七項做完再量一次，很多網站已經不需要走到第八步。
圖片為甚麼是最大的一段？
因為首屏那一塊最大的內容，在絕大多數商業網站上就是一張圖——橫幅、產品照或背景相。LCP 量的正是這一塊，所以它的檔案大小幾乎直接等於 LCP 的長短。
三個常見錯誤，逐一說明。第一，用相機原圖直接上載：一張 4MB 的相片在手機網絡上足以單獨把 LCP 推過 4 秒線。第二，用 CSS 把一張 3000 像素闊的圖縮細顯示：瀏覽器仍然要下載整張原圖，縮的只是顯示尺寸。第三，把首屏主圖也設成延遲載入：延遲載入的本意是省下看不見的部分，套用在首屏等於主動推遲最關鍵那一張。
正確做法是上載前按實際顯示尺寸輸出，轉成 WebP 或 AVIF，並提供多個尺寸讓手機下載較細的版本。同一張橫幅由 4MB 減到 180KB 是常見結果，而這一步完全不需要開發人員。網站結構上的其他常見問題，另見網站上線後最常見的六個技術 SEO 問題。
字型、外掛與主機：中後段的修法
前四項做完仍未達標，才輪到下面這一層。共通點是它們都需要能改動主題檔或伺服器設定的人，而且每一項的效果要在改動後重新量度才算數。
| 項目 | 典型徵狀 | 處理方向 | 影響指標 |
|---|---|---|---|
| 網頁字型 | 文字先空白後出現，或換字時整段跳動 | 字型檔自存同一網域、預載、設定 font-display: swap | LCP／CLS |
| 第三方腳本 | 按鈕按下後停頓半秒才有反應 | 對話工具、追蹤像素、影片嵌入改為互動後才載入 | INP |
| 外掛過多 | 每頁載入數十個獨立檔案 | 逐個停用再量度，保留真正在用的 | INP／LCP |
| 沒有快取 | 每次開頁伺服器都重新組裝一次 | 開啟頁面快取與 gzip／brotli 壓縮 | LCP（TTFB 段） |
| 主機與地域 | 伺服器回應時間長期偏高 | 換主機或加 CDN；產生經常性支出 | LCP（TTFB 段） |
其中第二項值得單獨提醒。INP 幾乎不是由網站本身的程式碼造成，而是由外掛進來的第三方腳本造成——對話視窗、廣告追蹤、社交媒體嵌入，每一段都在主執行緒上搶時間。刪掉一個用不着的追蹤碼，往往比重寫整個主題更有效。
速度優化應該付多少錢？
香港市場未有公開的速度優化收費統計，任何報出「行情價」的說法都在猜。可以判斷的是性質：把報價單上每一項標明一次性還是經常性，數字立刻可以比較。
| 項目 | 收費 | 性質 |
|---|---|---|
| 基本網站（1 頁・限時優惠，原價 US$99／5 頁） | US$19 | 一次性 |
| 加頁（每頁，上限共 20 頁） | US$10 | 一次性 |
| Server 與維護（hosting、SSL、備份、保安、內容微調） | US$600／12 個月 | 經常性 |
| 既有網站的速度優化工作 | 按報價 | 視乎工作範圍 |
我們交付的網站已包含基礎速度設定：圖片按尺寸輸出、寫死尺寸、字型自存。既有網站的優化屬於逐案評估的工作，服務頁沒有列出定價，因此按報價處理——這正是本文要求別人寫明的東西，我們不會在這裏報一個好看的數字。
要判斷別人的報價是否合理，用一條規則：一次性的工作只能收一次。壓縮圖片、預載字型、開啟快取都屬於做完就完成；只有主機、CDN 與證書本身按時間計，按年收才有理由。想先弄清楚整體預算的量級，可參考中小企建立網站需要多少錢？2026 香港行情全拆解。
落單前必問的五個問題
把以下五條發給供應商，答得出的通常也是量度得準的那一家。五條都不需要技術知識。
| 問題 | 好答案 | 壞答案 |
|---|---|---|
| 優化前後用甚麼數字驗收？ | CrUX 三項數值加量度日期，手機與桌面分開 | 「PageSpeed 分數會上到 90 分」 |
| 目前四段之中哪一段最長？ | 報出 TTFB、資源延遲、下載、繪製四個數字 | 「整體都要優化一次」 |
| 哪些項目是一次性、哪些按月？ | 逐項標明，主機與 CDN 分開列 | 一個總價，不分性質 |
| 改動後多久才反映在判定上？ | 說明 CrUX 是 28 日滾動窗口 | 「下星期就見到」 |
| 改動會否影響現有版面？ | 列明會改哪些檔案，並提供還原方式 | 「不會有影響」而無備份安排 |
還有一項值得自己先做：在接觸任何供應商之前，先開 Search Console 把三項數值抄下來，連同日期。這份基準是日後唯一能證明優化有效的東西，而它是免費的。上線初期還要做甚麼，可參考新網站 SEO 起步清單：上線首 90 日要做的 12 件事。
常見問題
PageSpeed Insights 拿到 90 分，是否代表已經合格？
不一定。90 分是實驗室模擬分數，只反映測試當刻那一部裝置的一次載入；Google 判定合格用的是 Chrome 使用者體驗報告（CrUX）過去 28 日真實訪客的第 75 百分位數值。同一頁在實驗室拿 90 分，而真實使用者的 LCP 中位數超過 2.5 秒，仍然算不合格。要看判定值，請看 PageSpeed Insights 頁面上方「實際使用者體驗」一欄，或 Search Console 的「網站體驗核心指標」報告。
三項指標之中，應該先修哪一項？
先修 LCP。按 HTTP Archive Web Almanac 2025 的 CrUX 數據，手機版 CLS 達標率 81%、INP 達標率 77%，而 LCP 只有 62%——三項同時達標的網站只佔 48%，最常見的失守位置就是 LCP。而 LCP 的最大單一來源通常是首屏那一張圖片，壓縮與改格式不需要改動程式碼，是投入最少、幅度最大的一步。
網頁公司說要另外收費做速度優化，這筆錢合理嗎？
要先分清楚是一次性工作還是經常性工作。壓縮圖片、寫死圖片尺寸、預載字型、開啟頁面快取都是做一次就完成，除非網站改版，否則不會每月重做；換主機與 CDN 則是按時間計的成本，按月或按年收合理。收到報價時請對方逐項標明「一次性／經常性」，並寫明優化前後的 CrUX 數值與量度日期。我們自己的網站已包含基礎速度設定，另行的優化工作按報價。
需要一個一開始就達標的網站？
我們交付的網站已包含基礎速度設定與 Blog 功能，基本網站限時優惠 US$19（1 頁，原價 US$99／5 頁），加頁 US$10 一頁。一對一專人跟進，3 次修改機會，滿意上線後才開始計 Server 與維護費。