Core Web Vitals: How to Diagnose and Fix Them (2026)
Core Web Vitals are Google's attempt to measure something real: does your page actually feel fast and stable to the person using it? They're a ranking factor — a light one, but a real one — and they quietly cost you conversions even when they don't cost you rankings. Here's what the three metrics mean, how to find which one your site is failing, and exactly how to fix each, using free tools and the data that actually counts.
What Core Web Vitals are (and why SEO cares)
Core Web Vitals are three metrics Google uses to put a number on real-world page experience. They're part of Google's page experience signals, and crucially they're measured from real Chrome users on your live site — not from a synthetic test. If your pages are slow to load, sluggish to respond, or jump around as they load, Vitals capture it.
For SEO, keep the weight honest: Vitals are a confirmed ranking factor, but a relatively light one. They work mostly as a tiebreaker — between two pages of similar relevance and authority, the better experience wins, and the effect is most visible on mobile. Brilliant content with mediocre Vitals can still rank. But poor Vitals also hurt conversions directly: a page that takes four seconds to become usable loses people before they read a word. So you fix Vitals for two reasons, and ranking is only one of them.
The three metrics, in plain English
- LCP — Largest Contentful Paint (loading). How long until the biggest visible element — usually the hero image or headline — has rendered. It answers "how long until the page looks loaded?" Good: ≤ 2.5 seconds.
- INP — Interaction to Next Paint (responsiveness). How quickly the page visually responds when a user taps, clicks or types. INP replaced First Input Delay in March 2024 and is stricter — it measures the whole interaction, not just the first one. Good: ≤ 200 milliseconds.
- CLS — Cumulative Layout Shift (visual stability). How much the content jumps around as the page loads — the maddening moment you go to tap a button and an ad shoves it down. It's a unitless score. Good: ≤ 0.1.
A page passes only when all three are in the "good" band for at least 75% of visits. One metric in the red and the page fails, however good the other two are.
Field data vs lab data — the distinction that trips everyone up
This is the single most misunderstood thing about Vitals, so get it straight before you touch anything.
- Field data (CrUX): real measurements from real Chrome users, over a rolling 28-day window. This is what Search Console shows and what Google ranks on. It's the truth.
- Lab data: one simulated test in a controlled environment — the headline Lighthouse score in PageSpeed Insights. Repeatable and great for debugging, but it's a lab, not your audience.
They frequently disagree, and that's fine. A page can score a middling 60 in the lab yet pass Vitals in the field, or score 95 in the lab and fail in the field on a slow mid-range Android phone. When they conflict, the field wins — chase real-user data, not a perfect lab score.
How to diagnose your Core Web Vitals
Three steps, all free:
1. Start in Search Console. Open the Core Web Vitals report (Mobile and Desktop tabs). It groups your URLs into "Poor", "Needs improvement" and "Good", and tells you which metric is failing on which group of pages. This is your field-data map of the problem.
2. Drill into a failing URL with PageSpeed Insights. Run a representative failing page. Read the field data at the top (the real verdict), then use the lab diagnostics below it — "Opportunities" and "Diagnostics" — to see what is causing the failing metric.
3. Isolate the cause with DevTools. For stubborn cases, Chrome DevTools (Performance panel) shows you exactly which element is the LCP, which script is blocking interactivity, and which element shifted. Now you're fixing a known cause, not guessing.
How to fix each metric
Fixing LCP (slow loading)
LCP is usually about how fast your main image or headline arrives. In order of impact:
- Cut server response time (TTFB). Good hosting, caching, and a CDN. A slow server makes everything else moot.
- Optimise the LCP image. Compress it, serve modern formats (WebP/AVIF), size it correctly, and
preloadit so the browser fetches it early. Don't lazy-load the hero image — that's a classic self-inflicted LCP failure. - Remove render-blocking resources. Defer non-critical CSS/JS so they don't hold up the first paint.
- Use a CDN so assets are served from near the user — especially valuable for an India-based site serving international visitors.
Fixing INP (sluggish responsiveness)
INP is almost always a JavaScript problem — the main thread is too busy to respond when the user interacts.
- Break up long tasks. Split heavy JavaScript so no single task blocks the main thread for long.
- Reduce and defer third-party scripts. Chat widgets, heavy analytics, ad scripts and tag managers are the usual culprits. Load them late (this site loads its tag manager only after first interaction — same principle).
- Trim the work done on each interaction. Heavy event handlers that recalculate or re-render too much are common INP killers.
- Minimise main-thread work overall — less JavaScript shipped is less to execute.
Fixing CLS (content jumping around)
CLS is the most fixable of the three — it's almost always about reserving space.
- Always set width and height (or CSS
aspect-ratio) on images, videos and iframes so the browser reserves the space before they load. - Reserve space for ads and embeds so injected content doesn't shove the page down.
- Use
font-display: optionalorswapand preload key fonts to avoid text reflowing when a web font arrives. - Never insert content above existing content (banners, notices) once the page has rendered, unless in response to a user action.
How long until Google sees the fix?
Patience is part of the job. Because field data uses a rolling 28-day window, an improvement you ship today won't fully show in Search Console for about a month, and Google then has to recrawl and re-evaluate. Use PageSpeed Insights lab data to confirm the fix worked immediately, then watch the Search Console Core Web Vitals report climb over the following weeks as real-user data catches up. Don't panic if the field number lags — that's expected.
What not to obsess over
- Don't chase a Lighthouse 100. A perfect lab score is satisfying and irrelevant. Passing field Vitals at the 75th percentile is the goal; the last 10 lab points usually aren't worth the effort.
- Don't treat Vitals as a ranking silver bullet. They're a tiebreaker. If you're not ranking, relevance, content quality and authority are almost always the bigger problem — see why your website isn't ranking.
- Don't optimise pages nobody visits. Fix Vitals on your highest-traffic, highest-value templates first; a flawless contact page moves nothing.
- Don't forget mobile. Google indexes mobile-first and Vitals fail most often on mid-range phones — test there, not just on your fast laptop.
Frequently asked questions
What are Core Web Vitals?
Three metrics Google uses to measure real-world page experience: Largest Contentful Paint (LCP, loading), Interaction to Next Paint (INP, responsiveness), and Cumulative Layout Shift (CLS, visual stability). They're part of Google's page experience signals and are measured from real Chrome users visiting your site, not from a lab test.
What is a good Core Web Vitals score?
Measured at the 75th percentile of your real visitors: LCP of 2.5 seconds or less, INP of 200 milliseconds or less, and CLS of 0.1 or less. A page passes only when all three are in the "good" range for at least 75% of visits.
Do Core Web Vitals affect SEO rankings?
Yes, but as a relatively light factor — strongest as a tiebreaker between pages of similar relevance, and most noticeable on mobile. Great content with poor Vitals can still rank, but you're giving up an edge, and poor Vitals hurt conversions regardless of rankings. Treat them as a foundation, not a magic lever.
What's the difference between field data and lab data?
Field data (CrUX) is collected from real Chrome users over a rolling 28-day window — this is what Google ranks on and what Search Console shows. Lab data is a single simulated test, like the Lighthouse score in PageSpeed Insights. Lab data is great for debugging; field data is what counts for SEO. When they disagree, trust the field.
Why is my PageSpeed Insights score different from Search Console?
They show different things. The big PageSpeed number is a lab score from one simulated test of a single URL. Search Console reports field data — the real-world Vitals of your actual visitors over 28 days. A page can score 60 in a lab test but pass Vitals in the field, or vice versa. For SEO, the Search Console field view is the one that matters.
How long do Core Web Vitals take to improve in Search Console?
Because field data uses a rolling 28-day window, it takes about a month after you ship a fix for it to fully reflect in Search Console, and Google then recrawls and re-evaluates. Use PageSpeed Insights lab data to confirm the fix worked immediately, then watch the Search Console report move over the following weeks.
Want your Core Web Vitals fixed for you?
Diagnosing Vitals is free with the tools above; fixing them well is where it gets fiddly — especially INP, which means getting into your JavaScript. If you'd rather not, our technical SEO audit service finds exactly which metric is failing on which templates and hands you a prioritised fix plan, and a full SEO audit puts Vitals in context with the rest of what's holding the site back. You can also run our free live audit to see your technical issues surfaced in real time.
Failing Core Web Vitals?
Send me your URL and I'll tell you which metric is failing and the first three things I'd change to fix it — in priority order, no pitch.
Get a free check →
Founder of SEORevive. Fixes the technical foundations — Core Web Vitals, indexation, schema — that quietly cap rankings, then rebuilds the content and authority on top. Technical SEO, recovery and search-visibility for businesses across India and internationally.