Core Web Vitals get talked about as an SEO checkbox, which undersells them. They are Google's attempt to measure something real: whether a page loads fast, responds when you touch it, and stays visually stable while you use it. Fixing them improves rankings, but it improves conversion rates for the exact same reason.
— Guide
Core Web Vitals, explained without the jargon.
Three metrics Google uses to judge how a page actually feels to use — and why fixing them pays off beyond the ranking bump.
The three metrics
Largest Contentful Paint (LCP) measures how long the biggest visible element — usually a hero image or heading — takes to render; under 2.5 seconds is good. Interaction to Next Paint (INP) measures how responsive the page feels when a visitor clicks, taps or types; under 200ms is good. Cumulative Layout Shift (CLS) measures how much content jumps around as the page loads; under 0.1 is good.
Two details matter more than the numbers themselves. Google grades you at the 75th percentile of real visits, so a page is only "good" when three quarters of actual sessions clear the threshold — your own fast connection is not the measurement. And INP replaced First Input Delay in March 2024, which is why older audits and blog posts still quoting FID are measuring something Google no longer uses.
Why they affect rankings and conversions
Google uses page experience as one ranking signal among many, so Core Web Vitals alone will not rescue a page with no relevant content. But the same issues that hurt these scores — slow loading, sluggish interactions, jumpy layouts — are exactly the things that make a real visitor leave before converting. The ranking effect and the conversion effect share a root cause.
Where sites usually lose points
Unoptimised hero images and background videos are the most common LCP killer. Render-blocking JavaScript and heavy third-party scripts — chat widgets, ad tags, marketing pixels — tend to wreck INP. CLS is usually caused by ads, web fonts, or embeds (reviews widgets, maps) that load late and shove content down after the visitor has already started reading.
Fixing it without a rebuild
Most of this is fixable incrementally: compress and lazy-load images below the fold, defer non-critical third-party scripts until after first interaction, reserve layout space for anything that loads asynchronously, and serve static assets through a CDN with proper caching headers. A full rebuild is rarely the first move — a targeted performance pass usually is.
For scale on how common the problem is: across the HTTP Archive’s 2025 platform data, only 45% of mobile WordPress sites passed all three metrics, against 85% for Duda and 74% for Wix. A failing score is the normal state of the web, not an unusual defect — which is exactly why fixing it is still a competitive advantage.
When the lab score and the field data disagree
Two tools can hand you two different verdicts on the same page and both can be right. Lighthouse is a lab run: one load, one simulated device, one connection, one place. The field data at the top of PageSpeed Insights is what actually happened to real visitors on whatever hardware, network and patience they arrived with.
When the two disagree, Google’s own guidance is unambiguous — field data is what you prioritise, because it is what your users actually experienced. The practical consequence is that a perfect lab score on a fast laptop can sit happily above a failing field score, and it is the field score that follows you into Search Console. Lab data still earns its place for debugging: it is reproducible and it tells you *why* something is slow. Field data tells you *whether it matters*. Use the lab to find the cause, the field to decide if it was worth fixing.
Sources
Metric definitions, thresholds, pass rates and the lab-versus-field guidance come from these, checked August 2026.
- web.dev — Web Vitals ↗
The canonical definition of the Core Web Vitals set, the good/needs-improvement/poor thresholds, and the 75th-percentile rule Google grades against.
- web.dev — Interaction to Next Paint (INP) ↗
How INP is measured across a whole visit rather than the single first input, and its replacement of First Input Delay as a Core Web Vital in March 2024.
- Google Search Central — Understanding page experience in Google Search results ↗
Google’s own statement that page experience is one signal among many, and that relevant content still outranks a faster page with less of it.
- HTTP Archive — Web Almanac 2025, CMS chapter ↗
Real-user mobile pass rates by platform: Duda 85%, TYPO3 79%, Wix 74%, Weebly 47%, WordPress 45%.
- web.dev — When lab and field data are different (and what to do about it) ↗
Field data reflects real network, device and behaviour variety; lab data deliberately limits the variables. Where both exist, field data is what should drive prioritisation.
— FAQ
Frequently asked questions
Curious where your site actually stands?
We run fixed-price technical audits that flag exactly what is capping your Core Web Vitals scores.