Core Web Vitals are three measurements Google uses to judge whether a page feels fast to a real person. They are not abstract engineering metrics. Each one corresponds to a specific irritation you have experienced yourself.
Largest Contentful Paint: how long until something useful appears
LCP measures when the biggest visible element finishes rendering. Usually that is your hero image or your main heading. It answers the question a visitor is asking without words: is anything going to happen?
Under 2.5 seconds is considered good. Over 4 seconds is poor.
The usual cause of a bad LCP is an oversized hero image. The second most common is a font that blocks the heading from rendering. The third is a slow server response, which delays everything downstream.
The fix is nearly always the same: make the largest thing smaller, and make sure the browser starts fetching it early rather than discovering it halfway through parsing the page.
Interaction to Next Paint: how long until the page responds to you
INP replaced an older metric called First Input Delay, and it is stricter. It measures the delay between you interacting with something and the page visibly reacting. Tapping a menu and watching nothing happen for half a second is exactly what this catches.
Under 200 milliseconds is good. Over 500 is poor.
Bad INP is almost always JavaScript. The browser can only do one thing at a time, so while a script is running your tap sits in a queue. Heavy page builders, chat widgets, and analytics that do work on every interaction are the common culprits.
This is the hardest of the three to fix, because it usually means removing functionality rather than optimising it.
Cumulative Layout Shift: how much the page jumps around
CLS measures content moving after it has appeared. You start reading, an image loads above where you are looking, and the text jumps down. Or you go to tap a button and an advert pushes it sideways at the last moment.
Under 0.1 is good. Over 0.25 is poor.
The cause is nearly always an element that arrives without the browser knowing how much space to reserve. Images without width and height attributes. Adverts injected into the flow. A cookie banner that pushes everything down. Web fonts that swap in at a different size to the fallback.
CLS is the easiest of the three to fix and the most annoying to visitors, which makes it the best place to start.
Two things worth knowing
First, the scores Google actually uses come from real visitors, not from a testing tool. Lab tools like Lighthouse simulate a device and give you a number instantly, which is useful for debugging. But ranking signals come from field data collected from real Chrome users over the previous 28 days. That means a fix made today will not show up in the data that matters for weeks.
Second, lab scores move between runs on identical pages. If you test twice and get different numbers, nothing is broken. Take the trend across several runs.
How much does this affect rankings
Less than people selling performance work would like you to believe, and more than nothing.
Core Web Vitals are a genuine ranking signal, but a small one relative to whether your page actually answers the query. A fast page about the wrong thing will not outrank a slower page that answers the question properly.
Where the effect is unambiguous is in behaviour. People leave slow pages. That shows up in your conversion rate long before it shows up in your rankings, and it is the better reason to care.
A sensible order of work on Core Web Vitals
- Fix layout shift first. It is cheap, it is visible, and it irritates people most.
- Then attack LCP through image weight and format.
- Then audit scripts for INP, accepting that some will need removing rather than tuning.
If you want this measured on your own pages rather than guessed at, the free check on our homepage runs a live audit, and our maintenance work covers the follow-through.
Related reading
- Your contact form is probably the weakest part of your website — The contact form is where a website pays for itself. The common faults that lose enquiries, and what to do about each one, with a test you can run today.
- How to brief a website project so the quotes are comparable — Three quotes that differ fourfold mean three agencies solved three different problems. How to brief a website project so the numbers are comparable.
- Why internal tools stop being used three months after launch — Internal tools rarely fail technically. They fail because they make someone slower, cannot express the exception, or have nobody who owns them.