Core Web Vitals sound like a subject for developers with three monitors. Four fifths of the time they are an oversized image at the top of the page. Once you have understood that, half the panic the topic usually causes goes away.
Google uses Core Web Vitals to measure how a page feels to a real visitor while it loads and while they use it. Three numbers, each describing a different moment. And all three are edge factors for ranking, not master switches. The real reason to improve them sits elsewhere: someone waiting four seconds for the first visible element is often gone before it appears.
LCP: when does the visitor see the important thing
Largest Contentful Paint measures how long it takes for the largest element in the visible area to load. Usually that is an image, a heading, or a hero section. Google draws the line at 2.5 seconds. Above that it gets tight.
The single most common cause of a poor LCP is mundane and therefore easy to fix: an uncompressed image near the top. A background image of 2.4 megabytes is not rare, and on a mobile connection loading that one file alone takes longer than the 2.5 seconds you are allowed. The order of repair: get the image down to a sensible size (a web image rarely needs more than 200 kilobytes), use a modern format like WebP, and tell the browser through the width and height attributes how big it will be.
CLS: does the layout jump while loading
Cumulative Layout Shift measures how much moves on the page while it builds. You know the effect: you go to tap a link, at the last moment an ad loads in above it, everything shifts, and you hit the wrong button. Google wants to see under 0.1.
The usual culprits are images without fixed dimensions, late-loading ad slots, and fonts that arrive late and then shove the text around. The most effective fix here is also the dullest: give every image and every embed fixed dimensions, so the space is reserved before the content arrives. The browser holds the gap open and nothing jumps.
INP: does the page respond when you use it
Interaction to Next Paint is the youngest of the three and replaced an older one called First Input Delay in 2024. It measures how long the page takes to respond visibly to an input. You tap a menu and it only opens half a second later, that is a poor INP. The threshold is 200 milliseconds.
INP is the most technical of the three and the one a small site is least likely to have a problem with. When it does, there is nearly always too much JavaScript behind it: third-party scripts, an overloaded builder theme, three different tracking tools all firing on the first click. Less of it helps more than any fine-tuning.
Where you measure, and why two numbers diverge
The tool is Google PageSpeed Insights. You enter your URL and get two blocks that will confuse you at first.
The upper block, "Field Data", comes from real Chrome users over the last 28 days. That is the number that counts for your ranking. The lower block, "Lab Data", is a single test under ideal conditions. It is useful for experimenting, because it reacts immediately when you change something. But rely on the field data for the verdict. A page can shine in the lab and fail in the field, because real visitors are on slower devices and connections.
A new or lightly visited page often shows no field data at all, because too few real measurements exist. Then the lab is all you have for now, and that is fine as long as you know it is the friendlier number.
The one number you can safely ignore
PageSpeed Insights shows a big circle at the top with a value between 0 and 100, usually in an alarming orange. That performance score is not a ranking factor. It is a report-card substitute calculated from the lab data, and it sends a lot of people into a panic even though Google does not count it at all.
What counts for your ranking is only the three field-data values LCP, CLS and INP, rated "good", "needs improvement" or "poor". A page can have a performance score of 68 and still sit in the green on all three vitals. If so, everything is fine, whatever the big circle looks like. Do not waste an afternoon lifting a 68 to a 95 when the three numbers that matter are already right.
Why you should not look at this in isolation
Load time is one factor among several, and rarely the one that produces the biggest jump. A perfectly fast page that answers the wrong question still does not rank. So work on Core Web Vitals belongs late in the order, not early. Which problems come first is in finding SEO problems.
And the connection to visitor behavior is direct: someone who leaves before anything is even visible still counts as a bounce in Analytics. A slow page can produce a high bounce rate that looks like a content problem and is really a load problem. How to separate the two is in reducing bounce rate.
Where to start
Enter your most important page in PageSpeed Insights, look only at the field data and only at the phone. If LCP is over 2.5 seconds, open the page and find the largest image near the top. In the vast majority of cases that is your afternoon project, and once you solve it you have essentially dealt with the topic for that page.