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 interactions, the changes in the user interface that result are visual feedback provided in the next frame the browser presents. Visual feedback tells us if, for example, an item we've asked to add to an online shopping cart is indeed being added, if a login form's contents are being authenticated by the server, whether a mobile menu has opened, and so on.
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'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? #
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 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 #
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. At the moment, getting INP data is only possible in version 3 of web-vitals
, currently in beta, which can be installed with the following command:
npm install web-vitals@next --save
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:
- Use the
postTask
API to appropriately prioritize tasks. - Schedule non-essential work when the browser is idle with
requestIdleCallback
. - Use the performance profiler to assess discrete interactions (for example, toggling a mobile navigation menu) and find long tasks to optimize.
- Audit third-party JavaScript in your website to see if it's affecting page responsiveness.
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.