Performance · Explainer

Core Web Vitals explained

Core Web Vitals - LCP, CLS and INP - are Google's measure of real-user page experience: loading, stability and responsiveness. They're a ranking signal and a conversion lever at once. Here's Core Web Vitals explained: what each one means and exactly how to improve it.

Test my Core Web Vitals freePageSpeed Test

What Core Web Vitals measure

Three metrics that approximate how a page actually feels to a real user: does it load fast, stay stable, and respond quickly?

Google uses page experience as a ranking signal, and Core Web Vitals are its measurable core. They're assessed on real-user data, predominantly mobile. The goal isn't a perfect lab score, it's passing the "good" threshold for each metric for most of your visitors. The three vitals each capture a different part of the experience, and each has its own causes and fixes, covered below.

The three vitals, decoded

What each measures, the good threshold, and the fixes that move it.

LCP: Largest Contentful Paint (loading)

Measures how long until the largest content element (usually the hero image or main heading) renders. Good: 2.5s or less. Fixes: compress, size and preload the hero image; serve modern image formats; cut server response time (TTFB) with caching and a CDN; remove render-blocking CSS/JS. The LCP element is most often an image, so image optimisation is usually the biggest win.

CLS: Cumulative Layout Shift (stability)

Measures how much the page unexpectedly jumps around as it loads. Good: 0.1 or less. Fixes: set explicit width and height (or aspect-ratio) on images, videos and embeds so space is reserved; reserve space for ads and dynamic content; use font-display: swap carefully and preload fonts to avoid text reflow. CLS is what makes you tap the wrong button because the layout shifted: eliminating it is mostly about reserving space up front.

INP: Interaction to Next Paint (responsiveness)

Measures how quickly the page visually responds to user interactions (taps, clicks, key presses) across the whole visit. Good: 200ms or less. Fixes: break up long JavaScript tasks, defer non-critical scripts, minimise main-thread work, and avoid heavy work in event handlers. INP officially replaced First Input Delay as the third Core Web Vital in March 2024; it's a stricter, whole-session measure of responsiveness rather than a single first-click delay.

LCP
Good ≤ 2.5s · Poor > 4s
Needs improvement: 2.5s–4s
CLS
Good ≤ 0.1 · Poor > 0.25
Needs improvement: 0.1–0.25
INP
Good ≤ 200ms · Poor > 500ms
Needs improvement: 200ms–500ms

Beyond the three vitals

The audit also catches the unglamorous performance drains that feed into them.

Non-minified JavaScript and CSS · uncompressed (no gzip/brotli) assets · oversized pages · render-blocking resources · unoptimised images (the most common LCP killer) · missing viewport meta (breaks mobile rendering) · reliance on plugins. These don't appear in the three vital scores directly, but they're the underlying causes of poor LCP and INP, and they're concrete, fixable engineering tasks. Always validate fixes on mobile, where vitals are hardest to pass and where most of your users actually are.

Interpreting your scores

How much do Core Web Vitals affect rankings?

Core Web Vitals are a real but modest ranking signal, most influential as a tiebreaker between pages of similar relevance and quality. Content relevance still dominates: a fast page about the wrong thing will not outrank a slower page that answers the query.

The stronger reason to fix them is user behaviour. Faster, more stable pages keep more of your existing visitors and convert better, so the payoff is both a small ranking lift and a real engagement gain. That makes vitals work worth doing on its own merits, independent of how the ranking signal is weighted in any given year.

Lab data against field data

Lab data, such as a PageSpeed test run, is a controlled, repeatable simulation. Because conditions are held constant, it is the right tool for debugging: you can change one thing, re-run, and attribute the difference.

Field data is real-user measurement collected over time, and it is what Google uses for the page experience signal. The two serve different jobs and you need both: use lab tests to diagnose and fix, then watch field data to confirm the improvement actually reached real users on real devices.

Why a perfect score is the wrong target

You do not need a perfect 100. The target is passing the "good" threshold for each vital for most users, not a perfect lab score.

Chasing the last few points often has diminishing returns, and a high lab score does not guarantee good field results anyway. Getting LCP, CLS and INP into the green on mobile is what matters, and once you are there the next hour of engineering is almost always better spent on something else.

Core Web Vitals questions, answered

What is a good Core Web Vitals score?

Good is LCP at 2.5s or less, CLS at 0.1 or less, and INP at 200ms or less, all measured at the 75th percentile of real visits on mobile. Between good and poor is "needs improvement": LCP 2.5s-4s, CLS 0.1-0.25, INP 200ms-500ms. Beyond those upper bounds a metric is "poor". You need all three in the good band to pass the assessment, not just an average across them.

Did INP really replace FID?

Yes, officially, in March 2024. FID only timed the delay before the browser started processing the very first user interaction. INP times the full visual response, input delay plus processing plus rendering, across every interaction in the session, and reports the slowest representative one. A site that comfortably passed FID can fail INP if any interaction later in the page triggers heavy JavaScript.

Why does my lab test look better than my real Core Web Vitals status?

A PageSpeed Insights run is lab data, one simulated pass under fixed conditions. The Core Web Vitals status that matters for search is field data: real visits over the trailing 28 days from Chrome. If most real visitors use slower phones or networks than the lab simulation, the field numbers will be worse than the lab report.

Should I test Core Web Vitals on desktop or mobile?

Mobile. Google's assessment is mobile-first, most traffic is mobile, and mobile CPUs and connections are slower, so a page that passes comfortably on a desktop test can still fail on the device most of your visitors actually use. Always read and act on the mobile numbers.

How fast does a fix show up in the data?

Field data rolls over a 28-day window, so a shipped fix takes close to a month to fully replace the older, slower visits it's averaged against. Use a lab tool to confirm the fix worked immediately, then expect the field report to catch up gradually rather than jump right away.

What's the single biggest lever for a bad LCP score?

Almost always the hero image, and what delays it from painting: a slow server response, render-blocking CSS or JS ahead of it in the head, or the image itself being unoptimised and un-preloaded. See render-blocking resources for how the head of the document caps how early LCP can happen, and asset delivery for the server-side settings that speed up everything in the critical path.

See your Core Web Vitals and what's hurting them

Free to start. Test your key pages and find the assets and templates slowing them down.

Start my free audit