Core Web Vitals in 2026: The Metrics That Actually Move Conversion

The state of performance in 2026

Three years after Google made Core Web Vitals a ranking factor, most teams still get them wrong. Not because the metrics are bad, but because teams optimize for Lighthouse scores in development instead of field data in production.

Here's what we've learned from optimizing performance across 20+ production applications: the gap between lab scores and real-user experience is where conversions are won or lost.

Which metrics actually matter

Let's be direct. Based on our data across client projects:

LCP (Largest Contentful Paint) has the strongest correlation with conversion rates. Every 100ms improvement in LCP above the 2.5s threshold correlated with a 1-2% uplift in our clients' conversion funnels. Below 1.2s, the returns diminish.

INP (Interaction to Next Paint) replaced FID and it's a much better signal. If your app feels sluggish when users click buttons or fill forms, INP will catch it. Target: under 200ms, ideally under 100ms.

CLS (Cumulative Layout Shift) is the silent conversion killer. Users don't report layout shift — they just leave. We've seen CLS above 0.1 correlate with 15% higher bounce rates on mobile.

The three interventions that deliver 80% of improvement

After running performance audits for dozens of production apps, we've found that three interventions consistently deliver the majority of gains:

1. Fix your font loading

Most LCP regressions we see trace back to web fonts. The fix is straightforward:

Use font-display: swap on all font faces
Preload your primary font weight in the document head
Subset to Latin characters — this alone reduces payload by 40-60%
Consider system font stacks for body copy

2. Eliminate render-blocking resources

The second biggest LCP offender is render-blocking JavaScript and CSS:

Audit your third-party scripts — analytics, chat widgets, and tracking pixels add up
Use async or defer on non-critical scripts
Inline critical CSS for above-the-fold content
Code-split aggressively — users shouldn't download your admin panel code on the marketing page

3. Reserve space for dynamic content

CLS is almost always caused by content that loads after the initial paint:

Set explicit width and height on all images
Use CSS aspect-ratio for responsive containers
Reserve space for ads, embeds, and dynamic banners
Never inject content above the fold after initial render

Our recommended audit process

When we run a performance engagement, we follow this checklist:

Establish a field data baseline using CrUX or RUM
Set a performance budget (LCP < 1.2s, INP < 100ms, CLS < 0.05)
Add Lighthouse CI to your build pipeline
Fix fonts, blocking resources, and layout shift (in that order)
Measure field data again after 2 weeks
Iterate on the remaining bottlenecks

The bottom line

Performance is not a one-time project. It's a practice. The teams that maintain fast sites are the ones that treat performance budgets like test coverage — automated, enforced in CI, and part of the definition of done.

If your LCP is above 2.5s, you're leaving money on the table. Start with fonts, move to blocking resources, fix your layout shift, and measure in the field. That's 80% of the work.