INP Guide: Web Development Company in Pune

Web Development Company in Pune: How to Fix a Slow-Feeling Website with Interaction to Next Paint (INP)

Interaction to Next Paint (INP) measures how quickly your page reacts after a visitor taps, clicks or presses a key, and whether the screen visibly updates in response. Google treats an INP of 200 milliseconds or less as good, above 200 and up to 500 as needing improvement, and above 500 as poor. A web development company in Pune can usually fix a failing INP by finding which script or handler is blocking the page at that moment, then delaying, trimming or removing it. On WordPress and Shopify sites the culprit is most often not your own code but the tag manager, chat widget, pop-up, review plugin or tracking pixel that was added later.

This article is for owners and marketing managers whose site looks fine in a speed test, yet feels sluggish: the menu opens late, the "Add to cart" button seems to ignore the first tap, the enquiry form freezes for a moment. It explains what INP measures, how to read your own data, why typical business sites fail, what fixes exist, and what to ask a developer before you sign off on "performance work". Thresholds and definitions come from web.dev's INP guide (last updated 2 September 2025) and Google Search Console Help, both read in October 2026. Google can change these, so check the current page before quoting a number in a contract. The worked example is hypothetical; no real client is described. This article does not cover payments, shipping or tax.

If you want the wider picture of all three Core Web Vitals on WordPress, our Core Web Vitals optimisation guide for WordPress covers loading speed and layout stability too. Here we stay on one metric, responsiveness, because it fails for different reasons and is fixed in a different way.

What INP actually measures

web.dev describes INP as a measure of how responsive a page is across the whole visit. It watches the latency of every click, tap and keyboard press, and reports a value representing the slowest interactions, with outliers ignored. Scrolling, hovering and zooming do not count by themselves.

Latency here means the time from the visitor's action until the browser can paint the next frame, the moment the screen shows something has happened. web.dev splits this into three parts:

Input delay. The wait before your code even starts to respond, often because the browser's main thread is busy with something else. A script that is still running when the visitor taps is the usual cause.
Processing duration. The time the event handlers take to run. A click handler that recalculates a cart, fires three tracking calls and opens a pop-up all in one go lengthens this part.
Presentation delay. The time between the handlers finishing and the new frame appearing. Heavy style and layout work, or a very large page structure, stretches it.

The distinction matters because the fix for each part differs. A long input delay points to scripts competing for the main thread. A long processing duration points to a specific handler. A long presentation delay points to rendering cost.

Where INP sits among the Core Web Vitals

INP is the responsiveness metric, beside Largest Contentful Paint (loading) and Cumulative Layout Shift (stability). Search Console takes the worst of the three per URL group, so a fast, stable page can still be labelled "Poor" because of INP alone.

The thresholds, and what "75th percentile" means

The pass mark applies to field data from real visitors, at the 75th percentile, separately for mobile and desktop.

Rating	INP
Good	200 ms or less
Needs improvement	Above 200 ms, up to 500 ms
Poor	Above 500 ms

Three out of four visits must be at or under the threshold. If one visit in four is slow, say an older Android phone while a chat widget loads, you fail even though the median visit is fine.

Why INP is different from "page speed"

Most speed advice targets how fast the page appears. INP begins after it appears, so a page can load perfectly and still fail. The overlap: web.dev notes that main-thread work during load can delay input, so a tap three seconds into a load, while the tag manager is still executing, can produce the slowest response of the visit.

Why WordPress and Shopify sites fail INP

A caution first: I am describing common patterns, not statistics. I have not found an official figure for how many WordPress or Shopify sites fail INP, so I will not give one. The mechanisms below are well documented in general terms; whether they apply to your site is something only a measurement can tell you.

The main thread is one lane

Browsers run most page JavaScript on one main thread, and while a script runs the browser cannot respond to a tap. INP rises when long tasks occupy that lane exactly when a visitor interacts.

Third-party scripts

web.dev's guidance on third-party JavaScript names sending too much JavaScript that keeps the main thread busy as a common slowdown, and suggests loading scripts with async or defer unless they are needed for rendering, lazy-loading embeds until they are needed, and measuring cost with Lighthouse, the DevTools Performance panel and long-task observers. On business sites the typical third-party load looks like this:

