What Are Core Web Vitals? (And Why They Actually Matter)

Core Web Vitals are Google's set of real-world metrics that measure user experience on your site. Since 2022, they've been direct ranking factors. In 2026, they're still critical — both for SEO and for keeping people from bouncing off your page in frustration.

What I tell every client: Google doesn't care how pretty your site is. They care how fast it loads, how stable it feels, and how quickly it responds when someone taps a button. Those three things are what Core Web Vitals measure.

The three metrics you need to worry about are:

LCP (Largest Contentful Paint) — Loading performance (how fast your main content appears)
INP (Interaction to Next Paint) — Interactivity (how snappy your page feels)
CLS (Cumulative Layout Shift) — Visual stability (how much stuff jumps around while loading)

There are also FCP and TTFB, which are important supporting metrics, but LCP, INP, and CLS are the big three Google actually uses for ranking. I've spent the last two years fixing these metrics for clients, and I'm going to walk you through exactly what works — not theory, but the stuff that actually moved the needle.

Fixing LCP (Target: Under 2.5s)

LCP measures how long the largest visible element takes to render. For most sites, that's your hero image or a big heading block. Google wants it under 2.5 seconds. Anything over that and you're losing both rankings and users. For a complete breakdown of diagnosing and fixing LCP specifically, see our LCP deep dive guide.

I spent three weeks fixing LCP on a client's WooCommerce store last year. Their product pages were loading at 6.8 seconds on mobile. We got it down to 2.1 seconds. Here's exactly how.

1. Optimize Images (This Is Where Most of the Wins Are)

Images are the number one LCP killer. Period. I've never seen a site with a bad LCP score that didn't have an image problem.

Convert to WebP or AVIF format. WebP gives you 40-80% smaller files than JPEG with basically the same quality. AVIF is even better but browser support is still catching up.
Use responsive images with srcset so mobile users aren't downloading 4000px hero images on a 375px screen. That's just wasteful.
Lazy-load below-the-fold images. Don't load that footer image until someone actually scrolls down to it.
Serve appropriately sized images for the viewport. A 1200px-wide image is fine for desktop. For mobile, 400px is plenty.

What I actually changed: On that WooCommerce store, we were serving the same 2400px product images to every device. We used `html Product name ` and converted everything to WebP. That alone cut LCP by 2.3 seconds.

2. Eliminate Render-Blocking Resources

Your is probably loading CSS and JavaScript that blocks rendering. Every render-blocking resource adds milliseconds to your LCP.

Defer non-critical CSS and JavaScript. If it's not needed for above-the-fold content, defer it.
Inline critical CSS in the for above-the-fold styles. This eliminates a render-blocking request entirely.
Use rel="preload" for your hero image and critical fonts. Tell the browser to start downloading these immediately instead of waiting.

What I actually changed: I found three CSS files loading in the that were render-blocking. Two of them were for a slider that only appeared on the homepage. We moved them to and inlined the critical above-the-fold CSS. LCP dropped another 0.8 seconds.

3. Improve Server Response Time

If your server is slow, everything else you do is fighting an uphill battle.

Use a CDN (Cloudflare, Vercel Edge, Fastly). There's no excuse not to in 2026.
Enable HTTP/2 or HTTP/3. Multiple requests can be multiplexed over a single connection.
Optimize database queries on the backend. From my experience, WooCommerce sites where a single page triggered 200+ database queries.
Implement caching strategies. Page caching, object caching, browser caching — use all of them.

What I actually changed: That same WooCommerce client was on $5/month shared hosting. Their TTFB alone was 1.8 seconds. We moved them to a managed WooCommerce host with server-level caching and a Cloudflare CDN. TTFB dropped to 180ms. That was the single biggest LCP improvement we made.

4. Optimize Web Fonts

Custom fonts are beautiful but they can absolutely wreck your LCP if you're not careful.

Use font-display: swap so text is visible immediately using a fallback font, then swaps in the custom font once it loads.
Subset fonts to include only the characters you need. Most sites don't need Cyrillic, Greek, and Vietnamese character sets.
Preload critical fonts with so the browser fetches them early.

