Back to the Journal
Engineering

Core Web Vitals in 2026: INP, and why speed is a business metric

Speed stopped being a back-office engineering concern a while ago. In 2026, Core Web Vitals sit squarely on the line between a good experience and lost revenue — and INP is the one that still trips teams up.

Theo Almeida
Theo Almeida
Principal Engineer, CodexLab
6 min read
A laptop showing a web performance dashboard with Core Web Vitals scores

Speed stopped being a back-office engineering metric a while ago. In 2026, Core Web Vitals sit squarely on the line between a good experience and lost revenue.

Three vitals still anchor the conversation: Largest Contentful Paint for loading, Cumulative Layout Shift for visual stability, and Interaction to Next Paint for responsiveness. INP — which replaced First Input Delay in 2024 — is the one that still trips teams up, because it measures the full latency of every interaction, not just the first tap.

Why INP is the hard one

LCP and CLS are largely about how a page arrives. INP is about how it feels once you’re using it. A heavy main thread, oversized JavaScript bundles, and expensive event handlers all show up here, in the lag between a click and a visible response. It rewards exactly the server-first, ship-less-JavaScript discipline the rest of the industry is moving toward.

An analytics dashboard plotting interaction latency over time
INP captures the lag between a tap and a visible response — the part users actually feel.

The fix is rarely a single trick. It’s breaking up long tasks, deferring non-critical work, and being honest about how much code runs on interaction. Measured on a mid-range phone, the difference between a sluggish and a snappy interface is usually a few hundred kilobytes of JavaScript nobody needed.

A business metric in disguise

Vitals correlate with the numbers leadership cares about. Faster, more stable, more responsive pages reduce friction in the funnel — and the compound effect of better rankings plus higher conversion can move revenue meaningfully. That’s why we treat performance as a product requirement, not a cleanup task.

A developer profiling long tasks in browser dev tools
Fix the template that touches the most high-value traffic first — not the page that’s easiest to reach.

Practically, we prioritise by impact and coverage: improve the templates that serve the most high-value traffic — product, category, and service pages — before chasing long-tail URLs.

Don’t guess — measure. Then fix the template that touches the most revenue, not the page that’s easiest to reach.

Keeping it fast after launch

Performance regresses the moment you stop watching it. We wire vitals into monitoring so a heavy third-party script or an unoptimised hero image shows up as a number, not a complaint. A site that launches fast and rots in six months was never really built for speed — it was just new.

The goal isn’t a perfect lab score. It’s a page that respects the person’s time and device, every single visit.

Theo Almeida
Theo Almeida
Principal Engineer, CodexLab

Theo writes about the engineering side of the studio — performance, architecture, and building things that last.

Keep reading