Interaction to Next Paint replaced First Input Delay as the responsiveness metric in Google's Core Web Vitals framework in March 2024, and the diagnostic challenge for most development teams is that the two metrics measure fundamentally different things. FID recorded only the input delay before the browser began processing the first interaction on a page. INP measures the full time from any interaction, a click, tap, or keypress, to the next visual update, and it does so for every interaction across the page lifecycle, not just the first. The distinction matters because FID could be gamed with a small optimisation on initial load; INP reflects the real interactivity of the whole page and is far harder to pass on JavaScript-heavy sites.
As of early 2026, INP is the most commonly failed Core Web Vital. CrUX data shows 43% of sites globally still failing the 200ms threshold, against 32% failing LCP and 19% failing CLS. For UK sites with significant JavaScript-rendered content, particularly those on React, Vue, or WordPress with heavy Gutenberg templates, INP is the most actionable Core Web Vitals improvement available. Understanding what the browser is actually doing during a poor interaction makes the fixes clearer than any checklist.
What the browser is doing during a poor INP interaction
The browser's main thread handles JavaScript execution, DOM manipulation, layout recalculation, and rendering. When a user clicks a button, the browser must complete three sequential tasks before the visual update appears: process the event handler, recalculate the layout if the handler modifies the DOM, and paint the updated pixels. INP measures the total time from interaction start to the next frame paint.
A poor INP score means one or more of these steps is blocking the main thread for too long. The most common cause is a long task: a JavaScript block that runs more than 50ms on the main thread, preventing the browser from responding to input during that block. Long tasks are the mechanism behind the "the page looks loaded but nothing happens when I click" experience that makes a site feel broken even when it looks visually complete.
The Chrome DevTools Performance panel, opened via F12 > Performance > Record, gives the most accurate long-task diagnosis. Record while interacting with the elements that generate your worst INP scores from the Chrome User Experience Report. In the timeline, long tasks appear as red-flagged blocks in the Main thread row. Click one to see its breakdown, script evaluation, function calls, DOM operations, and the specific script and function responsible appears in the Summary panel. That is your starting point, not a generic "reduce JavaScript" instruction.
Fun fact: INP's adoption as a Core Web Vital was informed by Web Performance Working Group research showing interaction latency correlated more strongly with engagement and session abandonment than First Input Delay, which could show a "Good" score on pages where users found interactions unresponsive after the initial load.
The three INP optimisation patterns with the highest impact
The first and most impactful pattern is task chunking. If a long task in the DevTools recording is a single function doing multiple operations, break it into smaller asynchronous units with yield points. The Scheduler API, available in Chrome and supported through the scheduler.yield() method, provides a direct mechanism: call await scheduler.yield() at strategic points to hand control back to the browser between chunks, letting it process pending input before continuing. For WordPress sites using Gutenberg blocks with complex editor interactions, applying this to block registration and validation logic is the most reliable INP win available short of an architecture change.
The second pattern is deferring non-critical JavaScript. Scripts not required for the interaction the user is performing at the moment of measurement are occupying main-thread time for no reason. Review the long tasks in the recording and find any analytics initialisation, third-party chat widget, or social share script running during the interaction window. Loading these with the defer attribute, or moving them to a requestIdleCallback triggered only during idle time, removes them from the critical INP path. Strip a 180ms analytics initialisation off the main thread during a click and you reduce INP by that amount directly.
The third pattern applies to sites that update the DOM extensively in response to interactions. Minimising DOM complexity reduces the time the browser needs to recalculate layout after a handler runs. The DOM size report in Lighthouse (PageSpeed Insights > View Report > DOM Size) flags pages above 1,400 nodes as potentially problematic. For INP specifically, node count matters most in the section of the DOM that changes in response to the interaction; a 10,000-node document does not degrade INP if the interaction only touches a 50-node subtree. INP sits inside the wider Core Web Vitals framework, and it is one of the first things we check in a technical SEO audit.
How to find your worst INP pages using Google Search Console
Go to Google Search Console > Experience > Core Web Vitals > Mobile. The report groups URLs by template and classifies each group as Good, Needs Improvement, or Poor based on field data from the Chrome User Experience Report. The groups in the Poor classification for INP, filtered to mobile (the ranking signal), are the starting point. Click through to a specific URL group and note the representative URL Google has identified for that template.
Run PageSpeed Insights on that URL. In Diagnostics, filter to "Avoid long main-thread tasks". This lists all long tasks with their duration and, where attributable, their source script. Cross-reference the top three with the Chrome DevTools Performance panel recording on the same URL to confirm the tasks occur during actual interactions rather than only during initial load. INP improvements that reduce main-thread execution during page load but not during interaction will not move the CrUX field score, because CrUX measures interaction latency from real users, not Lighthouse lab data.
Cross-browser INP and the December 2025 milestone
December 2025 delivered a significant infrastructure milestone for INP measurement: Firefox 144 and Safari 26.2 both added INP support through the Interop 2025 initiative, making INP a Baseline Newly Available metric across all major browsers. For teams using Real User Monitoring tools such as Cloudflare Web Analytics, Sentry Performance, or custom performance.eventTiming implementations, INP data can now be collected from Firefox and Safari users as well as Chrome. The Chrome User Experience Report, which drives Google's ranking signal, still uses Chrome field data only, but the cross-browser picture is more complete.
The practical implication: if your RUM data shows materially worse INP in Chrome than in Firefox or Safari, the cause is likely Chrome-specific rendering or extension behaviour rather than a universal JavaScript problem. If INP is poor across all browsers in RUM data, the long task is in your application logic rather than browser-specific execution, and the optimisation applies universally. This is exactly the kind of performance work our web apps and PWA team handles when responsiveness becomes a conversion problem.
Open the Performance panel and find the longest task first
Start with the Core Web Vitals report, mobile view. Identify the URL group with the highest volume of Poor INP classification. Open the Chrome DevTools Performance panel on a representative URL from that group. Record a session that includes the interactions your users perform most, menu navigation, form input, accordion toggles. Find the longest task in the Main thread timeline. Trace its source in the Summary panel. That specific function, in that specific script, is where optimisation begins.
The sites that improve INP most effectively are not the ones applying the broadest set of recommendations; they are the ones that identify the single dominant long task and resolve it precisely. A 240ms INP score traced to a specific analytics event handler initialising during a click can drop to 90ms by deferring that initialisation to requestIdleCallback, without touching any other part of the page architecture. INP is not a general performance problem. It is a specific main-thread scheduling problem, and the Performance panel is the tool that turns a poor PageSpeed score into a function call you can fix in an afternoon.
If a slow, unresponsive front end is costing you rankings and conversions, our website design and development team builds fast, INP-friendly sites from the ground up. Book a performance review through our contact page.
Related reading: How to run a technical SEO audit that fixes rankings and Screaming Frog vs Sitebulb for technical SEO audits.