Core Web Vitals in 2026: Fixing INP Before It Costs You Rankings

Interaction to Next Paint is the metric most sites fail. A practical guide to diagnosing and fixing INP — and why it directly affects your search rankings and revenue.

Your site might pass two of the three Core Web Vitals and still be losing rankings. The culprit is usually INP.

Most teams optimised for loading speed years ago and assumed Core Web Vitals were handled. Then Interaction to Next Paint (INP) became the responsiveness metric, and a lot of sites that felt "fast" started failing — because INP measures something loading metrics miss. Since it directly affects search rankings and conversion, it's worth understanding properly. Here's what INP is, why so many sites fail it, and how to fix it.

What the three Core Web Vitals measure in 2026

Largest Contentful Paint (LCP) measures loading — how long until the main content appears. Cumulative Layout Shift (CLS) measures visual stability — how much the page jumps around as it loads. And Interaction to Next Paint (INP) measures responsiveness — when a user taps or clicks, how long until the page visibly responds.

INP is the one that catches teams out because it's about runtime behaviour, not initial load. A site can load beautifully — great LCP, no layout shift — and still feel sluggish when you actually interact with it, because the JavaScript handling your clicks is doing too much work and blocking the browser from updating the screen. Loading-focused optimisation doesn't fix that.

Why so many sites fail INP

The root cause is almost always too much JavaScript running on the main thread in response to user interactions. When a user clicks a button, the browser needs to run your event handler and then paint the result. If your handler triggers a heavy, synchronous chunk of work — re-rendering a large component tree, processing a big array, running expensive layout calculations — the browser can't paint until that work finishes, and the interaction feels laggy.

Common offenders: oversized client-side bundles that ship far more JavaScript than the page needs, expensive re-renders triggered by every keystroke or click, third-party scripts (analytics, chat widgets, ad tags) competing for the main thread, and long tasks that never yield control back to the browser. The more interactive your page and the more JavaScript it ships, the more likely it fails INP.

How to actually fix INP

Start by measuring real user data, not just a lab test — INP is about real interactions, so field data tells you which interactions actually hurt. Then attack the causes in order. Ship less JavaScript: server components and code-splitting mean the browser has less to parse and execute. Break up long tasks: yield control back to the browser so it can paint between chunks of work rather than blocking on one big task. Defer non-essential work: heavy computation can often happen after the interaction is acknowledged, or off the main thread entirely. And audit third-party scripts ruthlessly — a single poorly-behaved widget can wreck your INP across the whole site.

For most sites, the highest-leverage fix is simply shipping less client-side JavaScript. An architecture that renders on the server and sends minimal JavaScript to the browser sidesteps the main cause of poor INP before you have to optimise individual handlers. That's a large part of why the server-component shift matters commercially, not just technically.

Key takeaways for businesses

  • INP measures responsiveness to interactions, not load time — a site can load fast and still fail it, which is why teams who "fixed performance" years ago are now slipping.
  • The root cause is almost always too much JavaScript on the main thread; shipping less of it is the single highest-leverage fix.
  • Measure with real-user field data, break up long tasks, defer non-essential work, and audit third-party scripts — and remember INP affects both rankings and conversions.

Frequently Asked Questions

What is INP in Core Web Vitals?

Interaction to Next Paint (INP) measures how quickly a page visibly responds when a user interacts with it — clicking, tapping, or typing. It captures responsiveness throughout the page's life, unlike loading metrics, and is a Google ranking factor.

Why is my site failing INP?

Almost always because too much JavaScript runs on the main thread when users interact, blocking the browser from painting the response. Common causes include large client bundles, expensive re-renders, long synchronous tasks, and heavy third-party scripts.

How do I improve INP?

Ship less JavaScript (server rendering and code-splitting), break long tasks into smaller chunks that yield to the browser, defer non-essential work, and audit third-party scripts. Measure with real-user field data so you fix the interactions that actually matter.

Failing Core Web Vitals and losing rankings?

I audit and fix web performance — including the INP problems most teams miss — with measurable before-and-after results. Let's talk about your site.