Tag managers. Google Tag Manager is a container; what slows the page is what sits inside it. Over time, containers collect old Google Ads tags, three analytics tags, Meta pixel, heat-map recorders, A/B testing snippets, and tags for campaigns that ended years ago. Each one runs code on load and often on every click.
Chat and messaging widgets. Live-chat bubbles and chatbot widgets often load a sizeable script bundle on every page, and some attach listeners to clicks across the page.
Heat-map and session-recording tools. These watch interactions, so they run code on many of them.
Pop-ups and consent banners. Exit-intent and cookie banners add handlers and layout work. They are not wrong, but poorly built ones are expensive.
Review, social-proof and embed widgets. Instagram feeds, review carousels, embedded maps and video players.

Note that a fast loading score can hide all of this, because many such scripts are set to load late. Late loading helps LCP but can land exactly in the window when the visitor starts to tap.

WordPress-specific causes

Page builders can ship large scripts and deeply nested pages; sliders, mega-menus, cart scripts and form plugins each add handlers, and plugins installed for one campaign tend to stay active. Our article on auditing WordPress plugins before development shows how to separate useful plugins from costly ones. A plugin's reputation is not evidence; test with and without it.

Shopify-specific causes

Apps installed from the app store frequently inject their own storefront scripts, and removing an app from the admin does not always remove leftover theme code. Upsell, review, loyalty and pop-up apps are usual suspects, and tracking pixels may be added on top of theme code. TODO: confirm current Shopify documentation on app script injection before quoting platform specifics. Our piece on store speed and Core Web Vitals for e-commerce covers the commerce side.

Heavy front-end JavaScript on custom builds

Custom sites are not immune. web.dev notes that rendering large amounts of HTML with JavaScript delays the next frame, so big lists and over-eager re-rendering push processing and presentation delay up.

How to diagnose INP properly

The sequence matters. Start with field data to learn whether you have a problem, then use diagnostic tools to find which interaction causes it, then reproduce it in the lab.

Step 1: Check field data in PageSpeed Insights

PageSpeed Insights shows Chrome User Experience Report (CrUX) field data for a page and for the whole origin, with mobile and desktop views. web.dev says plainly that this tells you whether INP is a problem, but not what causes it. Look at the origin-level data first, because that includes all pages, then the specific page.

Two limits apply. CrUX only includes Chrome users who have opted in to share data, and low-traffic pages may have no data. If a page shows no field data, that is not a pass; it is simply unmeasured.

Step 2: Look at the Search Console Core Web Vitals report

The report groups similar URLs, separates mobile and desktop, uses a 28-day window of CrUX data and takes the worst of LCP, INP and CLS. One template (all product pages, say) usually shares a result, so fixing the template fixes the group. After a fix, "Start Tracking" begins 28-day validation, so expect a month, not a day. Groups without enough data are left out, so smaller sites may see few or none.

Step 3: Reproduce in Chrome DevTools

The Performance panel shows live local metrics: INP appears after you interact, and the Interactions view lists each interaction with its element and timings. You can load CrUX field data in the panel to compare. Google recommends matching throttling to your users (its illustrative example is Fast 4G with a 20x CPU slowdown, and CPU presets can be calibrated for low and mid-tier phones). Test throttled, not on a fast office machine, and interact during load as well as after.

Step 4: Collect your own field data

If CrUX says you fail but you cannot reproduce it, the open-source web-vitals library's attribution build reports the interaction target, type and the three phases (phase fields need version 4 or later, per web.dev), plus Long Animation Frames data naming the responsible scripts. web.dev notes Long Animation Frames works in Chrome and Edge 123 and later, not Firefox or Safari. Real user monitoring tools offer similar data. Keep any collection aggregate and consistent with your privacy policy.

Reading the result

Symptom in the data	Likely area	First thing to check
High input delay, mostly during load	Scripts still running at page start	Tag manager contents, widget load timing
High input delay, later in the visit	Timers, queued work, background scripts	Heat-map tools, polling, carousels
High processing duration	A specific click or tap handler	Cart, form, filter or menu code
High presentation delay	Style and layout work, large page structure	Page size, animation, big lists

The fixes, in the order we would try them

