They're a Money Thing.

Most businesses treat Core Web Vitals as an SEO checkbox — something to fix once and forget. That framing is costing them real revenue, every single day. Here's what's actually happening.

When Google made Core Web Vitals a ranking factor in 2021, the SEO world collectively panicked. Agencies started selling "CWV audits." Developers started chasing green scores. And most businesses started treating it as a compliance task — like cookie banners or GDPR notices. Something you tick off and move on from.

That's the wrong frame entirely. Core Web Vitals are not about satisfying Google's algorithm. They're a direct measurement of how frustrating your website is to use. And frustration costs money.

What the three metrics are actually measuring

Google measures three things: how fast your page visually loads (LCP), how much content shifts around unexpectedly (CLS), and how quickly your page responds to the first thing a user does (INP). Strip away the acronyms and you get: Does it load? Does it stay still? Does it respond?

METRIC

WHAT IT MEASURES

GOOD

NEEDS WORK

LCP
Largest Contentful Paint

Time until the main content is visible

≤ 2.5s

> 4.0s

CLS
Cumulative Layout Shift

How much page elements jump around

≤ 0.1

> 0.25

INP
Interaction to Next Paint

Delay between a click and a visible response

≤ 200ms

> 500ms

These aren't arbitrary thresholds. They come from Google's research into the point at which users perceive a site as slow, broken, or unresponsive — and start leaving.

The direct revenue translation

Here's what the data says, consistently, across industries:

7%CONVERSION DROP PER 1S OF LCP INCREASE3×MORE LIKELY TO BOUNCE WITH POOR CLS24%DROP IN CONVERSIONS WITH INP > 500MS

Put that in concrete terms: if your site makes €200,000 in leads per year and your LCP is 5 seconds, fixing it to 2.5 seconds doesn't just improve your ranking — it could recover €20,000–€40,000 in conversions that were silently evaporating. No new traffic. No new campaigns. Just the traffic you already have, actually converting.

The leads were always there. The website was just sending them back to Google.

LCP: your first impression has a deadline

LCP is typically your hero image, headline, or above-the-fold block. If it takes longer than 2.5 seconds to appear, users have already formed an opinion. Research shows people make judgments about a website's credibility in 50 milliseconds — but they'll abandon a slow load in about 3 seconds.

The most common LCP killers in 2026:

COMMON LCP KILLERS

Unoptimized hero images — a 3MB JPEG served where a 180KB WebP would do. Render-blocking third-party scripts — analytics, chat widgets, and ad tags that load before your content. No server-side rendering — client-rendered React that sends an empty shell until JavaScript executes. And slow hosting — shared servers with a Time to First Byte over 800ms that starts everything late.

Fixing LCP is primarily an engineering problem. It's not about design. It's about how the server responds, how assets are delivered, and in what order the browser is allowed to work.

CLS: the one users notice without knowing why

Layout shift is insidious because users don't diagnose it — they just feel it. The button that moved when they tried to click it. The paragraph they were reading that jumped down. The form that reordered when an ad loaded. CLS doesn't make people think "this site has bad Core Web Vitals." It makes them think "this site feels cheap."

The fix is usually simpler than the damage it causes: reserve space for images with explicit dimensions, load fonts without invisible text flash, and don't inject content above existing content after page load. Three discipline problems, not three hard engineering problems.

INP: the metric most sites are failing in 2026

INP replaced FID (First Input Delay) as a Core Web Vital in March 2024, and it's significantly harder to pass. Where FID only measured the first interaction, INP measures every interaction throughout the session — clicks, taps, keyboard events — and reports the worst one.

This is where bloated JavaScript frameworks hurt you most. If your page ships 800KB of JS, every click might be competing with the main thread trying to execute something else. The user taps a button and waits. Nothing obvious breaks. But 200ms of sluggishness, repeated across every interaction, compounds into a site that feels heavy. Heavy sites don't convert.

How to actually fix this (not just audit it)

Knowing your scores is not the same as improving them. A PageSpeed Insights report that says "Reduce unused JavaScript" is not an action — it's a category. Here's what actionable looks like:

FIXES THAT MOVE THE NEEDLE

Switch to Next.js with App Router and React Server Components. Server-rendered HTML arrives with content — no blank shell waiting for JS to hydrate. LCP drops dramatically. Use next/image with priority on the hero. Automatic WebP conversion, lazy loading for everything below the fold, and no layout shift. Audit and defer third-party scripts. Every analytics tag, heatmap, and chat widget loads after your content, not before. Move to edge hosting. Vercel, Cloudflare Pages, or similar — your TTFB should be under 200ms from anywhere in Europe.

These aren't micro-optimizations. They're architectural decisions. Which is why they're not fixed by an SEO agency — they're fixed by engineers who understand how browsers work.