Core Web Vitals are Google's attempt to measure how a page feels to a real person, not how fast a server responds. There are three of them, they map to three distinct frustrations, and they're a confirmed part of how Google ranks pages. The good news: on a typical marketing site, a handful of fixes move all three.
The three metrics, in plain terms
Each vital has a "good" threshold. You want to hit it for most of your real visitors, not just once in a lab test.
LCP, Largest Contentful Paint (loading)
LCP measures how long it takes for the biggest visible thing, usually a hero image or a headline, to appear. It answers "did the page load?" from the visitor's point of view. Good is under 2.5 seconds. The usual culprits are heavy images, slow servers, and render-blocking scripts and fonts.
INP, Interaction to Next Paint (responsiveness)
INP measures how quickly the page reacts when someone taps or clicks, across the whole visit. It answers "did it respond?" Good is under 200 milliseconds. INP replaced First Input Delay (FID) as a Core Web Vital in March 2024, and it's stricter: it catches sluggishness caused by too much JavaScript running on the main thread, not just the first interaction.
CLS, Cumulative Layout Shift (visual stability)
CLS measures how much the page jumps around as it loads. If you've ever gone to tap a button and an ad shoved it out of the way, that's layout shift. Good is under 0.1. It's almost always caused by images and embeds with no reserved space, or fonts that swap and reflow the text.
Why your Lighthouse score and Search Console disagree
This trips up almost everyone. There are two kinds of measurement, and they answer different questions:
- Lab data (Lighthouse, PageSpeed Insights' simulated run) tests your page once, on a simulated device and network. It's great for debugging because it's repeatable, but it's not what Google ranks on.
- Field data (the Chrome User Experience Report, or CrUX) is collected from real Chrome users over the previous 28 days. This is what appears in Search Console and what actually feeds ranking.
So a perfect Lighthouse score can sit next to a failing Search Console report, because your real visitors are on slower phones and networks than the lab assumes. Fix for the field, verify in the lab.
The fixes that move the needle most
You rarely need to chase all three separately. On most sites, the same performance hygiene lifts every score at once.
To improve LCP
- Serve the hero image in a modern format (WebP or AVIF), correctly sized, and set explicit
widthandheight. A framework's image component usually does this for you. - Preload the LCP image and the fonts used in the headline.
- Cut render-blocking CSS and JavaScript, and put your site behind a CDN.
To improve INP
- Ship less JavaScript. Every kilobyte you don't send is work the browser skips.
- Break up long tasks and defer non-critical work so the main thread stays free.
- Avoid heavy third-party scripts; load tag managers and chat widgets lazily.
To improve CLS
- Always reserve space for images, video, and ads with explicit dimensions.
- Load web fonts with
font-display: swapand preload them to reduce the reflow when the real font arrives. - Never insert content above what someone is already reading.
How to measure it yourself
Start with the field data. Open Google Search Console's Core Web Vitals report to see which URL groups pass or fail for real users. Then reproduce the problem locally with Lighthouse or the PageSpeed Insights lab run, fix it, and wait for the 28-day field window to reflect the improvement. For live debugging, the web-vitals library and Chrome DevTools' Performance panel show you exactly which element or script is to blame.
Core Web Vitals are one input among many in ranking, but they're a tie-breaker you control, and a fast site converts better regardless of SEO. Getting them right is a core part of technical SEO, and often the cleanest moment to fix them is during a website redesign, when performance can be built in rather than bolted on.