Core Web Vitals, explained without the jargon

Core Web Vitals are three measurements of how a page feels to use. Google collects them from real Chrome visitors and uses them as a small ranking signal.

The three measurements

Largest paint (LCP): when the main thing appears. Usually the hero image or headline. Good is 2.5 seconds or less.

Interaction delay (INP): how quickly the page responds when you tap or click. It measures the worst noticeable delay during a visit. Good is 200 milliseconds or less.

Layout shift (CLS): how much the page jumps while loading. The score is unitless; good is 0.1 or less. This is the one people feel most: you go to tap a button and an advert pushes it away.

A page passes only when all three are good for at least 75% of visits.

Lab data and field data

Two kinds of number look the same and mean different things.

• Lab: Lighthouse or PageSpeed Insights loads the page once on a simulated mid-range phone. Repeatable, good for diagnosing causes, but it is one visit on one connection.
• Field: the Chrome UX Report, gathered from real visitors over 28 days. This is what Google uses, and what Rankwell shows as "speed for real visitors".

If the lab says 95 and the field data says otherwise, believe the field data: your visitors have slower phones or connections than your test.

Small sites often have no field data at all, because Google needs enough visits to publish it. Then lab numbers are all you have.

What actually moves each number

For largest paint

• Serve the hero image in a modern format (WebP or AVIF) at the size it is displayed, not the size it was uploaded.
• Do not lazy-load the hero image; that delays the very thing being measured.
• Cut the time your server takes to respond. Caching and a CDN usually help most.
• Preload the font used in the headline, and use font-display: swap so text appears before the font arrives.

For interaction delay

• Ship less JavaScript. Every script competes for the same thread that handles taps.
• Split long tasks. A single 500 ms task blocks every interaction during it.
• Be careful with third-party tags: chat widgets, analytics, consent banners and A/B testing tools are frequent culprits.

For layout shift

• Set width and height (or an aspect-ratio) on every image and video.
• Reserve space for adverts, banners and embeds before they load.
• Avoid injecting notices above content after the page has rendered.

A sensible order of work

1. Get field data if you have it: Search Console, or Rankwell's domain overview, which reads the Chrome UX Report for any site.
2. Fix the worst of the three, not all three at once.
3. Re-measure after a week of real traffic. Field data moves slowly, because it covers 28 days.

What "good enough" means

Perfect scores are not the goal. A page that appears in about two seconds on a mid-range Android phone over an ordinary connection is fine, and further work has diminishing returns compared with writing a better page.

Rankwell shows both sides: real-visitor Core Web Vitals with their weekly trend, and a Lighthouse test with performance, SEO, accessibility and best-practice scores, in domain overview. The site audit adds server response time for every crawled page, which is where slow pages usually start.