Core Web Vitals in 2026: What Actually Moves HK Google Rankings

Core Web Vitals have been a confirmed Google ranking signal since 2021. The thresholds tightened in 2024 when INP replaced FID. And for Hong Kong sites in particular, one of the three metrics is being silently broken by something that has nothing to do with your front-end code: TTFB. This post walks through what each metric actually measures, why HK sites struggle with it specifically, and the engineering moves that move the needle.

The three metrics, in plain English

Google's Core Web Vitals are three measurements that try to capture the user experience of loading a web page. Each has a "good" threshold and a "poor" threshold. Above the good threshold, you score full points. Below the poor threshold, you take a ranking hit. In between, you're "needs improvement."

Metric	What it measures	Good	Poor
LCP (Largest Contentful Paint)	How long until the biggest visible thing renders	≤ 2.5s	> 4.0s
CLS (Cumulative Layout Shift)	How much the page jumps around while loading	≤ 0.1	> 0.25
INP (Interaction to Next Paint)	How long until the page responds to clicks/taps	≤ 200ms	> 500ms

Google uses field data, not lab data. The numbers come from real Chrome users via the Chrome User Experience Report (CrUX), and they're measured at the 75th percentile. That means even if your site is fast for most users, if one in four users sees >4s LCP, you take the ranking hit.

LCP is the one that matters most for HK sites

We've audited dozens of HK sites — fintech, F&B, e-commerce, travel — and the same pattern shows up: LCP is poor on almost every one of them, and the same root cause keeps appearing. It's not unoptimized images. It's not bloated CSS. It's TTFB — the time from the user's click to the first byte of HTML arriving in the browser.

TTFB is part of LCP. If your server takes 800ms to respond, your LCP is already at 800ms before any rendering happens. Add image loading, font fetching, JS hydration, and you're easily past the 2.5s good threshold.

Why is TTFB so often the problem for HK sites? Three reasons:

1. Server location. If your hosting region is in the US (the default for many startups using Vercel, Netlify, or AWS), every request from a Hong Kong user has to cross the Pacific. That's a ~150ms baseline before any work happens. Combined with cold-start times on serverless platforms, TTFB easily passes 500ms.
2. SSR without edge caching. Modern Next.js sites server-render every request. If the rendered HTML isn't cached at the CDN edge, every visitor pays the full server-render cost.
3. Heavy database queries on the critical path. A homepage that fetches product data, user state, and i18n translations sequentially on every request can spend 200-400ms inside its own server before the first byte goes out.

What we've seen on synque.hk itself — Round 4 of our public SEO audit caught TTFB at 1,000-1,300ms on every Tier-1 landing — well into Google's "Poor" zone. The fix isn't one big change; it's ISR for static-ish pages, Cache-Control: s-maxage headers for marketing routes, and a Vercel region check.

CLS — the silent SERP-killer most teams don't notice

CLS measures how much content jumps around as the page loads. Imagine you're about to tap a button, and right before your finger lands, an ad loads above it and pushes the button down — so you tap something else instead. That's a layout shift, and Google penalizes it heavily.

The most common causes in our audits:

• Images without explicit dimensions. When the browser doesn't know an image's aspect ratio, it renders the page first and then re-flows when the image loads. Every modern image tag needs width + height attributes (or aspect-ratio in CSS), even for responsive images.
• Web fonts without font-display: optional or matching fallback metrics. When your custom font loads after the page renders, all the text re-flows when the font swaps in. The fix is either to preload the font, use font-display: optional, or use size-adjust to match the fallback metrics.
• Dynamic content insertions above the fold. A banner that loads from JS and pushes the hero down is a classic CLS bug. Reserve the space with CSS height, even if the content is empty initially.

INP — the new metric that replaced FID

Until March 2024, the third Core Web Vital was FID (First Input Delay) — the time between a user's first interaction and the browser starting to process it. FID was easy to game because it only measured the first interaction. Most sites passed it trivially even when they were sluggish.

INP is harder. It measures the worst interaction during the entire page visit, not just the first one. If a user clicks a dropdown that takes 600ms to respond because your React app has a heavy useEffect firing, that's your INP score.

The usual INP villains are:

• Large JavaScript bundles that block the main thread during hydration.
• Heavy event handlers that do too much work synchronously (state updates, layout reads, complex calculations).
• Third-party scripts (analytics, chat widgets, tag managers) that take main-thread time during user interactions.

The engineering moves that actually shift Core Web Vitals

After two years of running these audits, the moves that consistently produce the biggest wins are these (in priority order):

1. Move your hosting region close to HK. If you're on Vercel, set the region to sin1 (Singapore) or hkg1 (Hong Kong, when available). AWS users: ap-east-1 (Hong Kong) or ap-southeast-1 (Singapore). One config change. Drops TTFB 200-400ms for HK users.
2. Cache rendered HTML at the CDN edge. Add Cache-Control: s-maxage=3600, stale-while-revalidate=86400 on static-ish marketing pages. Or use Next.js export const revalidate = 3600 for ISR. The first request still hits your server; subsequent requests don't. TTFB on cached requests drops to 50-100ms.
3. Add explicit dimensions to every image. width, height, and ideally an aspect-ratio CSS rule on the container. Eliminates the biggest source of CLS.
4. Preload the LCP image. Add fetchpriority="high" and priority (Next.js) on the hero image. The browser starts downloading it before discovering it in the HTML.
5. Defer third-party scripts. Move analytics, chat widgets, and tag managers to strategy="lazyOnload" (Next.js) or defer attribute. None of them are time-sensitive enough to block the main thread.
6. Code-split aggressively. Every component that isn't needed in the first viewport should be dynamically imported. Smaller initial JS = faster LCP = better INP.

Why most agencies don't fix this

Every item on the list above is engineering work, not SEO advice. It requires someone who knows your stack, can write a pull request, and is comfortable with the deploy process. Most SEO agencies don't have that team. They can identify the problems (any good audit will), but they can't ship the fix — they hand it to you and hope you have the time.

This is the gap Synque Grow exists to close. We're engineers running an SEO practice. The finding and the fix come from the same hands. If your CWV scores are blocking you in Google Search Console and your dev team is buried in product work, that's exactly where we add value. Send us a URL on WhatsApp — five business days, three to five real findings, the fix path spelled out.

---

Related reading: Adyen, Nuvei, SwiftPass — the hidden SEO tax on payment integrations explains how third-party payment scripts can drag LCP by 800ms+ on the page that matters most to your revenue.