Three measurements of how a page feels
Core Web Vitals are three measurements of how a page feels to use: how long until the main content shows up, how quickly the page responds when you tap something and how much the layout jumps around while it loads. They were defined by the largest search engine and are reported in its free tools, and they form part of how it judges page experience.
Clients hear the term from a tool, a competitor or a cold email, and ask what it means and whether they are failing. This article is the explanation to give them. It uses the names, because they will see the names, and it translates each one into something they can feel on their own phone.
LCP: how long until the page looks loaded
Largest Contentful Paint, or LCP, is the time from tapping a link to the moment the biggest thing in the first screen has drawn. On most pages that is the hero image or the main headline. It is the measure that matches a visitor's sense of "the page has loaded", which is why it is the one that matters most to a client.
The published threshold for a good LCP is 2.5 seconds or less. Between 2.5 and 4 seconds needs improvement, and over 4 seconds is poor.
What moves it: the size of the hero image, how many fonts and scripts the browser has to fetch before it is allowed to draw and how quickly the server answers at all. A 3 megabyte hero image on a page served from the other side of the world is the usual story. What does not move it: anything below the first screen.
The specification is published by the W3C's web performance group, which is the non-commercial source to point a technical client at.
INP: how quickly the page responds when you tap
Interaction to Next Paint, or INP, measures the gap between a tap, click or key press and the screen visibly changing in response. It looks at every interaction during a visit and reports close to the worst one, so a page that responds instantly to most taps and freezes on the menu button will score on the menu button.
The published threshold for a good INP is 200 milliseconds or less. Between 200 and 500 needs improvement, and over 500 is poor.
What moves it: scripts that run on the main thread when something is tapped. Chat widgets, analytics bundles, animation libraries and a page builder that attaches a handler to everything are the common causes. What does not move it: server speed, once the page is loaded.
The client-friendly version: "when you tap the menu, does it open now or in a moment?"
CLS: how much the page jumps around
Cumulative Layout Shift, or CLS, is a score for unexpected movement. A page that loads its text, then pushes it down when an image or an ad arrives, then pushes it again when a font swaps in, has a high CLS. The visitor experiences it as trying to tap a button that moves.
The published threshold for a good CLS is 0.1 or less. Between 0.1 and 0.25 needs improvement, and over 0.25 is poor. The number is unitless; it combines how much of the screen moved and how far.
What moves it: images and embeds without a declared width and height, banners injected at the top of the page after load and web fonts that are a different size from the fallback. What does not move it: movement the visitor caused, such as opening a menu.
How the numbers are measured
Two things confuse clients about these scores. The first is that the real numbers come from real visitors. The engine that defines the vitals collects them from actual page views and reports the value at the 75th percentile, meaning three quarters of visits did at least that well. A lab test on a fast laptop in the studio can pass while the field number, dominated by phones on mobile networks, fails. When a client says "it loads fine for me", that is the explanation.
The second is that the numbers are per page, not per site. A homepage can be green and the service pages, built later by a different person with a heavier template, can be red. A single site-wide score is a summary, not a diagnosis.
What to tell a client, and what not to promise
Tell them the three measures in the words above: how long until it looks loaded, how fast it responds to a tap, how much it jumps. Tell them the thresholds, because they are published and a client will find them anyway. Tell them that the field numbers come from their real visitors, so a fix shows up in the data over weeks, not minutes.
Do not promise a ranking change. The vitals are part of how page experience is judged, alongside many other signals, and the honest claim is that a page which loads quickly and does not jump converts better and is easier to rank, not that a green score moves a position.
Do not promise a score from a public-page check either. Our hosted website audit reads the rendered page and reports what is there: structure, readability, contrast, overflow on a narrow screen, tap targets, a visible way to get in touch. Those sit beside the vitals and share causes with them, but the vitals themselves are measured from real visits and a lab run, which is a different tool. A maintenance plan report should carry both, and say which is which.
See what a website audit report finds on a real site. Get a free website audit: enter a URL and an email, and we check the public pages on our servers. We never log in and never touch your files.