Interaction to Next Paint (INP)

explains how it works, how to measure it, and offers suggestions on how to improve it.

Browser Support

  • 96
  • 96
  • x
  • x


Interaction to Next Paint (INP) is a pending Core Web Vital metric that will replace First Input Delay (FID) on March 12, 2024. INP assesses responsiveness using data from the Event Timing API. INP observes the latency of all click, tap, and keyboard interactions with a page throughout its lifespan, and reports the longest duration, ignoring outliers. A low INP means the page is consistently able to respond quickly to the vast majority of user interactions.

Good responsiveness means a page responds quickly to interactions. When a page responds to an interaction, the browser presents visual feedback in the next frame it renders to show that the interaction was successful. For example, it can provide feedback on the following:

  • Whether an item you add to an online shopping cart is actually being added.
  • Whether a mobile navigation menu has opened.
  • Whether a login form's contents are being authenticated by the server.

Some interactions naturally take longer than others, but for especially complex interactions, it's important to quickly present some initial visual feedback to tell the user something is happening. The time until the next paint is the earliest opportunity to do this. Therefore, the intent of INP is to measure not all the eventual effects of the interaction (such as network fetches and UI updates from other asynchronous operations), but the time in which the next paint is blocked. By delaying visual feedback, you make users think the page isn't responding to their actions.

The goal of INP is minimize the time from when a user initiates an interaction until the next frame is painted, for all or most interactions the user initiates.

An example of poor versus good responsiveness. On the left, long tasks block the accordion from opening. This causes the user to click multiple times, thinking the experience is broken. When the main thread catches up, it processes the delayed inputs, resulting in the accordion opening and closing unexpectedly. On the right, a more responsive page opens the accordion quickly and without incident.
A note on how INP is calculated

INP is calculated by observing all the interactions made with a page. For most sites, the interaction with the worst latency is reported as INP. However, for pages with large numbers of interactions, random hiccups can result in an unusually high-latency interaction on an otherwise responsive site. The more interactions, the more likely this is to happen. To counter this, and give a better measure of the actual responsiveness for those types of pages, we ignore one highest interaction for every 50 interactions. Because the vast majority of page experiences don't have over 50 interactions, the browser almost always still reports the worst interaction. The 75th percentile of all page views is then reported as usual, which further removes outliers to give a value more representative of the general user experience.

An interaction is a group of event handlers that fire during the same logical user gesture. For example, "tap" interactions on a touchscreen device include multiple events, such as pointerup, pointerdown, and click. An interaction can be driven by JavaScript, CSS, built-in browser controls like form elements, or a combination of these things.

An interaction's latency consists of the single longest duration of a group of event handlers that drives the interaction, from the time the user begins the interaction to the moment the next frame is presented with visual feedback.

Key point: For more details on how INP is measured, see "What's in an interaction?".

What is a good INP score?

To ensure you're delivering user experiences with good responsiveness, a good threshold to measure is the 75th percentile of page loads recorded in the field, segmented across mobile and desktop devices:

  • An INP equal to or less than 200 milliseconds means your page has good responsiveness.
  • An INP between 200 milliseconds and 500 milliseconds means your page's responsiveness needs improvement.
  • An INP greater than 500 milliseconds means your page has poor responsiveness.
Good INP values are 200 milliseconds or less, poor values are greater than 500 milliseconds, and anything in between needs improvement.
Good INP values are 200 ms or less. Poor values are greater than 500 ms.

What's in an interaction?

A diagram depicting an interaction on the main thread. The user makes an input while blocking tasks run. The input is delayed until those tasks complete, after which the pointerup, mouseup, and click event handlers run, then rendering and painting work is kicked off until the next frame is presented.
The life of an interaction. An input delay lasts until event handlers start running, possibly caused by factors like long tasks on the main thread. The interaction's event handlers then run, and another delay happens before the next frame is presented.

The primary driver of interactivity is often JavaScript, though browsers do provide interactivity through controls not powered by JavaScript, such as checkboxes, radio buttons, and controls powered by CSS.

For the purposes of INP, only the following interaction types are observed:

  • Clicking with a mouse.
  • Tapping on a device with a touchscreen.
  • Pressing a key on either a physical or onscreen keyboard.

