Interaction to Next Paint (INP): The New Core Web Vital Mumbai Sites Must Pass in 2026

Interaction to Next Paint, or INP, is the Core Web Vital that measures how fast your website responds when someone taps a button, opens a menu, or fills a form — and Google has been scoring every indexed page on it since March 12, 2024, when INP officially replaced First Input Delay (FID) as the third Core Web Vital. If your Mumbai business site loads a WhatsApp chat widget, a testimonial carousel, and three tracking scripts before the user can tap anything, there's a good chance you're already failing it — and you won't find out from a slow-loading homepage, because INP has nothing to do with load time.

What Is Interaction to Next Paint (INP)?

INP is a Core Web Vital that measures the latency of every click, tap, and keyboard interaction on a page, from the moment a user acts to the moment the browser paints the next visual update. Google's web.dev documentation defines it as assessing "a page's overall responsiveness to user interactions by observing the latency of all click, tap, and keyboard interactions." Unlike FID, which only clocked the delay before the browser could start processing the very first interaction, INP tracks every interaction across the entire visit and reports the worst (or near-worst) one at the 75th percentile of page loads, split separately for mobile and desktop.

That distinction matters more than most site owners realise. A page could load fast, show a perfect First Contentful Paint, and still fail INP badly — because the failure shows up three interactions in, after a chat widget's JavaScript has finished initialising and is now blocking the main thread every time someone taps the mobile menu.

INP Pass/Fail Thresholds for 2026

Google scores INP into three bands, and only "Good" counts as a pass for Core Web Vitals purposes. Per Google's official web.dev INP documentation, the thresholds are:

Google measures INP at the 75th percentile of real visitor interactions collected through Chrome User Experience Report (CrUX) field data — not a single lab test. That means one slow interaction buried deep in a session can be forgiven, but a pattern of sluggish taps across most visits will push your page into "Needs Improvement" or "Poor" even if your Lighthouse score looks fine in the office.

Why Mumbai Business Sites Commonly Fail INP

Most Mumbai business websites fail INP because of stacked third-party JavaScript, not because of bad code they wrote themselves. We see the same pattern on almost every audit across Andheri and Powai: a WordPress or Shopify theme ships with jQuery baked in, someone adds a WhatsApp chat bubble plugin, marketing drops in a Meta Pixel and a Google Ads tag, and a homepage carousel gets bolted on last — each one quietly registering its own click and scroll listeners on the main thread.

The common causes we see, in order of frequency:

• WhatsApp and live-chat widgets that load a full chat SDK on every page, even when the visitor never opens the widget, and re-run expensive DOM work on every click near it.
• Third-party marketing scripts — Meta Pixel, Google Ads conversion tracking, multiple analytics tools — each firing separate event listeners that compete for the same main thread.
• Image carousels and sliders built on older jQuery plugins that recalculate layout on every swipe or button tap instead of using CSS transforms.
• Heavy client-side forms with real-time validation libraries that re-render the entire form on every keystroke instead of the single field being edited.
• Render-blocking JavaScript bundles from page builders (common on WordPress sites built with visual builders) that ship one large bundle instead of splitting code by page.

A tech-heavy business park like Powai, full of SaaS and IT-services firms, tends to compound this — product demo widgets, live chat, and analytics dashboards all fighting for the same thread on a single landing page. Andheri's retail and service businesses see the opposite problem just as often: a WordPress site with a dozen stacked plugins, each contributing its own script, none of them individually heavy, but the total main-thread work adding up to a 600ms tap delay.

Neither problem is really about how much traffic the site gets. We've seen a five-page Andheri service business score worse on INP than a high-traffic Powai SaaS landing page, purely because the smaller site's page builder was loading four unused carousel scripts on every page, including ones with no carousel on them at all.

How INP Is Actually Measured on Your Site

INP is measured through real user interactions recorded in the field, primarily via Chrome's CrUX dataset, and surfaced in Google Search Console's Core Web Vitals report. You can also watch it happen in real time with Chrome DevTools' Performance panel, or get a quick read from the free PageSpeed Insights tool, which shows a lab estimate plus real CrUX field data once your site has enough traffic to qualify.

1. Open Google Search Console and go to Experience → Core Web Vitals. Any URL group flagged "Poor" or "Needs Improvement" under INP needs attention first.
2. Run PageSpeed Insights on your homepage and your highest-traffic landing pages — check both the mobile and desktop tabs, since INP thresholds are scored separately for each.
3. Open Chrome DevTools → Performance panel, record a session while clicking your main navigation, a form field, and any chat widget, and look at the "Interactions" track for anything over 200ms.
4. Check the INP breakdown — Chrome reports three phases: input delay (time before the browser starts handling the interaction), processing time (your JavaScript actually running), and presentation delay (time to paint the result). Most Mumbai sites we've audited lose the most time in processing — JavaScript execution — not input delay.

How to Fix INP on a Mumbai Business Website

Fixing INP means reducing how much JavaScript runs in response to a tap, not just reducing total page weight. These are the fixes that move the needle fastest, in the order we apply them during a client audit:

