Interaction to Next Paint (INP)

— Updated
Appears in: Metrics
Jeremy Wagner
Jeremy Wagner
TwitterGitHubHomepage
On this page

Chrome usage data shows that 90% of a user's time on a page is spent after it loads, Thus, careful measurement of responsiveness throughout the page lifecycle is important. This is what the INP metric assesses.

Good responsiveness means that a page responds quickly to interactions made with it. When a page responds to an interaction, the result is visual feedback, which is presented by the browser in the next frame the browser presents. Visual feedback tells you if, for example, an item you add to an online shopping cart is indeed being added, whether a mobile navigation menu has opened, if a login form's contents are being authenticated by the server, and so forth.

Some interactions will naturally take longer than others, but for especially complex interactions, it's important to quickly present some initial visual feedback as a cue to the user that something is happening. The time until the next paint is the earliest opportunity to do this. Therefore, the intent of INP is not to measure 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 being blocked. By delaying visual feedback, you may be giving users the impression that the page is not responding to their actions.

The goal of INP is to ensure the time from when a user initiates an interaction until the next frame is painted is as short as possible, for all or most interactions the user makes.

In the following video, the example on the right gives immediate visual feedback that an accordion is opening. It also demonstrates how poor responsiveness can cause multiple unintended responses to input because the user thinks the experience is broken.

An example of poor versus good responsiveness. At 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.

This article explains how INP works, how to measure it, and offers advice for improving it.

What is INP? #

INP aims to represent a page's overall responsiveness by measuring all click, tap, and keyboard interactions made with a page. The longest of those observed interactions—with some exceptions noted below—is chosen as the page's INP value when the user is done with the page.

A note on how INP is calculated

As stated above, INP is calculated by observing all the interactions made with a page. The chosen value is then a percentile of those interactions. A formula is then used to choose a high percentile value of those interactions. For pages with few interactions, the interaction with the worst latency (the 100th percentile) is chosen. For pages with many interactions, the 99th or 98th percentile is chosen.

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 (such as form elements), or a combination thereof.

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.

What's a "good" INP value? #

Pinning labels such as "good" or "poor" on a responsiveness metric is difficult. On one hand, you want to encourage development practices that prioritize good responsiveness. On the other hand, you must account for the fact that there's considerable variability in the capabilities of devices people use to set achievable development expectations.

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 below or at 200 milliseconds means that your page has good responsiveness.
  • An INP above 200 milliseconds and below or at 500 milliseconds means that your page's responsiveness needs improvement.
  • An INP above 500 milliseconds means that your page has poor responsiveness.

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 occurs until event handlers begin running, which may be caused by factors such as long tasks on the main thread. The interaction's event handlers then run, and a delay occurs 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.

As far as INP goes, 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.

Interactions happen in the main document or in iframes embedded in the document—for example clicking play on an embedded video. End users will not be aware what is in an iframe or not. Therefore, INP within iframes are needed to measure the user experience for the top level page. Note JavaScript Web APIs will not have access to the iframe contents so may not be able to measure INP within an iframe and this will show as a difference between CrUX and RUM.

Interactions may consist of two parts, each with multiple events. For example, a keystroke consists of the keydown, keypress, and keyup events. Tap interactions contain 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.
A depiction of an interaction with multiple event handlers. The first part of the interaction receives an input when the user clicks down on a mouse button. However, before they release the mouse button, a frame is presented. When the user releases the mouse button, another series of event handlers must run before the next frame is presented.

INP is calculated when the user leaves the page, resulting in a single value that is representative of the page's overall responsiveness throughout the entire page's 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 only measures the first interaction's input delay, not the time it takes to run event handlers, or the delay in presenting the next frame.

Given that FID is also a load responsiveness metric, the rationale behind it is that if the first interaction made with a page in the loading phase has little to no perceptible input delay, the page has made a good first impression.

INP is more than about first impressions. By sampling all interactions, responsiveness can be assessed comprehensively, making INP a more reliable indicator of overall responsiveness than FID.

What if no INP value is reported? #

It's possible that a page can return no INP value. This can happen for a number of reasons:

  • The page was loaded, but the user never clicked, tapped, or pressed a key on their keyboard.
  • The page was loaded, but the user interacted with the page using gestures that did not involve clicking, tapping, or using the keyboard. For example, scrolling or hovering over elements does not factor into how INP is calculated.
  • The page is being accessed by a bot such as a search crawler or headless browser that has not been scripted to interact with the page.

How to measure INP #

INP can be measured both in the field and in the lab (with some effort) through a variety of tools.

Field tools #

Lab tools #

Measure INP In JavaScript #

Browser support: 96 × 96 × Source

Writing your own PerformanceObserver to measure INP can be difficult. To measure INP in JavaScript, it's advised that you use the web-vitals JavaScript library, which exports an onINP function to do this work for you. You can then get a page's INP by passing a function to the onINP method:

import {onINP} from 'web-vitals';

onINP(({value}) => {
  // Log the value to the console, or send it to your analytics provider.
  console.log(value);
});

As with other methods exported by web-vitals, onINP accepts a function as an argument, and will pass metric data to the function you give it. From there, you can send that data to an endpoint for collection and analysis.

See the onINP() reference documentation for additional usage instructions.

How to improve INP #

If your website is reporting INP values that fall outside of the "good" threshold, you'll naturally want to figure out what you can do to improve. High INP values are usually indicative of a high reliance on JavaScript, or other non-JavaScript main thread work that may run concurrently with user interactions.

Improving INP during page startup #

INP can be a factor during page load, because users may attempt to interact with a page as it's fetching JavaScript to set up event handlers that provide the interactivity required for a page to work.

To improve responsiveness during page load, look into the following solutions:

  • Remove unused code using the coverage tool in Chrome's DevTools.
  • Find code-splitting opportunities so you can lazy load JavaScript not needed during page load. The coverage tool can help with this.
  • Identify slow third-party JavaScript that you may be loading during startup.
  • Use the performance profiler to find long tasks that you can optimize.
  • Ensure you aren’t asking too much of the browser in terms of rendering work during startup. Avoid large component tree re-rendering, huge DOM sizes, large image decodes, computationally expensive CSS animations, and so forth.

Improving INP after page startup #

Because INP is calculated from inputs sampled during the entire page lifecycle, it's probable that your site's INP could be influenced by what happens after page startup. If that's the case for your website, here are a few areas to look into for solutions:

CHANGELOG #

No changes have occurred to this metric since it has shipped. If changes occur, they will be noted in this CHANGELOG. If you have feedback for this metric, you can provide it in the web-vitals-feedback Google group.

Last updated: — Improve article
Return to all articles
Share