Core Web Vitals are three measurements Google takes of how your site feels to use. Not how it looks, not what it says, but how it feels: how quickly the main content appears, how quickly the page responds when you interact with it, and whether things jump around while you're trying to read. They're part of technical SEO, they're expressed in numbers, and they're one of the few parts of SEO where Google tells you exactly what it wants.
That last part matters. Most ranking factors are inferred. This one comes with published thresholds, so let's use them.
The three vitals, in plain terms
Largest Contentful Paint (LCP)
How long the biggest thing on the screen takes to appear, usually a hero image or a headline. It's a proxy for "when did this page feel loaded?". Google's threshold for good is 2.5 seconds or less. Over 4 seconds is officially poor, and in practice feels broken on mobile.
Interaction to Next Paint (INP)
When you tap a button or open a menu, how long before the page visibly responds. The threshold for good is 200 milliseconds or less; over 500ms is poor. INP replaced the older First Input Delay measurement because FID was too easy to pass, and most sites that "passed" still felt sluggish. INP is stricter and closer to real experience.
Cumulative Layout Shift (CLS)
Whether the page moves around as it loads. You've felt this one: you go to tap a link and an advert loads above it, shoving everything down, and you tap the wrong thing. CLS is scored rather than timed, and 0.1 or less is good.
Do Core Web Vitals actually affect rankings?
Yes, but modestly, and less than the industry's obsession with them implies. Google has been consistent on this: page experience is a ranking signal, not the ranking signal. A page with the right content and poor vitals will usually beat a page with perfect vitals and the wrong content.
So why care? Two reasons. First, at the margin they decide ties, and competitive SERPs are full of ties. Second, and more importantly, the same slowness that fails LCP also loses customers. A store whose product pages take five seconds to appear on a phone doesn't have an SEO problem so much as a revenue problem that SEO happens to measure.
Field data beats lab data
This trips up almost everyone. There are two kinds of Core Web Vitals numbers, and they routinely disagree.
Lab data is a simulated test, which is what you get when you run Lighthouse or PageSpeed Insights' top section. It's useful for diagnosis but it's one synthetic device on one synthetic connection.
Field data is what real visitors experienced over the last 28 days, collected from Chrome users. This is what Google actually uses. You'll find it in PageSpeed Insights (the "what your real users are experiencing" section) and in Search Console's Core Web Vitals report.
If your lab score is ugly but your field data is green, you're fine. The reverse is the situation that needs work. Judge yourself on field data, always.
What usually fixes each one
I've fixed these on everything from publisher templates to Shopify themes, and the same handful of causes come up every time.
For LCP it's almost always the hero image or the server. Compress and properly size the largest image, serve it in a modern format, don't lazy-load it (lazy-loading the hero is a self-inflicted wound I still see weekly), and get the server responding fast. On a slow platform, caching or a better host does more than any amount of image fiddling.
For INP the culprit is JavaScript, and most of it is usually third-party: tag managers stuffed with trackers, chat widgets, A/B testing tools. The fix is less a technique than a negotiation about which scripts the business actually needs. Every marketing tag has a cost, and INP is where it shows up.
For CLS it's elements without reserved space: images without dimensions, ads, cookie banners, and web fonts swapping in late. Give everything a reserved slot and the shifting stops.
If you want the wider context for where this sits in a technical programme, start with what technical SEO actually is, then work through the technical SEO checklist, which covers vitals alongside everything else worth checking.
How to check your site in five minutes
Put your key pages through PageSpeed Insights and read the field data section only. Then open Search Console's Core Web Vitals report, which groups your whole site's URLs into good, needs improvement, and poor. That grouping is the to-do list. Fix the template causing the biggest group of poor URLs first, because vitals problems are almost always template problems, and one fix repairs thousands of pages at once.
Core Web Vitals FAQs
What is a good Core Web Vitals score?
LCP of 2.5 seconds or less, INP of 200 milliseconds or less, and CLS of 0.1 or less, measured at the 75th percentile of real visitors. All three thresholds are published by Google, so there's no mystery about the target.
Will fixing Core Web Vitals improve my rankings?
Sometimes, modestly. If your content already competes and your vitals are poor, fixing them can decide close contests. If your content doesn't compete, perfect vitals won't save it. Fix them for the conversion gains and take any ranking lift as a bonus.
What replaced First Input Delay?
Interaction to Next Paint (INP) replaced First Input Delay (FID) in March 2024. It measures responsiveness across all interactions on a page rather than just the first one, and it's considerably harder to pass.
Do Core Web Vitals matter on mobile or desktop?
Both are measured, but mobile is where sites fail and where most of your traffic likely is. Judge yourself on the mobile numbers first.
Want a hand with any of this?
Tell me what you're working on and what you're trying to achieve, and I'll give you an honest view of whether I can help and what it would take.
Get in touch