Core Web Vitals are three measurements Google publishes about how a page feels to use. They exist because "is this page good?" is unanswerable and "did the main thing appear within two and a half seconds?" is not.
There are three of them, they each have an acronym, and the acronyms are why most explanations of this topic are unreadable. Here they are in the order they matter.
1. How long until the main thing appears
Largest Contentful Paint, or LCP.
The clock starts when someone clicks the link and stops when the biggest visible thing on the screen has finished drawing — usually the hero image or the headline. It is a decent proxy for the moment a visitor stops feeling like they are waiting.
- Good: under 2.5 seconds
- Needs work: 2.5 to 4 seconds
- Poor: over 4 seconds
What makes it bad, in order of frequency: an enormous hero image; a slow server taking a second to reply before anything can start; stylesheets and scripts in the page head that the browser must fetch and process before it will draw a single pixel; and custom fonts that hold the headline hostage.
What actually fixes it: compress and resize that hero image, and serve it in a modern format. That one change fixes more of these than everything else combined. After that: caching so the server replies quickly, and moving anything non-essential out of the way of the first render.
This is the vital worth spending money on. It correlates most directly with people leaving.
2. How quickly the page reacts when you touch it
Interaction to Next Paint, or INP. This replaced an older measurement called First Input Delay in 2024; if you are reading an article that talks about FID, it is out of date.
It measures the gap between you tapping something and the screen visibly changing in response. Not how long the action takes to complete — how long until the page acknowledges you at all.
- Good: under 200 milliseconds
- Needs work: 200 to 500 milliseconds
- Poor: over 500 milliseconds
Two hundred milliseconds sounds impossibly strict. It is roughly the threshold below which a response feels instant and above which it feels like the page is thinking.
What makes it bad: too much JavaScript running at once. A browser does one thing at a time, and while it is busy running a script it cannot respond to your tap. The usual culprits are a heavy page builder, a wall of third-party scripts, or a chat widget waking up at exactly the wrong moment.
What fixes it: less JavaScript. There is no clever configuration that makes a slow page feel fast here — the work either happens or it does not. Removing scripts you are not using is the accessible version of this fix.
3. How much the page jumps around while loading
Cumulative Layout Shift, or CLS.
You go to tap a link, an advert loads above it, everything moves down, and you tap something else. That is layout shift, and this measures how much of it happens.
- Good: under 0.1
- Needs work: 0.1 to 0.25
- Poor: over 0.25
The number is a unitless score rather than seconds — how much of the screen moved, multiplied by how far.
What makes it bad: images without width and height set, so the browser does not reserve space for them and the text jumps when they arrive. Adverts and embeds injected into the flow of the page. Cookie banners that push content down. Custom fonts that swap in at a different size to the fallback.
What fixes it: reserve the space. Set width and height on every image, give ad and embed slots a fixed size, and overlay banners rather than inserting them.
This is the cheapest of the three to fix and the most annoying to experience.
Lab data and field data — why two tests disagree
This confuses more people than the acronyms do.
Lab data is one simulated load, run now, on a deliberately throttled connection and a mid-range phone. It is repeatable and it is excellent for diagnosis, because you can change one thing and re-run it.
Field data is what real visitors actually experienced on your site over the last 28 days, collected from real Chrome users. It is messy, it lags a month behind your changes, and it is the one Google ranks on.
So a page can score beautifully in the lab and fail in the field — often because real visitors are on worse phones than the simulation assumes, or because your traffic is heavily mobile and the test was not. If the two disagree, the field data is the truth and the lab data is the explanation.
Field data also has a threshold most summaries skip: a page passes only when 75% of visits meet the target. The headline figure is the 75th percentile, not the average. One in four visits can be poor and you still pass; a third can and you do not.
How much does any of this matter?
Honestly: less than the amount written about it suggests, and more than nothing.
For ranking, Core Web Vitals are a real but small signal. They break ties between comparable pages. No amount of optimisation will float a page that does not answer the question above one that does, and a slow page with the right answer routinely outranks a fast page with the wrong one.
For your business, the case is stronger and does not depend on Google at all. People leave slow pages. People mis-click on pages that move. Every study on this points the same direction even if the exact percentages vary, and unlike a ranking change you can see the effect in your own analytics.
So the sensible position is: fix Largest Contentful Paint because visitors abandon slow pages; fix layout shift because it is cheap and infuriating; and treat the interaction score as a reason to delete the four tracking scripts nobody has used since last year. Do not rebuild your website to chase a number.
What to check first
- Look at the field data, not the lab score. That is what is being judged.
- If the main content is slow to appear, look at your hero image before anything else.
- If the page jumps, set dimensions on your images. This is usually an afternoon.
- If it is slow to respond, count your third-party scripts and delete the dead ones.
- Re-measure after 28 days, not after an hour. Field data moves slowly, and changing three things and re-testing immediately tells you nothing.