INP, the Core Web Vital for responsiveness, still fails mainly on phones, on inner pages and on feature-heavy sites: in 2025, 97% of sites had good INP on desktop but only 77% on mobile. Standard lab tests cannot see it, and the usual fix is removing or delaying JavaScript.
Interaction to Next Paint (INP), the Core Web Vital that times how quickly a page visibly responds to a tap, click or key press, still fails in three places: on phones, on inner pages and on sites crowded with widgets and tags. In the HTTP Archive's 2025 Web Almanac, 97% of websites had good INP on desktop but only 77% on mobile, so a site that feels instant on your office computer can still lag on your customers' phones.
It is not the vital most sites fail. On mobile that is still Largest Contentful Paint, which only 62% of sites pass. INP is the one that hides: standard lab tests cannot measure it, many small sites have too little traffic for Google to report it, and it tends to worsen as features pile up. The fix is usually subtraction, not another plugin. (If your pages are also slow to appear, start with why your website is slow.)
- of sites had good INP on mobile in 2025, against 97% on desktop
- 77%
- of sites had good INP on mobile in 2025, against 97% on desktop
- of mobile inner pages had good INP, against 80% of home pages
- 69%
- of mobile inner pages had good INP, against 80% of home pages
- of India's 2025 smartphone shipments were under US$200 (IDC's 16% and 41% price bands combined)
- 57%
- of India's 2025 smartphone shipments were under US$200 (IDC's 16% and 41% price bands combined)
- or less is good INP, at the 75th percentile of real visits
- 200 ms
- or less is good INP, at the 75th percentile of real visits
01
What INP measures, and what it replaced
INP became a Core Web Vital on 12 March 2024, replacing First Input Delay, which only timed the wait before a visitor's first interaction was handled. INP watches every click, tap and key press during a visit (scrolling, hovering and zooming do not count) and reports roughly the slowest, ignoring one outlier for every 50 interactions. If nobody interacts, there is no INP.
Google judges mobile and desktop separately: 200 milliseconds or less is good, up to 500 ms needs improvement, and slower is poor. Each interaction has three phases, and the slow one tells you where to look.
| Phase | What is happening | Usual cause |
|---|---|---|
| Input delay | The tap waits while the browser is busy | Scripts loading, parsing or running at that moment, tags included |
| Processing duration | The page's own event code runs | Menus, sliders, filters or forms that do too much in one go |
| Presentation delay | The browser paints the new screen | A very large page structure, or lots of HTML built by JavaScript |
02
Why your desktop test misses it
Google's verdict in its own tools comes from field data. The Chrome UX Report (CrUX) collects timings from opted-in Chrome users on desktop and Android, on their own devices and connections; Chrome on iPhone does not contribute. PageSpeed Insights shows the previous 28 days of it, and Search Console uses the same data. Your laptop on office broadband is the best case, not the typical one.
In India the typical case is a modest Android phone: by IDC's figures, Apple had just 10% of smartphones shipped in 2025, 16% of shipments were priced under US$100 and another 41% between US$100 and US$200. Slower devices amplify the effects of page complexity, the Almanac notes, and its lab data shows the main thread getting busier: median mobile Total Blocking Time (TBT) rose 58% in a year to 1,916 ms, even as field INP improved.
A standard lab test taps nothing, so it cannot see a slow interaction. web.dev treats TBT as a possible lab stand-in for INP, but not a substitute.
03
INP problems grow as features pile up
Among the 10,000 most visited websites, only 56% had good mobile INP, against 77% across all sites. The Almanac's authors point to richer features and heavier third-party integrations, and note that less popular sites are often simpler and lighter. Inner pages lag home pages for a similar reason: filters, carousels, form validation, widgets and analytics accumulate deeper in a visit.
So a five-page brochure site may well pass. The risk rises with the things growing businesses add:
- Tags that pile up. About 90% of pages load at least one third party, with Google's tag manager and analytics among the most common. Duplicates appear when a tag is hard-coded and also fired from the tag manager, and web.dev reports a correlation between bigger tag managers and poorer INP.
- Chat and video embeds that load their full code before anyone chats or presses play.
- Page builders. An estimated 60% of WordPress sites use one, Elementor most often.
- Heavy event handlers that do all their work at once when a menu, filter or form is tapped.
- A huge page structure. The more elements a page has, the more work each update takes. The Economic Times removed about 1,200 nodes by rendering menu items only when the menu was clicked.
04
How to find your slow interactions for free
All four checks are free. Stop when you find the culprit.
- Check the field data for your key pages in PageSpeed Insights on mobile and in Search Console's Core Web Vitals report, where each group of URLs takes the status of its worst metric.
- Reproduce it on a slowed-down machine. In Chrome DevTools, open the Performance panel and turn on CPU throttling, which can be calibrated to match low- and mid-tier phones. Live metrics then show your INP as you tap, split into phases.
- Find the heavy scripts. PageSpeed Insights' 3rd parties insight groups requests by provider, and the Coverage panel shows code that loaded but was never used.
- Measure real visitors. Google's web-vitals library reports INP and its phases from your own visitors, and the Long Animation Frames API, in Chrome since version 123, names the scripts behind slow frames. Since Safari 26.2 (December 2025), every major browser supports the APIs behind INP, so your data can include iPhone users, though CrUX stays Chrome-only.
05
Fix by subtraction first, then optimise
The cheapest INP fix is code that no longer runs. Before anyone rewrites application code:
- Delete what nobody owns. Label every tag with an owner in the tag manager, pause or remove the rest, and make sure each analytics or ad platform loads once.
- Delay what is not urgent. Fire non-essential tags after the page has loaded, and load third-party scripts with async or defer unless they must run first.
- Swap embeds for facades. Show a static chat button or video thumbnail and load the real widget on the first tap. Lighthouse 13 dropped its facade audit in October 2025, but the technique is still sound.
- Trim the builder. Switch off add-ons and widgets a page does not use, then check the Coverage panel again.
- Then optimise what remains. Developers should keep event handlers small, paint the visual change first, and break up long tasks with scheduler.yield(), in Chrome since version 129, with a setTimeout() fallback elsewhere.
The best general advice in optimizing event callbacks is to do as little work as possible in them.
Two Indian sites show what the work is worth. redBus debounced a scroll handler and stopped running an expensive state update on every keystroke in its search inputs; its case study says that input-field change improved the page's INP by 72%, and redBus reported a 7% overall increase in sales.
The Economic Times took its site-wide INP from about 1,000 ms to 257 ms, partly by lazy-loading third-party libraries, removing unused code and moving heavy work into web workers. Both are large businesses with in-house engineers, so expect the direction, not the exact numbers, to carry over. The business case is in what a slow website costs.
06
What to do this month
Give it one afternoon this month, then make it a habit.
- Run the four checks above on your home page, main service page and enquiry form, noting whether INP is reported for the page or the whole site.
- List every script and tag, who asked for it and what it does. Remove duplicates and anything without an owner.
- Once fixes are live, click Start Tracking on the issue in Search Console's Core Web Vitals report to begin its 28-day monitoring session.
- From then on, no new plugin, widget or tag goes live without a named owner and a retest on a throttled phone.
If you would like a second opinion on the results, Accendoz offers a free audit.
Sources
Figures current as of 3 July 2026.