Core Web Vitals in 2026: what they are and how to pass Google's exam

Google is grading your site. Most websites fail.

Since 2021, Google uses three concrete technical metrics to decide whether your site offers a decent experience. They're called Core Web Vitals and they're one of the most underrated ranking factors out there: if you're in the red, no matter how much content or SEO you have — Google will push your site down.

According to the latest HTTP Archive report, fewer than 40% of mobile sites pass all three Core Web Vitals. That means 6 out of 10 websites are technically penalised without knowing it.

6 in 10

mobile sites fail Core Web Vitals. If you pass, you already beat 60% of your competition on technical signals

In this guide we explain what the three metrics are, what values you need to hit, what typical mistakes break them, and how to fix them.

What Core Web Vitals are

Three metrics measuring three different dimensions of user experience:

Metric	What it measures	Target
LCP (Largest Contentful Paint)	Visible load speed	< 2.5s
INP (Interaction to Next Paint)	Responsiveness	< 200ms
CLS (Cumulative Layout Shift)	Visual stability	< 0.1

Google evaluates these at the 75th percentile of your real users. So it's not enough that they're fast on your Mac with fibre — they need to be fast on 75% of your real users' phones, including modest Androids on 4G.

LCP — Largest Contentful Paint

Measures the time from arriving at the page until the largest visible element is rendered (usually the hero image or main text block). It's the metric that best reflects "feels fast vs feels slow".

Good: < 2.5 seconds
Needs improvement: 2.5 - 4 seconds
Poor: > 4 seconds

INP — Interaction to Next Paint

Replaced FID in March 2024. Measures how long the site takes to visually respond when the user clicks, taps or types. If INP is high, the site "feels frozen" — the user clicks and nothing happens for half a second.

Good: < 200 ms
Needs improvement: 200 - 500 ms
Poor: > 500 ms

CLS — Cumulative Layout Shift

Measures how much content shifts unexpectedly while loading. If you've ever tried to click a button and it suddenly moved because a banner loaded above, you experienced high CLS. Google rightly penalises it.

Good: < 0.1
Needs improvement: 0.1 - 0.25
Poor: > 0.25

Why Core Web Vitals matter so much

Three reasons, in order of impact:

Confirmed ranking factor by Google. Not the strongest factor, but in competitive sectors where everyone has good content, moving Core Web Vitals can lift you 2-5 positions.
Conversion. Every extra 100ms of LCP cuts conversion by 1-2% according to Google. A site with 4s LCP converts 15-30% less than one with 1.5s LCP. We develop this in why website speed is costing you customers.
Bounce rate. A site with high CLS frustrates the user. A site with high LCP loses the user before it even loads.

Typical causes of red Core Web Vitals

Why LCP is high

Heavy hero images. An 800KB JPEG when it should be 80KB in WebP.
Slow hosting. TTFB (Time To First Byte) above 800ms. Switching hosts is the fastest fix.
Render-blocking resources. CSS or JavaScript that stops rendering until loaded.
Badly configured web fonts. The browser waits for the font before painting text.
Too many third-party scripts. Every tracker is 200-500ms.

Why INP is high

Huge JavaScript bundle. 1MB of compressed JS is overkill for an SMB site.
Heavy event handlers. Doing synchronous work in click handlers.
Poorly configured frameworks. WordPress + 30 plugins is the classic case.

Why CLS is high

Images without dimensions. No width and height on <img>. The browser reserves 0px then jumps.
Late-loading banners and ads. They appear, push content.
Web fonts that change text size on load.
Badly animated cookie popups and banners.

How to fix Core Web Vitals — actionable checklist

Quick wins (high impact, low effort)

1. Compress and convert images. Move every image to WebP or AVIF. An 800KB image becomes 80KB with identical visual quality. This alone moves LCP by hundreds of ms.

2. Set width and height on every <img> and <video>. The browser reserves space, no jumps. CLS drops immediately.

3. Use loading="lazy" on images below the fold. The browser doesn't load them until the user scrolls near.

4. Preconnect to critical external domains. <link rel="preconnect" href="https://fonts.googleapis.com"> saves 100-300ms per handshake.

5. Set font-display: swap on your web fonts. The browser shows text with the system font while yours loads.

Medium optimisations (high impact, medium effort)

Minify and compress CSS and JS. Every modern framework does it automatically. If yours doesn't, the stack is old.
Code splitting. Load only the JavaScript each page needs, not the whole bundle on every view.
Image CDN. Cloudinary, Cloudflare Images, Vercel Image — automatically convert and serve the optimal format to each browser.
Decent hosting. Vercel, Cloudflare Pages, Netlify, AWS are cheap and lightning fast. Move out of £3/month shared hosting.

Technical optimisations (high impact, high effort)

Modern stack (Next.js, Astro, SvelteKit). Static or hybrid rendering = sub-1s LCP achievable.
Drop plugins. If on WordPress, audit each plugin: every one adds JS to the bundle.
Reduce total JavaScript weight. Sensible target: < 300KB compressed.

How to measure Core Web Vitals correctly

Three types of measurement, in order of importance:

1. Real user data (CrUX) — Google Search Console

The source Google uses for ranking. Anonymised real Chrome user data from the last 28 days.

Go to Search Console → "Experience" → "Core Web Vitals"
You'll see "URLs with mobile/desktop issues"
Click on each error → it shows which URLs and which metric is bad

Important: Search Console only shows data if your site has enough traffic. No traffic, no real data.

2. PageSpeed Insights

pagespeed.web.dev. Shows two things:

CrUX data — real data from the last 28 days (if any)
Lab data — simulation of a 4G mobile device. Useful when there's no CrUX yet.

3. Lighthouse in Chrome DevTools

For detailed technical diagnosis. Tells you which specific optimisation to apply.

The gap between "good Core Web Vitals in Lighthouse" and "good Core Web Vitals according to Google" can be huge. Only CrUX (real data) counts. Lighthouse is a useful thermometer, not the final grade.

Real case: SMB goes from red to green and climbs 4 positions

A consultancy had a WordPress site with LCP of 4.8s, INP of 350ms and CLS of 0.28. Everything red.

We did 3 things in 6 hours:

Moved from shared hosting to Vercel (LCP dropped 1.2s on this alone)
Converted images to WebP + explicit dimensions (CLS from 0.28 to 0.05)
Disabled 7 unnecessary WordPress plugins + deferred chat loader (INP from 350ms to 140ms)

Result: all three metrics green. Climbed from position 9 to 5 for the main keyword in 6 weeks. Zero content changes. Pure technical.

If your stack is stuck on WordPress, this is why WordPress and Wix are holding your business back. Modern stacks deliver green Core Web Vitals out of the box.

Your next step

Running a quick audit is free and takes 5 minutes:

Open pagespeed.web.dev and enter your URL
Look at the "Origin data" block (CrUX) on mobile
Note: which metrics are red or amber?

If they're red, your site is losing positions and conversions every day. We do a free technical audit in 24 hours with the exact plan to move to green, prioritised by impact.

If you're building a new site, Core Web Vitals are covered from day 1 in our stack — see how AI web development works and our SEO web design service.