Key point: Hovering and scrolling does not factor into INP. However, scrolling with the keyboard (space bar, page up, page down, and so forth) involves a keystroke, which can trigger other events that INP does measure. Any resulting scrolling isn't factored into the INP calculation.

Interactions happen in the main document or in iframes embedded in the document—for example, clicking play on an embedded video. Because end users aren't aware of which parts of the page are in iframes, you need to measure INP within iframes to accurately measure it for the whole page. However, JavaScript Web APIs don't have access to the iframe contents, and might not be able to measure INP within an iframe. This shows as a difference between CrUX and RUM.

Interactions can consist of multiple events. For example, a keystroke includes the keydown, keypress, and keyup events, and tap interactions include pointerup and pointerdown events. The event with the longest duration within the interaction is chosen as the interaction's latency.

A depiction of more complex interaction containing two interactions. The first is a mousedown event, which produces a frame before the mouse button is let up, which kicks off more work until yet another frame is presented as the result.
When the user presses the mouse button to click, the browser handles the interaction and presents a frame of visual feedback. When the user releases the mouse button, another series of event handlers runs before the browser can present another frame.

INP is calculated when the user leaves the page, resulting in a single value representative of the page's overall responsiveness throughout its lifecycle. A low INP means that a page is reliably responsive to user input.

How is INP different from First Input Delay (FID)?

Where INP considers all page interactions, First Input Delay (FID) only accounts for the first interaction. It also measures only the first interaction's input delay, not the time it takes to run event handlers, or the delay in presenting the next frame.

Because FID is also a load responsiveness metric, we can use it to determine the page's first impression on the user based on input delay. INP instead measures all parts of all interactions throughout the page's lifecycle, making it a more reliable indicator of overall responsiveness than FID.

What if no INP value is reported?

It's possible for a page to return no INP value. This can happen for a number of reasons, including the following:

  • The page loaded, but the user never interacted with it.
  • The page loaded, but the user interacted with it using gestures that aren't measured, such as scrolling or hovering over elements.
  • The page is being accessed by a bot, such as a search crawler or headless browser, that hasn't been scripted to interact with the page.

How to measure INP

INP can be measured both in the field and in the lab using a variety of tools.

Key point: The best way to measure your website's INP is by gathering metrics from actual users in the field. If you're accustomed to relying on lab data for assessing performance, we recommend reading Why lab and field data can be different (and what to do about it).

In the field

Ideally, your journey toward optimizing INP starts with field data. At its best, field data from Real User Monitoring (RUM) gives you not only a page's INP value, but also contextual data that highlights what specific interaction was responsible for the INP value itself, whether the interaction occurred during or after page load, the type of interaction (click, keypress, or tap), and other valuable information.

If your website qualifies for inclusion in the Chrome User Experience Report (CrUX), you can quickly get INP field data through CrUX in PageSpeed Insights, alongside data on other Core Web Vitals. At a minimum, you can get an origin-level picture of your website's INP, but in some cases, you can also get page-level data.

However, while CrUX can tell you that there is a problem at a high level, it often doesn't provide enough detail to help fully understand what the problem is. A RUM solution can help you uncover more details about the pages, users, or user interactions that experience slow interactions. Being able to attribute INP to individual interactions helps avoid guesswork and wasted effort.

In the lab

Optimally, you'll want to start testing in the lab after you have field data that suggests you have slow interactions. In the absence of field data, however, there are some strategies for reproducing slow interactions in the lab. Strategies include following common user flows and testing interactions along the way, as well as interacting with the page during load, when the main thread is often busiest, in order to expose slow interactions during that crucial part of the user experience.

How to improve INP

See our collection of guides on optimizing INP for guidance on identifying slow interactions in the field and using lab data to optimize them.


Occasionally, bugs are discovered in the APIs used to measure metrics, and sometimes in the definitions of the metrics themselves. As a result, changes must sometimes be made, and these changes can show up as improvements or regressions in your internal reports and dashboards.

To help you manage this, all changes to either the implementation or definition of these metrics are surfaced in this Changelog.

If you have feedback for these metrics, provide it in the web-vitals-feedback Google group.