What failing Core Web Vitals actually costs you
47%
Of sites pass all three
43%
Fail INP specifically
2.5s / 200ms / 0.1
The thresholds
Fewer than half of sites currently pass all three Core Web Vitals. The most-failed of the three isn’t the one most teams optimise for, and the conversion figures everyone quotes are shakier than they sound. Both of those are worth knowing before you spend a sprint on this.
The thresholds, and which one is hard
| Metric | Measures | Good | Needs work | Poor |
|---|---|---|---|---|
| LCP | When the largest element renders | ≤ 2.5s | 2.5–4.0s | > 4.0s |
| INP | Latency of interactions | ≤ 200ms | 200–500ms | > 500ms |
| CLS | Unexpected layout movement | ≤ 0.1 | 0.1–0.25 | > 0.25 |
LCP and CLS are largely solved by discipline: size your images, reserve space for anything that loads late, don’t inject banners above content that has already rendered. Tedious, but tractable.
INP is the one 43% of sites fail, and it’s harder because it isn’t a loading problem. It measures how long the interface takes to respond when someone actually interacts with it — which means it’s a main-thread problem, and the main thread is where your JavaScript lives.
That distinction matters for where you spend effort. You cannot fix INP by compressing images. You fix it by doing less work in JavaScript, breaking up long tasks, and shipping fewer third-party scripts that you don’t control.
About those conversion numbers
You’ve seen the claims. A one-second delay costs 7% of conversions. Sites that pass see 24% lower bounce rates. E-commerce sites hitting all three thresholds see 15–30% conversion improvements.
These get repeated as though they were laws of physics. They’re worth taking seriously, and they’re worth reading carefully, because most of them share three problems.
They’re correlational. Fast sites convert better. Fast sites are also, on average, better funded, better engineered, and better designed. Performance is entangled with every other quality signal, and an aggregate correlation can’t separate them.
The baselines vary wildly. “A one-second delay costs 7%” means something very different going from 1s to 2s than from 8s to 9s. The relationship isn’t linear and the studies rarely say where on the curve they measured.
The wins are usually bundled. The frequently cited case where LCP went from 5.2s to 1.8s and conversion rose 12% also involved optimising images and preloading the hero — real work that changed how the page looked and felt, not just its metrics.
Where the problem usually is
Across the audits we’ve run, the cause is boringly consistent and rarely the framework everyone suspects.
Images, most of the time. On a typical store or marketing site, imagery is 70–90% of page weight. Modern formats, correct sizing per breakpoint, and genuinely lazy loading below the fold usually halve load time before anyone opens a JavaScript profiler.
Third-party scripts, second. Analytics, chat widgets, session recording, consent managers, ad pixels. Each one was added by someone reasonable for a reasonable purpose, and collectively they own your main thread. This is the single biggest INP contributor we see.
Client-side rendering, third. If the first response is an empty div, LCP can’t happen until JavaScript has downloaded, parsed, executed, and fetched data. You’ve serialised four things that could have been zero.
The framework, almost never. Teams routinely propose a rewrite when the actual fix is a 4MB hero image and a chat widget loading synchronously. Rewrites are expensive and rarely address the cause.
Fix it in the order that pays
Field data beats lab data. Lighthouse tells you what’s possible on a throttled connection in a data centre; the Chrome User Experience Report tells you what your actual visitors experienced on their actual phones. When they disagree, believe the field data.
The part that matters more than the score
Passing Core Web Vitals is a threshold, not a ranking factor you can accumulate. Going from 2.4s to 1.2s doesn’t buy you twice the ranking benefit — you were already passing. The value of that second second is in how the site feels, which is real but isn’t an SEO argument.
So treat it as hygiene: get into the green, keep it there with budgets enforced in CI, and spend the remaining effort on the things that actually differentiate — content, product, and whether the page answers the question the visitor arrived with.
Performance is much easier to keep than to recover. The teams who never have a Core Web Vitals project are the ones who set a budget before designing the hero.
Sources: Digital Applied — Core Web Vitals 2026 · Meteora — thresholds and SEO impact