INP (Interaction to Next Paint) is the Core Web Vital that measures how quickly a page visibly responds when someone clicks, taps or types, and it replaced First Input Delay on 12 March 2024. Google rates an INP of 200 milliseconds or less as good and anything above 500 milliseconds as poor, judged at the 75th percentile of real Chrome visits. To fix it, find the slow interaction in field data first, reproduce it in Chrome DevTools, work out which of its three phases is slow, and apply the fix for that phase rather than a general speed clean-up.
Definitions, thresholds and browser support below were checked against the linked Google and HTTP Archive pages on 13 September 2026; support for newer APIs changes with each browser release.
Key takeaways
- INP observes every click, tap and key press during a visit and usually reports the slowest one; scrolling, hovering and zooming are ignored.
- FID only timed the delay before the first interaction started, so a site could pass FID while its filters, menus and forms still felt sticky.
- CrUX and Search Console can tell you that INP is poor, but only real user monitoring with attribution tells you which element and which script caused it.
- In the 2025 Web Almanac, 80% of mobile home pages had good INP but only 69% of secondary pages did, so test the inner pages where people filter, book and submit.
What INP measures that FID missed
According to web.dev’s INP documentation (last updated 2 September 2025), an interaction’s latency runs from the moment the user acts until the browser can paint the next frame. INP does not wait for a network request to finish. It measures how long the next paint was blocked.
FID measured something much narrower. It timed only the input delay of the first interaction on a page, and it stopped counting the moment event handlers began to run. A property listing page could load, accept the first tap within a few milliseconds, then freeze for 600 milliseconds while a JavaScript filter re-rendered 300 cards. FID called that page fast. INP does not.
The Chrome team introduced INP as an experimental metric in May 2022 and, as announced on web.dev, promoted it to a stable Core Web Vital on 12 March 2024. FID was removed from Search Console that day, and other tools such as PageSpeed Insights and CrUX gave a six-month deprecation period.
On pages with many interactions, web.dev says one highest interaction is ignored for every 50, so one random hiccup does not define the score. A page can also return no INP value at all if visitors only scroll.
How Google turns INP into a pass or fail
The thresholds are fixed. At or below 200 milliseconds is good, above 200 and up to 500 milliseconds needs improvement, and above 500 milliseconds is poor. The score that counts is the 75th percentile of page loads, segmented into mobile and desktop, so a fast office laptop in DIFC does not cancel out a slower phone on mobile data.
The data comes from the Chrome User Experience Report. CrUX collects field data from Chrome users who have opted into sending usage statistics, and a page must be publicly discoverable to be included. The Search Console Core Web Vitals report groups similar URLs together and shows the group’s INP as the value 75% of page requests met or beat “in the last 28 days”. A URL group’s overall status is its worst metric, so good LCP and good CLS do not rescue a group with poor INP.
Does it affect rankings? Google’s page experience documentation states that “Core Web Vitals are used by our ranking systems” and in the same answer warns that good scores do not guarantee top rankings. Our reading: INP will not lift thin content, but a sticky enquiry form costs leads whatever it does to rankings.
Find the slow interaction in field data first
Start with PageSpeed Insights. Enter the URL, switch between the mobile and desktop tabs, and read the field data block at the top, not the Lighthouse score below it. If the page has enough traffic you get URL-level INP; if not, you may only get origin-level data for the whole domain. Then check which URL groups Search Console’s Core Web Vitals report flags, since the group points to the template to investigate.
CrUX stops there. It says a problem exists but not what causes it. For the cause you need your own real user monitoring, and the cheapest route is Google’s open-source web-vitals JavaScript library. Its attribution build reports, for the interaction that set the page’s INP:
- interactionTarget, a CSS selector for the element the user touched, such as button#save
- interactionType, which tells you whether it was a click, tap or key press
- inputDelay, processingDuration and presentationDelay, the three phases in milliseconds
- longAnimationFrameEntries, data from the Long Animation Frames API including the script URL and function name that ran during the slow frame
Send those fields to your analytics endpoint or to GA4 as event parameters, and after a week you can rank selectors by how often they set the page’s INP. The script URL in the long animation frame data separates your own code from a third-party tag. According to web.dev’s field data guide, that script attribution comes from the Long Animation Frames API, which shipped in Chrome 123, so it is Chromium-only data.
Reproduce it in Chrome DevTools
Once you know which interaction to chase, open the page in Chrome, open DevTools and go to the Performance panel. The live metrics view shows INP as you click around and logs each interaction with its phase breakdown. For the detail, record a trace: press Record, perform the interaction, stop, and find it in the Interactions track.
Hovering over the interaction shows the split. The left whisker is input delay, the solid block is processing duration, and the right whisker is presentation delay. web.dev’s lab diagnosis guide notes that the striped part of the bar marks the time beyond the 200 millisecond good threshold, which makes the size of the problem obvious at a glance.
A recent MacBook will often make a poor interaction look fine. Turn on CPU throttling in the Performance panel, or connect a mid-range Android phone over USB and use remote debugging. If you have no field data at all, check Total Blocking Time in Lighthouse; web.dev describes TBT as a lab metric that correlates well with INP, although it only covers the loading period and is not a substitute.
The three phases and the fix that matches each
| Phase | What is happening | Common causes | First fix to try |
|---|---|---|---|
| Input delay | The tap has arrived but the main thread is busy with something else | Script evaluation during load, third-party timers, overlapping interactions | Reduce and defer JavaScript that runs at startup; delay non-critical tags |
| Processing duration | Your event handlers are running | Heavy click handlers, synchronous analytics calls, framework re-renders | Do the visual update first, then yield to the main thread |
| Presentation delay | Handlers are done; the browser is calculating style, layout and paint | Large DOM, forced reflows, expensive requestAnimationFrame or ResizeObserver work | Shrink the DOM, batch reads and writes, use content-visibility |
When input delay is the problem
A task longer than 50 milliseconds is a long task, per web.dev’s long tasks guide, and a click handler cannot start until the running task ends. If the attribution data shows invoker types of classic-script or module-script, script evaluation during load is blocking the tap. Split bundles, defer scripts the first screen does not need, and move tags to a later trigger.
When processing duration is the problem
Do as little work as possible inside the handler: update the part of the interface the user is waiting for, then yield so the browser can paint before the rest runs. Web.dev’s example is a text editor that updates the text box immediately and pushes word counting, spell checking and saving into a later task with setTimeout inside a requestAnimationFrame callback, which works in all browsers.
The newer option is scheduler.yield(). Chrome’s March 2025 article on the API explains its advantage: the rest of your function resumes ahead of other queued tasks, including those queued by third-party scripts, instead of waiting behind them. On 13 September 2026, web.dev’s support table listed it for Chrome and Edge 129 and Firefox 142, with no Safari support shown, so feature-detect it and fall back to setTimeout. React sites can mark non-urgent state updates with useTransition, which React documents as non-blocking, although it cannot be used to control text inputs.
When presentation delay is the problem
Web.dev’s lab guide says presentation delays can be the most difficult cause to troubleshoot and fix. Its companion DOM size guide notes that Lighthouse warns once a page passes 800 DOM nodes and treats more than 1,400 as excessive. Mega menus with every service rendered on every page, page-builder sections nested six wrappers deep and long FAQ accordions all push that number up. Also look for forced reflows, where code changes a style and immediately reads a layout property such as offsetHeight. The CSS content-visibility property lets the browser skip rendering work for off-screen sections both on load and after an interaction.
Patterns that break INP on Dubai business websites
These are practitioner observations, not statistics: the causes we find most often when tracing slow interactions on UAE service and e-commerce sites.
The first is the marketing stack. A lead-generation site may run Google Tag Manager with the Meta Pixel, Google Ads conversion tags, a TikTok pixel, a heatmap tool and a consent banner, and many of those listen for clicks. When a visitor taps “Get a quote”, those listeners run before the button can visibly respond, and one issue we often see is a conversion tag doing synchronous work inside the click. The attribution data exposes it because the script URL points to the tag’s domain.
The second is chat and WhatsApp widgets. Clinics, brokers and business setup firms often add a floating chat button, and some widgets load large bundles at page load for a tap that may never come. Loading the widget after the first scroll, or on tap, takes it out of the input delay.
The third is client-side filtering. A broker’s listings page or a store’s category page that re-renders the whole grid on every checkbox change can fail INP on mid-range phones even when the page loads quickly. Update the checkbox first, then yield before the grid re-renders. Arabic and English language toggles that rebuild the page in JavaScript rather than linking to a separate URL carry the same risk, and a separate URL is usually better for Arabic SEO anyway.
Why your inner pages matter more than your home page
The 2025 Web Almanac performance chapter, based on July 2025 CrUX data, found that 97% of websites had good INP on desktop against 77% on phones, up from 74% on phones in 2024. The more useful finding is the split by page type: 80% of mobile home pages had good INP, but only 69% of secondary pages did. The Almanac suggests secondary pages carry more filters, carousels, form validation and third-party widgets that activate deeper into a visit.
The booking page, the product filter and the multi-step enquiry form are where visitors tap repeatedly, and they rarely get the attention the home page does. The same chapter reports median mobile Total Blocking Time rising to 1,916 milliseconds in 2025 from 1,209 in 2024, so pages are carrying more JavaScript, not less. If your team only tests the home page, it is testing the page type that data shows is least likely to fail.
A fix order that does not waste a sprint
- Pull INP for mobile from PageSpeed Insights and Search Console, and list the URL groups rated needs improvement or poor.
- Add the web-vitals attribution build and collect at least a week of data, recording the selector, the three phases and the long animation frame script URL.
- Rank interactions by how often they set the page’s INP, not by how bad the single worst one looked.
- Reproduce the top interaction in DevTools with CPU throttling on, and confirm which phase dominates.
- Apply the phase-specific fix, starting with removing or deferring work rather than rewriting it.
- Deploy, watch your own RUM data, and once it looks healthy use Start Tracking on the issue in the Search Console report, which works from a 28-day window.
Replatforming is rarely the first answer. A WordPress site with a heavy page builder can often reach good INP by trimming plugins and deferring tags, and a Next.js rebuild that ships the same tags and the same client-side filtering will fail the same way. If a rebuild is on the table for other reasons, make INP an acceptance criterion in the development contract, with a mobile target, the pages it applies to and the tool that measures it.
