Recently Google launched a new Core Web Vital metric which will be integrated along with the remaining performance-related metrics shown with the page speed insights test of Google.
Check out > https://pagespeed.web.dev/
As you can see the INP metric is integrated with the pagespeed insights report.
As per Google’s Definition
“Interaction to Next Paint (INP) is an experimental field metric that assesses responsiveness. INP logs the latency of all interactions throughout the entire page lifecycle. The highest value of those interactions—or close to the highest for pages with many interactions—is recorded as the page’s INP. A low INP ensures that the page will be reliably responsive at all times.”
Google chrome is used by about 52% of all internet users. Hence as per Chrome’s user data, 90% of the user’s session time is spent after the page loads, hence scrutiny of website responsiveness is important as more website’s rely on Javascript for responsiveness.
Responsiveness is measured by Visual Feedback. Visual feedback is what tells us that “when a user clicks on a product” then that product is being added to the cart. The following example can help you differentiate between Good and Bad responsiveness.
Visual feedback for Responsiveness
Good responsiveness is critical to a good user experience. In this article, we’ll talk about how INP works and how to measure it.
How does INP Work?
Basically, INP measures the latency of how pages respond to a particular interaction, also called interaction latency.
For pages with less than 50 interactions, INP is the interaction with the worst latency. For pages with most interactions, INP is often in the 98th percentile.
“An interaction is a set of related input events that fire during the same logical user gesture. For example, “tap” interactions on a touchscreen.”
The total duration of interaction consists of the following components.
- The input delay is the time between when the user interacts with the page, and when event handlers execute.
- The processing time is the total amount of time it takes to execute code in associated event handlers.
- The presentation delay is the time between when event handlers have finished executing, and when the browser presents the next frame.
What is an interaction?
When we are considering INP value, and interaction consists of the following:
- Clicking on an interactive element with a mouse.
- Tapping on an interactive element on a device with a touchscreen.
- Pressing a key on either a physical or onscreen keyboard.
Similar to CLS web vital, the INP metric is measured at the end of a user’s session, i.e, when a user leaves the page. This returns a single value which represents the overall responsiveness of the entire web page lifecycle. This is because as per Google
“If high percentile page interactions are responded to quickly, that means that interactions at all lower percentiles are fast as well.”
So what’s a good INP Value?
- 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.
When does the Worst Interaction Latency not Considered?
While for many websites whose number of interactions is low, measuring the worst interaction latency might suffice. However, there are other websites which might have a high number of interactions. For example gaming websites.
In these cases measuring the worst latency might be misleading as all websites with heavy interaction, face hiccups, even if they are optimized to be responsive. Hence in these cases, measuring the worst latency may give us the wrong data. These so-called failed or high latency interactions due to server issues must be ignored.
In a nutshell, by focusing on a high percentile of interactions, it can be fairly examined whether the website responds to a vast majority of interactions in a timely fashion.
How is INP different from First Input Delay(FID)?
Interaction to Next Paint | First Input Delay |
INP considers all Page interaction | FID only reports the first interaction. It also only measures the input delay, not the processing time of event handlers, or the delay in presenting the next frame. |
INP is more than about first impressions. It covers the entire spectrum of interactions that can occur from the time the page begins loading to the time the user leaves the page. By sampling all interactions, responsiveness can be assessed comprehensively. This makes INP a more reliable indicator of responsiveness than FID. | The idea behind FID is that during the page loading phase if there is little to no input delay then the page has made a good first impression. |
What happens if the Users never interacted with a Webpage?
Sometimes a page is loaded but no interaction happens. This occurs when:
- User bounced from the page.
- User navigated through the page but didn’t click on any button
- The page is being accessed by a bot.
How to Measure Lighthouse
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.
- 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
INP can also be measured using Node.js code.
Enter the following in the Terminal Window of the Node.js editor.
npm install web-vitals@next –save
We can get the INP value by running the following code.
import {onINP} from ‘web-vitals’;
onINP(({value}) => {
// Log the value to the console, or send it to your analytics provider.
console.log(value);
});
So How do I improve INP?
INP can be improved in two stages:
- Improve INP during page startup.
- Improve INP after page startup.
Improve INP during Page Startup
- 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 out of the browser rendering after your JavaScript is done—that is, large component tree re-rendering, large image decodes, too many heavy css effects, and so on.
Improve INP after Page StartUp
- 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.