Core Web Vitals 2026: Mastering INP (Interaction to Next Paint)

1. What Is INP and Why Google Prioritises It

Interaction to Next Paint (INP) measures how quickly your website responds when a visitor does something — taps a button, opens the mobile menu, expands a FAQ, types into a form field. It replaced First Input Delay (FID) as an official Core Web Vital in March 2024, and it is a much tougher test.

FID only timed the first click on a page. INP watches every click, tap and key press during the whole visit and reports one of the slowest. So a homepage that loads fast but freezes for half a second when someone opens the navigation drawer will fail INP, even though it would have passed FID comfortably.

Google scores INP from real Chrome users (the CrUX dataset), at the 75th percentile of page loads:

• Good: 200 milliseconds or less
• Needs improvement: 200–500 ms
• Poor: over 500 ms

Why does it matter for business? Because 200 ms is roughly the point where a delay becomes noticeable. Past that, a visitor in Pune tapping “Add to Cart” on a 4G connection starts to wonder whether the tap registered, taps again, and you get a double order or an abandoned cart. Core Web Vitals are also a confirmed ranking signal within Google’s page-experience systems — not the biggest one, but a tie-breaker between otherwise similar pages, and in competitive local searches like “web design company in Vikhroli” the tie-breakers decide who gets the click.

2. The Three Phases of Every Interaction

To fix INP you need to know where the time goes. Every interaction has three phases, and the metric is the sum of all three:

1. Input delay — the time between the tap and the moment the browser can start running your event handler. This is long when the main thread is busy doing something else (usually a third-party script or a large JavaScript bundle still executing).
2. Processing time — how long your event handlers actually take to run. Heavy handlers that fetch data, rebuild large parts of the page, or run analytics synchronously live here.
3. Presentation delay — the time from the handler finishing to the next frame being painted. Big DOM trees, complex CSS selectors and forced layout recalculations inflate this phase.

In our audits of business websites across Pune and Mumbai, the split is remarkably consistent: input delay caused by third-party scripts is the number one offender, followed by presentation delay from oversized page builders. Actual slow event-handler code is rarer than developers expect.

3. The Top Causes of Poor INP on Business Websites

• Long JavaScript tasks on the main thread. Any task longer than 50 ms blocks the browser from responding to input. Unoptimised WordPress themes, jQuery plugin stacks and unbundled React apps routinely ship 100–300 ms tasks.
• Too many third-party scripts. A typical Indian SMB site we audit carries Google Tag Manager, GA4, the Meta Pixel, a WhatsApp widget, a chatbot, Hotjar and sometimes two of each. Every one of them competes for the same CPU at the exact moment a visitor is trying to interact.
• Huge DOM trees. Page builders like Elementor and Divi wrap every element in five or six nested divs. Once a page passes ~1,500 DOM nodes, every style change forces the browser to recalculate layout for a large tree, which shows up as presentation delay.
• Layout thrashing. JavaScript that reads a layout property (offsetHeight, getBoundingClientRect()) and then writes a style, repeatedly, inside one handler forces multiple synchronous reflows.
• Animating the wrong properties. Menus and accordions animated with height, top or margin trigger layout on every frame. transform and opacity are handled by the compositor and cost almost nothing.
• Low-end devices. INP is collected from real users. If a large share of your audience is on budget Android phones — true for most consumer businesses in India — your field INP will be far worse than what you see on a developer’s laptop.

4. How to Find Your Slow Interactions

Start with data, not guesses:

1. Google Search Console → Core Web Vitals report. This tells you which URL groups are failing INP on mobile and desktop, using the same field data Google ranks with. Fix the groups with the most URLs first.
2. PageSpeed Insights. The top “Discover what your real users are experiencing” panel shows field INP for the URL and the whole origin. Below it, the lab audit lists long main-thread tasks and third-party script cost.
3. Chrome DevTools → Performance panel. Record yourself using the page on a throttled CPU (4× slowdown) and look at the Interactions track. Each interaction shows the three phases so you can see which one is the problem.
4. The web-vitals library. Add it to your site and send INP values, plus the element that was interacted with, to GA4. In a few days you will know exactly which button or menu is slow for real customers — something no lab tool can tell you.

5. How to Fix High INP, Step by Step

Fix input delay

• Defer every non-critical script. Chat widgets, pixels, heat maps and social embeds should load after the load event, or better, on the first user interaction or scroll. On our own site, moving the analytics and pixel scripts to after load cut Total Blocking Time by roughly 65%.
• Break long tasks. Split large JavaScript work into chunks and yield between them with scheduler.yield() (or setTimeout(fn, 0) as a fallback) so the browser can handle input in between.
• Ship less JavaScript. Tree-shake, code-split by route, remove unused plugins. On WordPress, a plugin audit alone often removes 30–40% of the JS payload.

Fix processing time

• Do the visual update first, everything else later. In a click handler, update the UI immediately, then push analytics calls, data fetches and logging into a setTimeout or requestIdleCallback.
• Move heavy computation to a Web Worker — filtering large product lists, image processing, search indexing.
• Debounce input handlers on search boxes and filters so you are not re-rendering on every keystroke.

Fix presentation delay

• Reduce DOM size. Simplify page-builder layouts, lazy-render off-screen sections and use content-visibility: auto on long pages so the browser skips layout for content that is not on screen.
• Batch reads and writes. Read all the layout values you need first, then apply all style changes, or use requestAnimationFrame for writes.
• Animate with transform and opacity only, and add will-change sparingly to elements that really animate.

“Most websites don’t have a JavaScript problem. They have a too much JavaScript at the wrong time problem. Deferring the scripts that don’t need to run before the first tap fixes INP on more sites than any code rewrite.” — Deepali Bamble

6. What Passing INP Does for a Business

Speed work is easy to dismiss as a technical vanity metric, so here is what it actually changes. A responsive page keeps visitors on task: forms get completed, product filters get used, and the WhatsApp button responds on the first tap. For e-commerce stores that means fewer abandoned carts; for service businesses it means more enquiries from the same ad spend, because Google Ads Quality Score also rewards landing-page experience (we cover that in our Google Ads landing page guide).

There is also a compounding SEO effect. Pages that pass all three Core Web Vitals — LCP, INP and CLS — are eligible for the full page-experience benefit, and fast, stable pages tend to earn better engagement signals, which feed back into rankings. If you are already investing in SEO or content, leaving Core Web Vitals failing is like running a shop with the shutter half-closed.

7. Ongoing Performance Care with Web Crafters

INP is not a one-time fix. Every new plugin, tracking tag or theme update can push it back over 200 ms, which is why we include a monthly Core Web Vitals check in our website care plans. For sites that are failing today, our speed & security optimisation service starts with a field-data audit, fixes the biggest interaction bottlenecks first, and re-measures against real Chrome users — not just a lab score. And if the site is built on a heavy page builder that cannot be rescued, a rebuild on a lean, custom-coded stack (or a Progressive Web App) is usually cheaper than a year of patching.

Frequently Asked Questions