web.dev's INP optimisation guide recommends yielding to the main thread, prioritising rendering, avoiding layout thrashing, reducing input delay, keeping the page structure small, using content-visibility, and limiting client-side HTML rendering. For business sites, the order of operations below usually gives the most benefit for the least risk. It is a practice order, not a documented rule.

1. Remove what is not used

The cheapest script is the one that is not there. List every third-party script, say who asked for it and whether anyone still looks at its reports. Delete pixels for dead campaigns, abandoned heat-map tools, old A/B tests and duplicate analytics. This is a business decision as much as a technical one, so involve marketing before the developer removes anything.

2. Load the rest later and more selectively

web.dev recommends async or defer for third-party scripts that are not needed to render, and lazy-loading embeds until they approach the viewport. In practice this can mean:

load the chat widget only after the first user interaction, or when the visitor scrolls, or only on pages where support matters;
use a lightweight placeholder (a "facade") for YouTube or map embeds that loads the real player only when tapped. web.dev's third-party article does not use the term facade, but describes the same idea of loading embeds when needed;
restrict heat-map and recording tools to key pages or a sample of visitors rather than all traffic;
trigger tags only on the pages and events that need them, instead of "all pages, all clicks".

Delaying is a trade-off. A late-loading analytics tag can miss early bounces; a late chat widget may miss an impatient visitor. Agree what is acceptable before changing it, and compare enquiry numbers afterwards.

3. Break up long tasks

For code you control, web.dev recommends splitting long event-handling work into separate tasks, using setTimeout in its examples, so that the browser can respond to other inputs between pieces. It adds that yielding indiscriminately is better than not yielding at all. A related principle is to update the visible interface first (show the "added to cart" state), then defer non-essential work such as logging, saving or recalculating secondary things. The guide uses requestAnimationFrame combined with setTimeout for this.

A modern API called scheduler.yield() exists for this purpose, but web.dev's optimisation page did not mention it when I read it, and browser support has varied, so ask your developer to confirm current support before relying on it.

4. Avoid layout thrashing

Reading layout measurements right after changing styles forces the browser to recalculate layout immediately; repeated in a loop it produces long presentation delays. Batch reads and writes.

5. Keep the page structure and rendering light

Web.dev recommends a flat page structure, adding elements during interactions rather than up front, and content-visibility to skip rendering off-screen sections. Page builders with many nested wrappers deserve attention.

6. Replace heavy components

If a slider, mega-menu or filter plugin is the failing interaction, replacing it is often cheaper than tuning it: a lighter theme component on WordPress, or a native feature instead of an app on Shopify. A custom website build can beat stacking plugins, though not always; see WordPress versus a custom website.

What does not fix INP

A caching plugin alone. Caching speeds the server; INP is about browser work after the page arrives.
Compressing images. That is an LCP topic; see our image optimisation guide.
A lab pass alone. web.dev says lab tests can miss what real users experience.

A hypothetical worked example

The following scenario is invented to show the method. It describes no real client, and the numbers are illustrative, not benchmarks.

The site. A Pune-based furniture retailer has a WordPress and WooCommerce store. Search Console shows the product-page group as Poor on mobile, with INP the failing metric. LCP and CLS are in the good range. The owner says the site feels slow when customers tap "Add to cart" and when they open the size and finish selector.

Diagnosis.

PageSpeed Insights confirms the origin's mobile INP sits above 200 ms at the 75th percentile (hypothetically, in the 300 to 400 ms range). The developer treats this as confirmation of the problem, not a diagnosis.
In Chrome DevTools, with CPU throttling set to mimic a mid-range phone, the developer loads a product page and taps "Add to cart" during and just after load. The Interactions view shows the add-to-cart tap has a long processing duration, and a different tap on the finish selector shows a long input delay.
The Performance recording shows that the add-to-cart handler runs a cart refresh script, then fires analytics events from three separate tags, then updates a mini-cart. The finish-selector tap collides with a chat widget and a review-widget script that were still executing a few seconds after load.
The tag manager container turns out to contain two old advertising tags and a heat-map script no one has opened in over a year (hypothetical).

Fixes, in order.

