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+。