How to Improve INP: Fixing Interaction to Next Paint on a Real Website

Interaction to Next Paint (INP) measures how quickly a page responds when someone clicks, taps or presses a key. For each of those interactions, the browser records the time from the input until the next frame is painted. Hovering, scrolling and zooming are not measured. For most sites the interaction with the worst latency becomes the page's INP; on pages with many interactions, one of the highest is ignored for every 50 interactions so a single outlier does not decide the score.

Google's thresholds are applied to the 75th percentile of page loads in the field, split by mobile and desktop: 200 ms or less is good, above 200 ms up to 500 ms needs improvement, and above 500 ms is poor. INP is the successor to First Input Delay (FID) as the responsiveness Core Web Vital. FID only measured the delay before the first interaction's handlers started, which is why sites that passed FID easily can fail INP.

Google says it highly recommends achieving good Core Web Vitals for success with Search, and that Core Web Vitals, along with other page experience aspects, align with what its core ranking systems seek to reward. INP is one of the three Core Web Vitals, with Largest Contentful Paint and Cumulative Layout Shift. In practice, fixing INP will not lift a page that does not answer the query well, but a slow, unresponsive page works against both rankings and conversions.

The HTTP Archive Web Almanac 2025, based mainly on July 2025 measurements, found that 77% of websites had good INP on mobile, up from 74% in 2024, against 97% on desktop. Only 48% of websites had good Core Web Vitals overall on mobile and 56% on desktop. If your site fails, mobile is the place to look first.

INP is a field metric, so start with real-user data, not a lab score. A real user monitoring (RUM) tool gives the most context, because it can tell you which element was clicked, on which page, and how far the page had loaded at the time. Without RUM, PageSpeed Insights shows field data from the Chrome User Experience Report (CrUX), which tells you whether you pass but rarely which interaction is responsible.

Until recently, RUM data on INP came almost entirely from Chromium browsers. Safari 26.2, released in December 2025, added the Event Timing API, which WebKit says makes measuring INP possible. If a large share of your visitors use iPhones, update your monitoring and compare Safari with Chrome before deciding where the problem is. CrUX, and therefore the score Google reports, still reflects Chrome users.

Every interaction's latency is the sum of three parts. Input delay is the time from the user's input until event handlers start running, usually because the main thread is busy with something else. Processing duration is the time the event handlers take to run. Presentation delay is the time from the end of the handlers until the browser paints the next frame, which covers style calculation, layout and paint.

This split is the most useful decision in the whole process, because the fixes do not overlap. Rewriting a click handler does nothing if the real problem is a third-party script that was still evaluating when the user tapped. Note also that each iframe has its own main thread, so check which frame the interaction happened in.

A simple decision rule keeps the work focused. If input delay is the largest part, the problem is usually not the interaction itself but whatever else is running on the main thread, so the fix belongs in how scripts load. If processing duration is the largest, the fix belongs in your own event handlers and component code. If presentation delay is the largest, look at how much of the page changes after the interaction and how big the DOM is. When two phases are similar, fix the one that is cheapest to change first, measure again, and only then move on.

Once you know which phase dominates, the options narrow quickly. A long task is any task over 50 ms, and long tasks are behind most input delay and processing problems. Google's guidance for each phase comes down to the following.

The same patterns come up again and again on marketing sites and online stores. Treat this list as a set of hypotheses to check against your own field data, not as a diagnosis.

Many of these problems are added after launch rather than built in. A marketing team installs a new tag, a plugin adds a widget, or a product list grows from fifty items to two thousand. That is why INP should be owned by whoever approves changes to the live site, not only by the developers who built it.

A lab test can show that an interaction got faster, but the score that matters is the 75th percentile in the field. Watch the RUM data for the specific pages and interactions you changed, segmented by device. Field data has to accumulate from real visits, so expect PageSpeed Insights and Search Console to reflect a release only after some weeks.

Google's own advice is that the key to improving INP is persistence: fixing one slow interaction often reveals the next one. Add an INP budget to your release checklist, and re-check after adding any new third-party script, because that is the change most likely to undo the work.