Core Web Vitals, explained properly.
Core Web Vitals sound like something only developers need to worry about. In fact they're Google's attempt to measure something every business cares about: whether your website actually feels good to use. Here's what they mean, in plain English, and what to do about them.
Core Web Vitals are three metrics Google uses to measure real-world page experience and factor into rankings. Largest Contentful Paint (LCP) measures how quickly the main content appears — good is 2.5 seconds or less. Interaction to Next Paint (INP) measures how fast the page responds when you tap or click — good is 200 milliseconds or less. Cumulative Layout Shift (CLS) measures how much the layout unexpectedly jumps around — good is 0.1 or less. Google judges these on real visitor data, and a page passes only if 75% of visits meet the 'good' threshold for all three. You can check yours free in PageSpeed Insights or Search Console.
What this guide covers
What Core Web Vitals are and why Google created them
Google's whole business depends on sending people to pages they'll find useful. A page can be relevant and still be miserable to use — slow to appear, unresponsive to taps, jumping around as you try to read it. Core Web Vitals are Google's way of measuring that misery objectively, so it can prefer pages that don't inflict it.
Two things make them matter commercially. First, they're a confirmed ranking factor — part of Google's page experience signals. Second, and more importantly, they measure the same things that make visitors leave or convert, so improving them helps your business even where it doesn't move rankings. They're judged on real visitor data (called field data) gathered from actual Chrome users, not just a lab test — which is why two people can get different scores for the same page.
LCP — Largest Contentful Paint
What it measures: how long until the largest piece of content in the visible area — usually the main image or headline — has loaded. It's the moment the page stops looking empty and starts looking useful.
Thresholds: good is 2.5 seconds or less; 2.5–4 seconds needs improvement; over 4 seconds is poor.
Common causes when it's poor: a slow server response (the page can't start until the server replies), an oversized hero image, render-blocking CSS or JavaScript delaying the paint, or slow-loading web fonts. The fixes map directly onto general speed optimisation: faster hosting, compressed and correctly-sized images, deferring non-critical resources, and preloading the important ones.
INP — Interaction to Next Paint
What it measures: how quickly the page visually responds after you interact — tap a button, open a menu, select a field. It captures responsiveness across the whole visit, and in 2024 it replaced the older First Input Delay metric, which only measured the first interaction. INP is stricter and more representative.
Thresholds: good is 200 milliseconds or less; 200–500ms needs improvement; over 500ms is poor.
Common causes when it's poor: heavy JavaScript hogging the browser's main thread, so when you tap something the browser is too busy to respond. This is the metric most affected by plugin-heavy and page-builder sites, because they tend to run a lot of script. The fix is reducing and optimising JavaScript — removing what isn't needed, breaking up long tasks, and being wary of features that pull in large libraries.
Why INP catches people out: a page can score well on loading (LCP) but badly on INP, because it looks ready before it actually is. The content has painted, but the JavaScript is still busy, so the first tap hangs. Fast-looking and actually-responsive are different things.
CLS — Cumulative Layout Shift
What it measures: how much the page layout moves around unexpectedly as it loads. You've felt bad CLS: you go to tap a link, an image loads above it, everything jumps, and you tap the wrong thing. It's measured as a score rather than a time.
Thresholds: good is 0.1 or less; 0.1–0.25 needs improvement; over 0.25 is poor.
Common causes when it's poor: images and embeds without width and height set (so the browser doesn't reserve space and content jumps when they load), ads or banners injected after load, and web fonts that swap in and change text size. The fixes are mostly discipline: always specify dimensions for images and media, reserve space for anything that loads late, and handle fonts so they don't reflow the page.
How the three fit together
| Metric | The question it answers | Good | Needs work | Poor |
|---|---|---|---|---|
| LCP | Has the main content loaded? | ≤ 2.5s | 2.5–4s | > 4s |
| INP | Does it respond when I tap? | ≤ 200ms | 200–500ms | > 500ms |
| CLS | Does it stay still while loading? | ≤ 0.1 | 0.1–0.25 | > 0.25 |
A page needs all three in the 'good' band, for at least 75% of real visits, to be considered as passing. One bad metric fails the page — which is why a site that feels "mostly fine" can still be flagged.
How to measure yours (free)
Three free tools, each with a different job:
PageSpeed Insights (pagespeed.web.dev) — enter any URL for both lab data (a controlled test) and, where available, field data (real Chrome-user measurements), plus specific recommendations. Start here.
Google Search Console — its Core Web Vitals report shows how your whole site performs on real visits, grouped by issue, so you can see patterns across page types rather than testing one URL at a time. This is the report Google itself uses.
Chrome DevTools (Lighthouse) — built into Chrome, useful for developers diagnosing a specific page while they work on it.
For a fast, jargon-free read on whether a site has obvious problems, our website checker summarises the key signals in twenty seconds.
Lab data vs field data — why your scores disagree
A common confusion: PageSpeed Insights sometimes shows a good lab score and a poor field score, or vice versa. They measure different things. Lab data is a single controlled test on Google's hardware and connection — repeatable, but not real life. Field data is aggregated from actual visitors on their real devices and connections over the previous 28 days — messier, but true. Google ranks on field data. So when they disagree, believe the field data, and treat the lab test as a diagnostic tool for reproducing and fixing issues.
Do you need perfect scores?
No — and chasing a perfect 100 is often a poor use of effort. The goal is to be in the 'good' band on all three vitals for most visitors, which is very achievable, and then to stay there. Beyond that, returns diminish quickly, and the last few points frequently come from micro-optimisations that don't change what a customer experiences.
The honest priority order for a business: first make sure you're not in the 'poor' band on any vital (that's the part that hurts rankings and visitors), then get comfortably into 'good', then stop and spend the effort on content and conversion instead. A fast site that nobody has a reason to buy from still doesn't sell. Core Web Vitals are necessary, not sufficient — they belong in the wider context of technical SEO and conversion.
Frequently asked questions
What are Core Web Vitals?
Three metrics Google uses to measure real-world page experience and factor into rankings: Largest Contentful Paint (loading), Interaction to Next Paint (responsiveness) and Cumulative Layout Shift (visual stability). A page should be in the 'good' band on all three for most visits.
What is a good LCP score?
2.5 seconds or less. Between 2.5 and 4 seconds needs improvement; over 4 seconds is poor. LCP measures how long until the largest visible piece of content — usually the main image or heading — has loaded.
What is INP and how is it different from FID?
Interaction to Next Paint measures how quickly a page responds visually when you tap or click, across the whole visit. It replaced First Input Delay in 2024. FID only measured the first interaction; INP is stricter and more representative of the real experience. Good is 200ms or less.
What causes a high CLS score?
Layout jumping as the page loads — usually caused by images or embeds without dimensions set, ads or banners injected after load, and web fonts that swap in and resize text. Reserve space for anything that loads late and always specify image dimensions.
Do Core Web Vitals affect SEO?
Yes — they're a confirmed Google ranking factor as part of page experience signals. They also affect rankings indirectly by influencing how long visitors stay and how much of your site gets crawled. That said, relevant content still matters more than a perfect score.
How do I check my Core Web Vitals?
Use PageSpeed Insights (pagespeed.web.dev) for any single URL, or Google Search Console's Core Web Vitals report for your whole site based on real visitor data. Chrome's built-in Lighthouse is useful for developers working on a specific page.
Why is my PageSpeed lab score different from the field score?
They measure different things. Lab data is one controlled test on Google's hardware; field data is aggregated from your real visitors over 28 days. Google ranks on field data, so believe that when they disagree and use the lab test to reproduce and fix issues.
What's the difference between lab data and field data?
Lab data comes from a single simulated test in a controlled environment — repeatable but artificial. Field data comes from real Chrome users on their actual devices and connections. Field data reflects the true experience and is what Google uses for ranking.
Do I need a perfect Core Web Vitals score?
No. Aim to be in the 'good' band on all three vitals for most visitors, then stop. Chasing a perfect 100 usually means micro-optimisations that don't change the customer experience — better to spend that effort on content and conversion.
Why does my site pass on desktop but fail on mobile?
Mobile devices have slower processors and connections, so JavaScript-heavy pages that feel fine on a laptop can respond sluggishly on a phone. Since Google predominantly uses mobile data for ranking, the mobile result is the one that counts.
How often are Core Web Vitals updated?
Field data in Search Console and PageSpeed Insights reflects a rolling 28-day window, so changes you make take a few weeks to show fully. Lab tests update instantly, which is why developers use them to check fixes before waiting for the field data to catch up.
Can WordPress pass Core Web Vitals?
Yes, with the right build — a lean theme, minimal plugins, optimised images, caching and good hosting. WordPress sites commonly fail INP because of heavy JavaScript from page builders and plugins, so keeping those minimal is the key.
Related: Website speed guide · Technical SEO · Development standards · Health checker
Key takeaways
- Core Web Vitals measure real page experience: LCP (loading), INP (responsiveness), CLS (stability).
- Good thresholds: LCP ≤ 2.5s, INP ≤ 200ms, CLS ≤ 0.1 — and a page needs all three, for 75% of real visits.
- INP replaced FID in 2024 and is stricter; it's the metric plugin-heavy sites most often fail.
- Google ranks on field data (real visitors), not lab tests — believe the field data when they disagree.
- Check yours free in PageSpeed Insights (per page) or Search Console (whole site).
- Aim for 'good', then stop — perfect scores rarely change what a customer experiences.
- Vitals are necessary, not sufficient: pair them with strong content and conversion work.
Failing a Core Web Vital?
Send me the page and I'll tell you exactly which vital is failing, why, and what it'll take to fix — in plain English, no jargon. The sites I build pass all three by design.