Guides

INP, short for Interaction to Next Paint, is one of Google's Core Web Vitals, the metrics Google uses to score how good a page feels to use. INP measures responsiveness: when you click, tap or press a key, how long does the page take to visibly respond? It became an official Core Web Vital on 12 March 2024, replacing the older First Input Delay (FID).

The name describes exactly what it measures. From the moment you interact, INP times how long it takes until the next frame is painted, that is, until you actually see something change on screen. A low INP means the page reacts almost instantly; a high INP means you tap a button and it feels stuck for a moment before anything happens.

Google's thresholds, measured at the 75th percentile of real user interactions, are straightforward. An INP of 200 milliseconds or less is Good. Between 200 and 500 milliseconds is Needs improvement. Above 500 milliseconds is Poor. The 75th-percentile part matters: your page has to be responsive for most interactions, not just on average.

FID, the metric INP replaced, only measured the delay before the browser could start processing your first interaction, the input delay, and only for that first one. That made it easy to pass while a page still felt sluggish. INP is stricter because it looks at interactions across the whole visit, and it measures the full duration: the input delay, the time your event handlers run, and the time to present the next frame.

In other words, FID asked how quickly the page could begin to respond, once. INP asks how quickly the page actually responds, every time. That is a much closer match to how responsiveness really feels to a user.

Almost all INP problems come from the main thread being busy. JavaScript runs on a single main thread, and while a long task is running, the browser cannot respond to a click or paint a new frame. The usual culprits are long-running JavaScript tasks, heavy event handlers that do too much work at once, large or complex DOM updates, and frameworks re-rendering more than they need to.

Fixing INP is mostly about not blocking the main thread. Break long tasks into smaller pieces and yield back to the browser between them so it can handle input. Move heavy, non-urgent work out of the interaction, for example with requestIdleCallback or a web worker. Keep event handlers light, debounce noisy events like input and scroll, and avoid forcing large synchronous layout or re-render work in direct response to a tap.

INP is best judged on field data, real users on real devices, which you can see in the Chrome User Experience Report and in Google Search Console's Core Web Vitals report. For debugging in the lab, the web-vitals JavaScript library, the Performance panel in Chrome DevTools, and Lighthouse all help you find the slow interactions. On this site, our web vitals checker lets you enter your measured values and see instantly whether they pass Google's thresholds.

It is worth being clear about scope. INP is about responsiveness only. It is one of three Core Web Vitals, alongside Largest Contentful Paint (loading) and Cumulative Layout Shift (visual stability). A page can load fast and still have a poor INP if its JavaScript locks up the main thread when people start interacting.

The bottom line: INP rewards pages that stay responsive throughout a visit, not just at the first tap. If your site ships a lot of JavaScript, INP is the Core Web Vital most likely to need attention, and the fix is almost always the same discipline: do less work on the main thread, and do it in smaller pieces.