Core Web Vitals

Lab scores lie. Field data from real Chrome users is what ranks you — and it's the only Core Web Vitals number that matters when Google decides whether your page is a good experience.

What are Core Web Vitals?

Core Web Vitals are the three specific metrics Google uses to quantify page experience for the purposes of Search ranking. Introduced in 2020 and turned into a confirmed ranking signal in June 2021, they replaced years of vaguer "site speed" signals with three measurable, threshold-based numbers.

Two important properties define them:

• Real-user, not simulated. Google's ranking system uses field data from the Chrome User Experience Report — measurements from actual Chrome users on your site. Lighthouse scores are diagnostic, not ranking inputs.
• Threshold-based, at the 75th percentile. A page "passes" a metric only when 75% of user visits meet the good threshold. The median (p50) is not enough.

Why Core Web Vitals matter

Beyond ranking, poor Core Web Vitals cost revenue directly. Five reasons every SEO and dev team tracks them:

1. 24% fewer abandonments. Google's own case studies show pages meeting all three thresholds retain significantly more users to first interaction.
2. Up to 15% more ad revenue. Publishers who fixed CWV reported meaningful lifts in monetization — a slow page earns less inventory per session.
3. Direct Search ranking signal. Confirmed as a tiebreaker among otherwise-comparable results.
4. Mobile amplification. Google indexes mobile-first. Mobile CWV are typically worse than desktop and matter more.
5. Compound effect with conversion. Every 100ms saved on LCP shows a measurable lift in conversion rate across ecommerce benchmarks.

How Core Web Vitals work

Chrome collects performance data from real users (with telemetry consent) and aggregates it into CrUX. That data is joined to your URLs at the origin and page-URL levels. Search Console displays your page URLs bucketed as Good, Needs Improvement, or Poor per metric.

Field data vs lab data

Two data classes measure the same metrics but differ sharply:

• Field data (RUM): real Chrome users, aggregated over 28 days. Used for ranking.
• Lab data: simulated runs from Lighthouse. Useful for reproducing issues, not for ranking.

URL-level vs origin-level

CrUX reports both individual URL data (when there's enough traffic) and origin-wide aggregates. Low-traffic pages inherit the origin's data until they accumulate enough samples.

The three Core Web Vitals

Largest Contentful Paint (LCP)

LCP times the render of the largest above-the-fold element — usually the hero image, hero video, or a large H1 block. Slow LCP typically means an unoptimized hero image, render-blocking JavaScript, or a slow server response.

Interaction to Next Paint (INP)

INP tracks the delay between a user's click, tap, or keypress and the next visual update. Slow INP typically means heavy JavaScript execution on the main thread — long tasks that block rendering.

Cumulative Layout Shift (CLS)

CLS counts unexpected content shifts during page load. Common causes: images without width/height, late-loading ads that push content down, web fonts that swap font-face and reflow text.

Real Core Web Vitals fixes

1. LCP 4.8s → 1.9s via image + font optimization

A DTC ecommerce hero image was a 1.2MB PNG. Swapping to WebP, adding proper srcset, and preloading the file cut LCP from 4.8s to 1.9s. Add-to-cart rate rose 8% in the same month.

2. INP 620ms → 140ms via JS deferral

A publishing site loaded 14 third-party scripts synchronously on page load. Deferring non-critical scripts and consolidating three analytics tags into one dropped INP from 620ms to 140ms. Pageviews per session rose 12%.

3. CLS 0.42 → 0.02 via reserved ad slots

A media site's mid-article ads inserted after load, pushing paragraphs down. Reserving fixed-height CSS containers for each ad slot dropped CLS from 0.42 to 0.02 in two days.

Field data vs lab data — which one ranks you?

7 best practices for Core Web Vitals

1. Compress and modernize images. WebP or AVIF, correctly sized via srcset, with width/height attributes on every img.
2. Preload the LCP element. A single preload hint on the hero image or font cuts LCP by hundreds of milliseconds.
3. Defer non-critical JavaScript. Analytics, chat widgets, and A/B testing scripts should load after first interaction.
4. Reserve space for dynamic content. Ads, embeds, and images all need explicit dimensions to prevent layout shift.
5. Ship on a CDN. Static assets over a global CDN reduce LCP by 200-800ms depending on audience geography.
6. Measure field data, not lab. Watch Search Console monthly. Lighthouse is for reproducing specific issues.
7. Optimize for the 75th percentile, not the average. A "passing" median hides a failing tail.

Common Core Web Vitals mistakes to avoid

• Uncompressed hero images. The #1 cause of slow LCP in 2026.
• Heavy synchronous JavaScript. Every long task delays INP.
• Missing image dimensions. Every img without width/height contributes to CLS.
• Optimizing only for desktop. Mobile carries the ranking weight.
• Ignoring the 75th percentile. Averages hide the slow tail that fails you.

How theStacc helps

Our audit surfaces every URL that fails LCP, INP, or CLS at the 75th percentile — segmented by page type, device, and traffic source. We rank the fixes by the traffic they'd protect and hand the dev team a ready-to-ship engineering ticket. It's the same workflow behind our technical SEO engagements — measure the field data, fix the biggest lever, re-measure at 28 days.

Frequently asked questions

Related glossary terms

Sources

Akshay VR

Marketing Head · theStacc · Ex-Sr Marketing Specialist, ARKA 360

Akshay leads the editorial and content-ops function at theStacc. He writes about SEO craft, content operations, and the small decisions that compound into big ranking wins — from what to redirect to what to leave alone.

LinkedIn Author page More terms by Akshay