Interaction to Next Paint (INP)
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.
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. 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.A note on how INP is calculated
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 is a good INP score? #
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? #
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.
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 #
- PageSpeed Insights.
- Chrome User Experience Report (CrUX).
- Via BigQuery in the CrUX dataset's
experimental.interaction_to_next_paint
table. - CrUX API via
experimental_interaction_to_next_paint
. - CrUX Dashboard.
- Via BigQuery in the CrUX dataset's
web-vitals
JavaScript library.
Lab tools #
- Lighthouse Panel in DevTools, available in "Timespan Mode".
- Lighthouse npm module.
- Lighthouse User Flows.
- Web Vitals extension for Chrome.
Measure INP In JavaScript #
- chrome 96, Supported 96
- firefox, Not supported ×
- edge 96, Supported 96
- safari, Not supported ×
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 #
A full guide on optimizing INP is available to guide you through the process of identifying slow interactions in the field and using lab data to drill down and optimize them.
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.