2026 年 Core Web Vitals:邊啲因素真正影響香港 Google 排名
Core Web Vitals 自 2021 年起已經係確認嘅 Google 排名信號。2024 年 INP 取代 FID 之後,門檻收緊咗。對香港網站嚟講,三個指標之一被啲同你前端代碼完全無關嘅嘢默默搞壞咗:TTFB。呢篇文章會講解每個指標實際量度乜嘢、點解香港網站特別容易喺呢方面跌低,同邊啲工程操作真正能夠移動到指標。
三個指標,用簡單嘅話講
Google 嘅 Core Web Vitals 係三個量度,試圖捕捉網頁加載嘅用戶體驗。每個都有「好」嘅門檻同「差」嘅門檻。喺「好」門檻之上,你拎足分。喺「差」門檻之下,你受排名懲罰。中間係「需要改善」。
| 指標 | 量度乜嘢 | 好 | 差 |
|---|---|---|---|
| LCP (Largest Contentful Paint) | 最大可見內容渲染要幾耐 | ≤ 2.5 秒 | > 4.0 秒 |
| CLS (Cumulative Layout Shift) | 加載過程入面頁面跳動嘅幅度 | ≤ 0.1 | > 0.25 |
| INP (Interaction to Next Paint) | 頁面回應點擊/觸碰要幾耐 | ≤ 200ms | > 500ms |
Google 用嘅係實地數據,唔係實驗室數據。呢啲數字嚟自 Chrome 真實用戶經過 Chrome User Experience Report (CrUX),量度係喺第 75 個百分位。即係話即使你嘅網站對大多數用戶都快,如果每四個用戶有一個睇到 >4 秒嘅 LCP,你照樣受排名懲罰。
LCP 對香港網站影響最大
我哋審計過幾十個香港網站 —— 金融科技、餐飲、電商、旅遊 —— 同一個模式不斷出現:LCP 喺幾乎每個網站都差,而且根源都係同一個。唔係未優化嘅圖片。唔係過大嘅 CSS。係 TTFB —— 由用戶點擊到首位元 HTML 到達瀏覽器嘅時間。
TTFB 係 LCP 嘅一部分。如果你嘅伺服器要 800ms 回應,你嘅 LCP 喺任何渲染開始之前已經喺 800ms。加埋圖片加載、字型 fetching、JS hydration,你輕易就過咗 2.5 秒嘅好門檻。
點解 TTFB 對香港網站咁經常成為問題?三個原因:
- 伺服器位置。 如果你嘅 hosting 區域喺美國 (好多初創用 Vercel、Netlify、AWS 嘅默認位置),每個來自香港用戶嘅請求要過太平洋。喺任何工作開始之前已經有 ~150ms 嘅基準延遲。加埋 serverless 平台嘅冷啟動時間,TTFB 輕易就過 500ms。
- SSR 無邊緣緩存。 現代 Next.js 網站每個請求都 server-render。如果渲染出嚟嘅 HTML 唔喺 CDN 邊緣緩存,每個訪客都付足伺服器渲染嘅成本。
- 資料庫查詢喺關鍵路徑上面太重。 主頁面如果順序 fetch 產品資料、用戶狀態、i18n 翻譯,每個請求都喺自己伺服器入面花 200-400ms,先至發出首位元。
我哋喺 synque.hk 自己上面睇到嘅 —— 我哋公開 SEO 審計嘅第 4 輪喺每個 Tier-1 著陸頁都捕捉到 TTFB 1,000-1,300ms,深入 Google 嘅「差」區域。修復唔係一個大改動;係靜態頁面嘅 ISR、
Cache-Control: s-maxageheaders 喺營銷路線、同 Vercel 區域檢查。
CLS —— 多數團隊唔留意到嘅靜默 SERP 殺手
CLS 量度頁面加載過程入面內容跳動幾多。想像你正準備 tap 個 button,就喺你手指落到之前,上面個廣告加載並推 button 落,你就 tap 咗第二樣嘢。呢個係 layout shift,Google 重懲呢樣嘢。
我哋審計入面最常見嘅原因:
- 圖片無明確尺寸。 當瀏覽器唔知圖片嘅 aspect ratio,佢首先 render 頁面再喺圖片加載時 reflow。每個現代圖片 tag 都需要
width+height屬性 (或 CSS 入面 aspect-ratio),即使係 responsive 圖片。 - Web fonts 無
font-display: optional或匹配嘅 fallback metrics。 當你嘅自訂字型喺頁面 render 之後先加載,所有文字會喺字型 swap 入嚟時 reflow。修復係 preload 字型、用font-display: optional,或用size-adjust匹配 fallback metrics。 - 首屏上面動態插入內容。 個 banner 從 JS 加載並推 hero 落,係典型 CLS bug。用 CSS height reserve 個 space,即使內容初始為空。
INP —— 取代 FID 嘅新指標
直至 2024 年 3 月,第三個 Core Web Vital 係 FID (First Input Delay) —— 用戶首次互動到瀏覽器開始處理之間嘅時間。FID 易作弊,因為佢只量度首次互動。多數網站即使遲鈍都輕易過 FID。
INP 更難。佢量度整個頁面訪問期間最差嘅互動,唔只係第一個。如果用戶 click 個 dropdown,因為你嘅 React app 有重 useEffect 觸發要 600ms 回應,呢個就係你嘅 INP 分數。
通常嘅 INP 元兇:
- 大 JavaScript bundle,喺 hydration 期間 block main thread。
- 重事件 handler,做太多同步工作 (state 更新、layout reads、複雜計算)。
- 第三方腳本 (analytics、chat widgets、tag managers) 喺用戶互動期間佔用 main-thread 時間。
真正提升 Core Web Vitals 嘅工程操作
兩年運行呢啲審計之後,持續產生最大效果嘅操作 (按優先排列):
- 將你嘅 hosting 區域移近香港。 如果你喺 Vercel,將區域設為
sin1(新加坡) 或hkg1(香港,可用時)。AWS 用戶:ap-east-1(香港) 或ap-southeast-1(新加坡)。一個 config 改動。對香港用戶嘅 TTFB 下降 200-400ms。 - 喺 CDN 邊緣緩存渲染後 HTML。 喺靜態類型嘅營銷頁面加
Cache-Control: s-maxage=3600, stale-while-revalidate=86400。或用 Next.jsexport const revalidate = 3600做 ISR。第一個請求仍打你嘅伺服器;後續嘅唔再打。緩存後請求嘅 TTFB 下降到 50-100ms。 - 每個圖片加明確尺寸。
width、height,理想情況再加 CSSaspect-ratiorule 喺 container 上面。消除 CLS 最大嘅來源。 - Preload LCP 圖片。 喺 hero 圖片上面加
fetchpriority="high"同priority(Next.js)。瀏覽器喺 HTML 入面發現之前已經開始下載。 - Defer 第三方腳本。 將 analytics、chat widgets、tag managers 移到
strategy="lazyOnload"(Next.js) 或deferattribute。佢哋無一樣係時間敏感到要 block main thread。 - 積極 code-split。 唔需要喺首屏出現嘅每個 component 都應該 dynamic import。初始 JS 細啲 = LCP 快啲 = INP 好啲。
點解多數代理唔修呢啲嘢
上面清單上每一項都係工程工作,唔係 SEO 建議。需要識你 stack、可以寫 pull request、習慣 deploy 過程嘅人。多數 SEO 代理公司無呢隊人馬。佢哋可以識別問題 (任何好嘅審計都可以),但唔可以 ship 修復 —— 佢哋交畀你,然後祈禱你有時間。
呢個就係 Synque Grow 存在所要填補嘅 gap。我哋係跑 SEO 業務嘅工程師。發現同修復出自同一雙手。如果你嘅 CWV 分數喺 Google Search Console 阻住你,而你嘅開發團隊埋頭做產品工作,呢度就係我哋能加價值嘅地方。喺 WhatsApp 發 URL 畀我哋 —— 五個工作天,三到五個真實發現,修復路徑寫明。
延伸閱讀:Adyen、Nuvei、SwiftPass —— 支付整合對 SEO 嘅隱形稅 講解第三方支付腳本點樣可以喺對你收入最重要嘅頁面拖累 LCP 800ms+。