What I actually changed: The client was loading three different weights of a font family (400, 600, 700) plus two different font families. We subset each to Latin characters only and dropped the light weight. Font file sizes went from 380KB total to 85KB.

The Final LCP Result

After all these changes, we got their LCP from 6.8 seconds to 2.1 seconds on mobile. That's a 70% improvement. Organic traffic to product pages increased 34% over the next two months. Not a coincidence.

Fixing INP (Target: Under 200ms)

INP (Interaction to Next Paint) replaced First Input Delay (FID) in 2024, and honestly, it's a much harder metric to nail. FID only measured the delay before the first interaction. INP measures how quickly your page responds to *every* interaction throughout the session. If you have one slow handler buried in your code, INP catches it.

What nobody tells you about INP: most sites fail because of JavaScript they didn't write themselves. Third-party scripts, analytics tools, chat widgets — they're the silent INP killers.

1. Break Up Long Tasks

The browser's main thread can only do one thing at a time. If a JavaScript task takes longer than 50ms, it blocks everything — scrolling, clicking, rendering. Users feel it as jank.

Split JavaScript execution into chunks under 50ms using requestIdleCallback or setTimeout.
Use requestIdleCallback for non-urgent work like analytics, prefetching, or non-critical UI updates.
Implement code splitting and lazy loading so users only download what they need for the current page.

What I actually changed: I found a product page that was running a 340ms JavaScript task on page load — a complex price calculator that computed tax for 12 different regions. Nobody was interacting with it on load. We wrapped it in requestIdleCallback and deferred it until the browser was idle. INP dropped from 420ms to 85ms.

2. Optimize Event Handlers

Every click, tap, scroll, and keypress triggers an event handler. If that handler does too much work, your page feels sluggish.

Debounce scroll and resize handlers. Running complex logic on every scroll event is almost always unnecessary.
Avoid complex DOM manipulations in event callbacks. Batch your DOM reads and writes.
Use passive event listeners where possible (`htmladdEventListener('scroll', handler, { passive: true })`). This lets the browser scroll while your handler runs.

What I actually changed: A client had a sticky header that recalculated its position on every single scroll event — no debounce, no throttle. That's hundreds of times per second. Adding a simple debounce with a 16ms delay fixed it immediately. INP went from 380ms to 120ms.

3. Reduce Main Thread Work

The less JavaScript you force the browser to execute, the faster it can respond to interactions.

Minimize JavaScript bundle size. Use tree-shaking, remove unused exports, and analyze your bundle with tools like webpack-bundle-analyzer.
Remove unused polyfills and legacy code. If you're not supporting IE11, stop shipping polyfills for it.
Use Web Workers for heavy computations like data processing, image manipulation, or complex calculations.

What I actually changed: After checking a SaaS landing page and found 400KB of JavaScript that was never executed. It was a legacy A/B testing library that had been replaced but never removed. Deleting it dropped the bundle by 40% and INP improved from 290ms to 110ms.

The Final INP Result

Most of my clients land between 80-150ms INP after optimization. Under 200ms is passing, but I aim for under 150ms to give a safety margin. Remember, INP is measured at the 98th percentile — your worst interactions matter more than your average ones.

Fixing CLS (Target: Under 0.1)

CLS measures visual stability — how much your page layout shifts after it starts loading. Think about that moment when you're about to click a link and an ad loads above it, pushing everything down. That's CLS, and users absolutely hate it.

The biggest CLS issue I ever saw was caused by a news site with 14 different ad units loading asynchronously. The page would shift three or four times before settling. Their CLS score was 0.45. We got it to 0.03.

1. Set Explicit Dimensions

If you don't tell the browser how big an element will be, it has to guess. And when the real content loads, everything shifts.

Always set width and height on images and videos. Even if you're using CSS to make them responsive, the browser needs the intrinsic dimensions to calculate aspect ratio.
Use the aspect-ratio CSS property for responsive elements: `htmlaspect-ratio: 16 / 9;`
Reserve space for ads and embeds. I use a placeholder div with the expected dimensions that the ad fills when it loads.

