What Core Web Vitals are and why Google cares

Three numbers describe how a page feels: how fast it shows, how quickly it reacts, how much it jumps. What each measures, the targets, and how to read yours.

3 minread 627words last updated

The short answer

Core Web Vitals are three numbers Google uses to describe how a page feels to a real person: how long until the main content is visible, how quickly the page reacts when you tap or click, and how much the layout jumps around while loading. Google publishes targets for each and measures them from real visitors’ browsers.

They matter for two reasons. Google says they are used in ranking. And, more directly, they are a decent proxy for whether visitors stay long enough to do what you wanted them to do.

The three metrics

MetricWhat it measuresGoodTypical cause of a bad score
Largest Contentful Paint (LCP)Time until the largest visible element, usually the hero image or heading, is on screen2.5 s or lessHeavy images, slow server, render-blocking scripts and fonts
Interaction to Next Paint (INP)Delay between a tap or click and the screen visibly responding, across the whole visit200 ms or lessToo much JavaScript running on the main thread
Cumulative Layout Shift (CLS)How much visible content moves unexpectedly while loading0.1 or lessImages without dimensions, late-loading banners, fonts swapping

Field data versus lab data

Two kinds of numbers exist, and confusing them wastes a lot of effort.

  • Field data comes from real visitors’ browsers, collected over the past 28 days. This is what Google uses. You find it in Search Console and, when there is enough traffic, in PageSpeed Insights.
  • Lab data is a simulated visit from one machine with fixed settings. Lighthouse scores are lab data. Useful for finding causes, useless as a report card.

What moves each number

LCP. Make the largest element arrive first: an optimised hero image in a modern format with the right size for the screen, loaded with priority, from a network location close to the visitor. Remove scripts and stylesheets that block rendering. A static site served from a CDN starts with a large head start here.

INP. Ship less JavaScript and run less of it on load. Every tracking tag, chat widget and slider adds work the phone must do before it can respond to a tap. Pages that are mostly HTML with small interactive islands rarely have an INP problem.

CLS. Give every image and embed explicit dimensions so space is reserved before it loads. Do not insert banners above content after the page has rendered. Load fonts so that text does not reflow.

What this means for you

Open Search Console, find the Core Web Vitals report, switch to mobile, and look at which URL groups are “poor” or “needs improvement”. Those pages are losing visitors right now, regardless of what any lab score says. Fixing them is usually a matter of images, scripts and layout, in that order, and it is work a good web partner does as a matter of routine rather than as a project.

Written by the CivSec S.M.A.R.T team

We build and run websites, software and AI systems for businesses. We write about what we see in that work, in plain language, and we update articles when things change.

Last checked . Spotted something outdated? Tell us.

Frequently asked questions

Are Core Web Vitals a ranking factor?

Google's page experience documentation states that Core Web Vitals are used by its ranking systems. In practice they act as one signal among many, most visible when pages compete on similar content. Do not expect a jump from tuning alone; do expect a penalty-like effect from pages that fail badly.

Where do I see my own numbers?

Google Search Console has a Core Web Vitals report based on real visitors. PageSpeed Insights shows both field data, when available, and a lab test. Look at the field data first, on mobile, for your most visited pages.

What is a good score?

There is no single score. A page is in the good range when LCP is 2.5 seconds or less, INP is 200 milliseconds or less, and CLS is 0.1 or less, at the 75th percentile of visits. All three, on mobile, for your important pages.

Why does my page pass on desktop and fail on mobile?

Phones have slower processors and worse connections than your office laptop. JavaScript that runs in a blink on a desktop takes far longer on a mid-range phone, and images that look fine on Wi-Fi are heavy on mobile data. Mobile is the number that matters.

Sources

  1. Google web.dev: Web Vitals (accessed 2026-09-11)
  2. Google Search Central: Understanding page experience in Google Search results (accessed 2026-09-11)