1. Audit and defer third-party scripts. Load your WhatsApp widget, chat SDK, and marketing pixels with defer or on user interaction (e.g. only initialise the chat widget when the user scrolls near it or taps the bubble icon), instead of blocking the main thread on every page load.
2. Break up long JavaScript tasks. Any single script task running longer than 50ms blocks all input handling until it finishes. Split large functions using setTimeout, requestIdleCallback, or the newer scheduler.yield() API so the browser can respond to a tap between chunks.
3. Replace jQuery carousels with CSS-driven ones. A carousel that animates with CSS transforms and transitions costs the main thread almost nothing; one that recalculates DOM positions in JavaScript on every swipe is a common INP culprit on Mumbai retail and restaurant sites.
4. Debounce and virtualise heavy form validation. Validate on blur or with a short debounce instead of on every keystroke, and avoid re-rendering the whole form when only one field changed.
5. Reduce DOM size. A bloated DOM (common on page-builder WordPress sites) makes every style recalculation and re-render slower — Google's own guidance recommends keeping DOM size lean as part of INP optimisation, since large DOM trees increase the cost of every input-driven update.
6. Move non-critical work off the main thread with Web Workers where possible — heavy calculations, JSON parsing, or data transformations don't need to compete with the browser's ability to respond to a click.

On a modern stack, this is far easier to control. A Next.js site lets us code-split by route so a chat widget's JavaScript never loads on pages where it isn't used, and React's concurrent rendering features naturally break up long update tasks — one reason we increasingly recommend Next.js for Mumbai businesses that depend on fast lead-capture forms.

If your site is still on a heavily-plugin-dependent WordPress build, INP problems often stack up faster than they would on a leaner stack — every added plugin is another script fighting for the same main thread. Our website speed optimisation service starts by profiling exactly which scripts are causing your slowest interactions before touching anything, rather than guessing which plugin to disable first.

Not sure where your site's INP score actually stands? Get a full breakdown of every interaction slowing your pages down.

INP vs. LCP and CLS — Why You Need All Three

INP measures responsiveness, LCP measures loading speed, and CLS measures visual stability — a site can pass two of the three and still fail Core Web Vitals overall. We've published a broader walkthrough of what Core Web Vitals means for Mumbai business owners if you need the full picture across all three metrics; this article focuses specifically on INP because it's the newest of the three and the one we see Mumbai sites mismeasure most often — teams still check PageSpeed for LCP and assume a fast-loading page is automatically a fast-responding one.

They're not the same thing. A site can hit Google's LCP target of 2.5 seconds and still leave a visitor tapping a menu button for 800 milliseconds before anything happens, because LCP only measures how fast the largest visible element renders — not what happens after the page finishes loading.

Tools to Monitor INP Ongoing

Monitoring INP requires both field data and lab testing, because lab tools can miss real-world script conflicts that only show up on actual visitor devices. Here's the combination we set up for ongoing client sites:

• Google Search Console's Core Web Vitals report — free, uses real CrUX field data, updates roughly every 28 days.
• PageSpeed Insights — instant lab test plus field data if the URL has enough CrUX traffic.
• Chrome DevTools Performance panel — the only way to see exactly which script is causing a specific slow interaction.
• web-vitals JavaScript library — Google's own open-source library for logging real INP scores from your actual visitors into your analytics tool, catching regressions before Search Console reports them weeks later.

If your site already has analytics and tracking set up correctly, adding real-user INP monitoring is a small addition that pays for itself the first time a new plugin quietly breaks responsiveness.

Get your INP, LCP, and CLS scores fixed by a team that builds fast Next.js and Laravel sites for a living.

Frequently Asked Questions

What is a good INP score?

A good INP score is 200 milliseconds or less, measured at the 75th percentile of real visitor interactions. Google rates 200ms–500ms as "Needs Improvement" and anything above 500ms as "Poor," per its official web.dev Core Web Vitals thresholds.

When did INP replace FID as a Core Web Vital?

INP officially replaced First Input Delay (FID) as the third Core Web Vital on March 12, 2024, as announced on Google's web.dev blog. FID is no longer scored in Search Console's Core Web Vitals report.

Why does my WhatsApp chat widget slow down my INP score?

Most WhatsApp and live-chat widgets load a full chat SDK on every page and register JavaScript event listeners that run even when the visitor never opens the chat window. That script competes with your page's other JavaScript for main-thread time, and on a busy page it commonly pushes tap and click response times well past Google's 200ms "Good" threshold.

Does INP affect Google rankings for my Mumbai business website?

Yes. Core Web Vitals, including INP, are part of Google's page experience signals used in ranking, and a "Poor" or "Needs Improvement" INP rating can also mean visitors abandon slow-feeling pages before converting — a direct hit to lead generation, independent of any ranking effect.

How do I check my website's INP score right now?

Run your homepage and top landing pages through Google PageSpeed Insights, or check Google Search Console's Experience → Core Web Vitals report if your site already has enough traffic for CrUX field data. Both are free and take under two minutes.