What I actually changed: A client's blog was embedding YouTube videos with just the iframe — no dimensions specified. We wrapped each iframe in a container with aspect-ratio: 16 / 9; width: 100%; and set explicit width and height attributes on the iframe. CLS dropped from 0.28 to 0.05.

2. Avoid Late-Loading Content

Anything that appears after the initial page load and pushes content around contributes to CLS.

Don't inject content above existing content after load. If you must, pre-allocate space for it.
Pre-allocate space for dynamic elements like banners, cookie notices, and chat widgets.
Use skeleton screens with fixed dimensions so the layout doesn't shift when real content loads.

What I actually changed: That news site I mentioned had a breaking news banner that appeared 2-3 seconds after page load. It pushed the entire article down 120px. We gave the banner position with a CSS placeholder: `html

` — the space was always there, it just stayed empty until the banner loaded.

3. Use Font Display Swap (Strategically)

Custom fonts can cause layout shifts when they load — the fallback font might be a different size, causing text to reflow.

Use font-display: swap for body text. The text appears immediately in a fallback font, then swaps to the custom font.
Use font-display: optional for non-critical fonts. This eliminates the layout shift entirely — the browser either uses the custom font or sticks with the fallback, no swap.
Match your fallback font metrics. Use tools like fontaine to find system fonts that closely match your web fonts.

What I actually changed: A client had three custom fonts causing a 0.12 CLS from text reflow alone. We used font-display: optional for the heading font (it was only used in large sizes where the difference was barely noticeable) and matched the fallback font metrics using CSS size-adjust. CLS from font loading dropped to zero.

The Final CLS Result

Most CLS issues come from ads, images, and dynamically injected content. Fix those three categories and you'll typically land under 0.1. I've gotten every client I've worked with to pass CLS — it's usually the easiest of the three metrics to fix once you know what to look for.

What I Actually Changed (Summary)

The reality is — I just gave you a lot of technical advice. Let me boil it down to what actually makes a real difference, in order of impact:

1. Images — Convert to WebP, set explicit dimensions, use srcset, lazy-load below-fold. This fixes LCP and CLS simultaneously.

2. JavaScript — Remove unused code, defer non-critical scripts, break up long tasks. This fixes INP.

3. Server — Use a CDN, enable caching, upgrade hosting if needed. This fixes LCP and FCP.

4. Fonts — Subset, preload, and use font-display strategically. This fixes LCP and CLS.

5. Layout stability — Set dimensions on everything, reserve space for dynamic content. This fixes CLS.

If you only do one thing, fix your images. It's the highest-impact change for the least effort. From my experience image optimization alone improve LCP by 2+ seconds on image-heavy sites.

Tools to Measure Core Web Vitals

You can't fix what you can't measure. Here are the tools I use daily:

Google PageSpeed Insights — Lab and field data. Free, reliable, and what Google actually uses.
Chrome User Experience Report (CrUX) — Real-user metrics from actual Chrome users. This is the gold standard for field data.
Search Console Core Web Vitals report — Shows URL-level issues across your entire site. Great for finding pages that need attention.
AI SEO Copilot — Automated CWV analysis with specific fix recommendations. It doesn't just tell you what's broken — it tells you exactly what to change.
Chrome DevTools Performance panel — For deep-diving into specific interactions and identifying long tasks.

My advice? Start with PageSpeed Insights for a quick overview, then use Search Console to find the worst offenders across your site. Once you've identified problem pages, use the DevTools Performance panel to pinpoint exactly what's causing the issue. For WordPress sites specifically, our guide on Core Web Vitals optimization for WordPress covers plugin-by-plugin fixes.

Test Your Core Web Vitals Now

Stop guessing and start measuring. Run a free Core Web Vitals analysis on any URL. You'll get a traffic-light score for all five metrics plus specific optimization steps ranked by impact. No signup required — just paste your URL and see exactly where you stand.

How to Fix Core Web Vitals Issues: LCP, INP, CLS Explained