Core Web Vitals: The Three Numbers That Actually Move Rankings
LCP, INP and CLS decide how Google sees your site and how users experience it. Here is what each one measures, the thresholds that matter, and the fixes that work in practice.
Most performance advice is a list of tactics with no way to tell which ones matter for your site. Core Web Vitals fix that, because they reduce the question to three numbers Google actually measures on real visitors.
The thresholds
A page passes when 75% of real visits land in the "good" band for all three metrics. That last part trips people up: your own fast laptop on office wi-fi is not the measurement. Field data from real users is.
| Metric | Good | Needs work | Poor |
|---|---|---|---|
| LCP — Largest Contentful Paint | ≤ 2.5s | 2.5–4.0s | > 4.0s |
| INP — Interaction to Next Paint | ≤ 200ms | 200–500ms | > 500ms |
| CLS — Cumulative Layout Shift | ≤ 0.1 | 0.1–0.25 | > 0.25 |
LCP: how fast the main thing appears
LCP measures when the largest element in the viewport finishes rendering — usually a hero image, a video poster, or a large block of text.
The single most effective change we make on client sites is making the LCP element text rather than an image. Text renders as soon as the font and HTML arrive. A hero image has to be discovered, downloaded and decoded first, and on a 4G connection in Dhaka that is often two extra seconds.
When a hero image is non-negotiable:
- Mark it
priority(orfetchpriority="high") so it is not lazy-loaded - Preload it in the document head so discovery does not wait for CSS
- Serve AVIF or WebP at the actual displayed size, not a 3000px original
- Never put it behind a client-side component that hydrates before rendering
// The LCP image should never be lazy — that is the one image that must not wait.
<Image
src="/hero.avif"
alt="Team reviewing an architecture diagram"
width={1200}
height={675}
priority
sizes="(max-width: 768px) 100vw, 1200px"
/>INP: how fast the page answers
INP replaced First Input Delay in 2024, and it is stricter. FID only measured the delay before processing started. INP measures the whole round trip — input, processing, and the next paint — across every interaction on the page, then reports close to the worst one.
Bad INP is almost always too much JavaScript running on the main thread. The usual culprits:
- A large client-side bundle hydrating components that never needed interactivity
- Expensive work in a click handler that could be deferred or debounced
- Third-party scripts — chat widgets, analytics, tag managers — competing for the thread
The structural fix is to ship less JavaScript. In a React Server Components setup that
means keeping "use client" at the leaves: a header that tracks scroll position needs to
be a client component, but the section it sits above does not.
CLS: how much the page moves
CLS is the easiest to fix and the most irritating to users — the tap that lands on the wrong button because an ad loaded above it.
Three rules eliminate most of it:
- Always set
widthandheight(oraspect-ratio) on images, videos and iframes, so the browser reserves the space before the file arrives. - Reserve space for anything injected later — banners, cookie notices, embeds. Give the container a fixed height rather than letting it push content down.
- Use
font-display: swapwith a matched fallback. A swap from a fallback font with very different metrics causes a visible reflow;size-adjustor a framework's font fallback generation keeps the two sizes close.
Measure the field, not the lab
Lighthouse gives you a lab score on a simulated connection. It is useful for catching regressions, but it is not what Google ranks on.
For real numbers, use:
- Chrome UX Report (CrUX) — the actual dataset behind the Core Web Vitals assessment
- Search Console's Core Web Vitals report — CrUX data grouped by URL pattern
- Real-user monitoring via the
web-vitalslibrary, which lets you correlate scores with device, country and connection type
That last one matters most for Bangladeshi audiences. A site that scores 98 on a simulated desktop run can still fail its field assessment because most real visits arrive on mid-range Android phones over mobile data.
Where to start
If you only do three things:
- Make sure the LCP element is text, or a preloaded, correctly sized image
- Audit which components genuinely need client-side JavaScript, and remove the rest
- Set explicit dimensions on every image and reserve space for late-loading content
That usually takes a failing site into the good band without a rewrite.
Want a performance audit of your site with specific, prioritised fixes? Get in touch — we will send you the numbers before we send you a proposal.