what is it and why work with it
Since March 12, 2024, the FID (First Input Delay) indicator from the Core Web Vitals family has been replaced by a new metric – INP (Interaction to Next Paint), which reflects the response speed of sites. The need for such a replacement, among other things, is confirmed by data on the use of Chrome: according to them, the user spends 90% of the time on the page after it has loaded. Therefore, it is important to carefully measure site responsiveness throughout the page lifecycle. This is where the INP metric helps.
My name is Konovalov Ilya. I am a Performance Engineer and Front-end Developer at the medical company SberZdorovye. In this article I will tell you what INP is and how to work with the new metric.
A little history
Classically, a set of Core Web Vitals indicators proposed by Google is used to assess the quality and responsiveness of a website interface. Previously, the set included three main metrics:
LCP (Largest Contentful Paint) – loading speed of large content;
FID (First Input Delay) – time from first input to action;
CLS (Cumulative Layout Shift) – cumulative layout shift.
But since March 2024, FID has been replaced by a new metric – INP (Interaction to Next Paint), which displays the site’s response speed to user actions. For example, INP estimates how quickly the value next to the cart icon changes after adding a new product. In this case, INP does not take into account the time until the final response (in complex scenarios, full rendering takes a lot of time), but the time until the interface’s first reaction to a user action – that is, until the moment when the user can see that the site has not frozen and information is being processed.
Reference! INP was first introduced back in 2022. The metric was initially considered as a replacement for FID, as it provides more detailed and applied information. Thus, FID estimates the time from a click to the site’s response, but takes into account only the first contact, while INP estimates the response speed throughout the entire interaction with the site. Moreover, FID is more focused on assessing technical response speed, while INP is more focused on visual speed.
It is noteworthy that, according to Google, 93% of sites are optimized for the FID metric, but only 65% are optimized for INP, which makes such optimization a priority task for the near future.
INP calculation
INP takes into account actions with any interactive elements, regardless of their implementation – JavaScript, CSS, standard browser controls (for example, form elements), or a combination of these.
In fact, the INP metric is affected by speed:
JavaScript processing,
executing event handlers,
redrawing the DOM after changes,
redrawing styles,
rendering interaction results.
Three types of action are taken into account:
mouse click,
tap on the touch screen,
pressing keys on the on-screen or physical keyboard.
Notably, hover and scrolling are not taken into account.
When calculating, the metric takes into account the period from the user’s action to the visual display of the reaction to this action in the interface. At the same time, INP displays the average response time for all actions within one session on the page – for example, if the user clicked on the form 10 times, we will get the average INP value.
What’s important is that for every 50 interactions, INP allows the longest one to be cut. That is, if within one session the response to one of the actions is too long, it will not be taken into account so as not to affect the objectivity of the results.
INP indicators
The INP value can be used to evaluate the quality of a site in the context of responsiveness. So:
200 ms and below – the page has a good response speed;
from 200 to 500 ms – the response speed is average and needs optimization;
500 ms or more – poor page responsiveness.
An example of response predictability. On the right is good interactivity, in which the site immediately responds to user actions. On the left is poor interactivity, in which the result is not guaranteed.
To understand when a high INP can make itself known and what to do about it in real cases, let’s look at two examples.
Open the map on the website by clicking on the button. If we wait for the script to load and only then start rendering, we get a large INP. To prevent this, it is better to use standard asynchronous loading, without await. It is also important to let the user know that loading is taking place by adding a skeleton/loader/animation of the opening of the field in which the card should be located.
Large DOM tree. If a click causes large DOM trees to be redrawn (for example, in the case of opening a complex side menu with the entire layout shifted), it provokes a multiple increase in INP, which can become a problem. The key optimization methods in this case are asynchronous processing, preliminary data preparation, and also reducing the number of elements that must be changed. Skeletons/loaders are required.
Working with INP
By analyzing INP, you can track a number of typical problems:
excessive JavaScript execution time,
excessive number of changes to the DOM,
re-complication of styles,
insufficient network performance.
But it is important to consider that the result of INP measurements may depend on the type of device, network, measurement method (laboratory or not) and other factors. Therefore, it is important to understand how to measure INP and monitor the metric in the product.
For example, at SberHealth we use Page Speed Insights to measure INP. This is a tool in Google Chrome that automatically analyzes a page based on basic metrics, including INP – just drop a link to the page.
Page Speed Insights displays cumulative data collected from users over 28 days, if there is enough of it – to accumulate “historical data” it is important that the user systematically visits the site.
We use the CRUX API to collect user data, and then visualize it by page and device type, getting the target picture. To make it easier for businesses to understand the indicators, we turn abbreviations into human-readable indicators (for example, interface response time – INP) while preserving the original names in the tooltips.
This allows us to monitor user metrics collected by Google for evaluation over long periods of time (month, quarter, six months, year), assessing dynamics and comparing with major releases. This helps us improve delivery and development processes and test performance approaches.
But SberHealth has many pages and even page options: pages for doctors, clinics, doctors, services and others. Moreover, each of them has many components that change the page and the load on it. Therefore, we are not limited to the Page Speed Insights tool, but also work with the Web Vitals library – it is loaded on the client side and suspends certain handlers (in our case INP), which after the session give us the result of the average INP value. It is noteworthy that Web Vitals remains anonymous – it simply works with browser timing via the Navigation Timing API.
For the convenience of tracking and analyzing metrics, we send data from Web Vitals to Sentry – in our case, this is one of the main tools for assessing user performance with an explicit division into groups by device/browser/region and other metrics.
Thanks to this, it is easier for us to interpret the results: we can calculate internal indicators, allocate users into groups, analyze sessions, identify bottlenecks, build hypotheses, and so on.
In addition, we try to “link” INP to business indicators. To do this, we send data from Web Vitals to Metrika. This way we can track patterns and dependencies – for example, the impact of INP on user activity.
In our case, collecting and aggregating such data in Sentry and Metrika solves two problems at once.
Firstly, it allows us to interpret the metric taking into account the type of device, the percentage of “bad” INP and the adequacy of the data volume – for example, we see if high values are caused by users from specific devices or regions.
Secondly, we immediately see bottlenecks that we can improve. For example, disabling unnecessary JS and reducing the execution of required code, hosting content locally, caching resources, minimizing layout drift, and other practices can help improve INP.
Our automation solutions
To optimize site performance checking and reduce manual intervention, we try to automate processes as much as possible.
So, in order to interact with Google Lighthouse automatically, we wrote the Lighthouse Worker program, which allows you to:
run Headless Chrome browser on any virtual machine;
launch a tab with the required number of sessions;
collect data and derive medians and changes based on it – for example, how page parameters change depending on different user interaction scenarios.
That is, instead of manually simulating hundreds of user sessions, we can run this process automatically and quickly get results.
In addition, to automate work with Google PageSpeed Insights, we use a separate server, which accesses Google PageSpeed Insights via IP and sends it links for analysis (in our case, there are about a thousand such links). Next, the server receives a response with average indicators for 28 days and transmits the data to the Grafana platform, through which we monitor the status of the pages. It is important that we save all data in relation to the period. This gives us the opportunity to compare metrics after releases, optimizations, A/B tests and other manipulations: if the measurements after innovations are worse than before them, we can roll back the changes or quickly modify them.
What's the result?
Since March 2024, the INP indicator has influenced the ranking of sites, so it will not be possible to ignore the new realities – especially considering that, according to Google itself, only 65% of sites have a satisfactory INP metric.
In conditions when the new metric has already become the main one, it is better not to put off optimizing sites for it indefinitely – this will give you a chance not to sag in terms of indicators and not lose your position in the “eyes” of search robots.
INP optimization, like any other website improvement, is an almost continuous process. Therefore, you need to learn how to work correctly with metrics and improve them now. On March 28, I will speak at the SberHealth Frontend Meetup – I will share additional tips for working with INP that did not fit into the article. Connect to broadcasts at 19:00 – my front-tender colleagues and I will be happy to answer your questions after the performances!
