Core Web Vitals in plain English: the three numbers that matter

Core Web Vitals are Google’s attempt to put numbers on how a page feels. They are worth understanding even if you never think about search rankings, because each one maps to something visitors notice: waiting, lag and things jumping around.

The three metrics#

• Largest Contentful Paint (LCP) measures loading: how long until the biggest thing in view, usually the hero image or headline, has appeared.
• Interaction to Next Paint (INP) measures responsiveness: how quickly the page visibly reacts to taps, clicks and key presses, across the whole visit. It replaced First Input Delay as a Core Web Vital on 12 March 2024.
• Cumulative Layout Shift (CLS) measures stability: how much the content moves unexpectedly while someone is reading or about to tap.

• ✓Good
• !Needs improvement
• ✕Poor

LCP

2.5 s4 s

INP

200 ms500 ms

CLS

0.10.25

Show the data

Metric	Thresholds
LCP	Good ≤ 2.5 s · Poor > 4 s
INP	Good ≤ 200 ms · Poor > 500 ms
CLS	Good ≤ 0.1 · Poor > 0.25

Source: web.dev — Web Vitals

The 75th percentile matters. Passing does not mean your fastest visit was fast; it means three out of four visits were good. Slow phones and patchy connections count.

Lab data versus field data#

	Lab data (Lighthouse)	Field data (Chrome UX Report)
Where it comes from	One simulated load on a throttled device	Real Chrome users visiting your site
Time window	A single run	A rolling 28 days
Measures INP?	No, it uses Total Blocking Time as a proxy	Yes
Used by Google Search?	No	Yes, when there is enough traffic
Best for	Finding and debugging problems	Confirming fixes worked for real people

A green Lighthouse score with failing field data usually means real visitors have slower devices than the test, or something like a cookie banner, chat widget or personalisation runs only for them.

How the web is doing#

Good CLS81%

Good INP77%

Good LCP62%

All three good48%

Show the data

Metric	Mobile origins
Good CLS	81%
Good INP	77%
Good LCP	62%
All three good	48%

Source: HTTP Archive Web Almanac 2025

Desktop does better, at 56% passing all three. On both, LCP is the bottleneck: most sites that fail, fail on loading.

What usually fixes each one#

LCP: get the main content on screen sooner

• Serve the hero image at the size it is displayed, in WebP or AVIF, and never lazy-load it.
• Tell the browser it matters with fetchpriority="high".
• Cache full pages so the server answers in milliseconds, and put a CDN in front of the site.
• Remove render-blocking CSS and JavaScript that the first screen does not need.

<img src="/hero-1600.avif"
     srcset="/hero-800.avif 800w, /hero-1600.avif 1600w"
     sizes="100vw" width="1600" height="900"
     fetchpriority="high" alt="Our studio at work">

INP: keep the main thread free

• Audit third-party scripts. Chat, heatmaps and tag managers are the usual cause of slow interactions.
• Load non-essential widgets after the first interaction or when they scroll into view.
• Break long JavaScript tasks into smaller pieces so the browser can respond in between.

CLS: reserve space for everything

• Give every image, video and embed a width and height, or an aspect-ratio.
• Reserve space for anything injected later: banners, ads, consent prompts.
• Load web fonts with font-display: swap and a fallback font of similar proportions.

img, video { max-width: 100%; height: auto; }
.video-embed { aspect-ratio: 16 / 9; }

Check your own site in five minutes#

1. Open PageSpeed Insights and enter your address. The top section, “Discover what your real users are experiencing”, is field data. If it says there is not enough data, use the lab section instead.
2. In Google Search Console, open the Core Web Vitals report to see which groups of pages fail on mobile and desktop.
3. In Chrome DevTools, the Performance panel shows live LCP, INP and CLS while you click around.
4. After a fix, wait 28 days and check the field data again.