Remove the dead tags and the unused heat-map script after the marketing manager confirms.
Change the chat widget to load after first interaction on product pages, and keep it immediate on the contact page.
Defer the review widget until it nears the viewport.
Rework the add-to-cart handler so the button state and mini-cart update first and the analytics events fire afterwards in a separate task.
Re-test on the throttled profile; compare the Interactions view before and after.

Outcome handling. The team records before and after local numbers, publishes the change, and then waits. Search Console's validation window is 28 days, so the report will not confirm the change quickly. They keep an eye on enquiry and add-to-cart rates for the same period, since the chat-delay change could have a side effect. If enquiries drop, the chat timing is rolled back on the pages where it mattered. A fix is a hypothesis until the field data agrees.

Notice what the example did not need: a new theme, a new host, or a rebuild. It needed measurement, a clear list of what is on the page, and decisions about what to delay or remove.

What to ask a web development company in Pune

Responsiveness work is easy to sell vaguely and hard to verify. These questions help separate a team that will measure from one that will install an optimisation plugin and report success.

"Which field data will you use as the baseline?" A good answer names PageSpeed Insights CrUX data, the Search Console Core Web Vitals report, or real-user monitoring, and notes mobile and desktop separately. A weak answer quotes a single lab score.
"How will you find which interaction is slow?" Look for DevTools Performance testing under CPU throttling, and, where needed, the web-vitals attribution build or a monitoring tool.
"Will you list every third-party script and who owns it?" An audit of tags, pixels, widgets and plugins should be a deliverable, with a recommendation to keep, delay or remove each.
"What will you change in our tag manager, and who approves it?" Marketing and ads staff need to sign off before tags disappear, or tracking breaks silently.
"How will you test on slower phones?" Throttled testing, ideally also on a real mid-range Android handset.
"What is the timeline for seeing it in Search Console?" If someone promises a green report in a week, they have not read the 28-day window.
"What is out of scope?" INP fixes may stop at your own code and your configuration of third-party tools. If a vendor's widget is the problem, the remedy may be a different vendor.
"How do we avoid regressions?" New tags can re-break the score; ask for staging tests first, as in our staging and rollback article.

For a general checklist beyond performance, see our shortlist questions for a Pune web development company.

What it should cost

Effort depends on the number of third-party scripts, the platform and whether one component needs rebuilding, so ask for a fixed-scope audit first and quote fixes after. TODO: add a Govindani audit price range once confirmed.

Next steps

Start with three checks you can do in an afternoon: open PageSpeed Insights for your most important page and note the mobile INP; open Search Console's Core Web Vitals report and see which page groups fail; then list every script on that page and mark which ones you can no longer justify. If you want a second opinion or a measured audit, you can reach us through our contact page or on WhatsApp at https://wa.me/919201958278. If search visibility is the larger concern, our SEO service team can look at how performance fits alongside content and technical work.

Frequently Asked Questions

What is a good INP score?

Google's web.dev guidance treats 200 milliseconds or less as good, above 200 and up to 500 milliseconds as needing improvement, and above 500 milliseconds as poor. The score is judged at the 75th percentile of real visits, separately for mobile and desktop.

Why does my site pass PageSpeed Insights but fail INP in Search Console?

Lab tests simulate a load on a single device, while Search Console uses real visitor data over 28 days. Real visitors on slower phones, with chat widgets and tags running, tap at moments a lab test never tries. Check the field data section of PageSpeed Insights and reproduce in DevTools with CPU throttling.

Do chat widgets and Google Tag Manager hurt INP?

They can. They add JavaScript to the single main thread, and a busy thread delays the browser's response to taps. The effect depends on what is inside the tag container and how the widget loads, so measure before deciding. Removing unused tags and delaying non-essential widgets are common first steps.

How long before Search Console shows the improvement?

The report uses a 28-day window of field data, and validation after a fix tracks over 28 days, so expect about a month rather than days. Local DevTools testing shows the change immediately and is the way to check your work in the meantime.

Is INP fixable on Shopify, or only on custom sites?

It is often fixable on Shopify, mostly by auditing installed apps and tracking scripts and removing or delaying what is not needed. Where a theme or app component is the issue, replacing it may be needed. The platform limits what you can change in some areas, so ask for a scoped audit first.

Sources: