INP will observe the latency of all click, tap, and keyboard interactions that occur throughout the lifespan of a user's visit to a page. The final INP value is the longest interaction observed, ignoring outliers. But what does that mean?
A new responsiveness metric was introduced in december 2021. But as Google first wanted to collect data in the field, they didn't replace FID right away, but introduced a new one instead: Interaction to Next Paint. Unlike First Input Delay, INP will observe all interactions during a page life cycle and then report one of the numbers related to the highest delays to their CrUX data.
The need for INP
It is expected that INP will replace FID in the future. This would mean that INP would become part of the three Core Web Vitals. And this is why:
FID is not a good fit
Currently, 95% of almost 17 million origins are passing the FID threshold, while there are way more than the remaining 5% that are using a many Third Parties and JavaScript in general. In other words, only tracking the first interaction -as FID is doing- isn't sufficient to get an idea of the impact of JS in general. Hence, the need to track delays across multiple interactions within a lifespan of a page.
Google's documentation
After reading Google's documentation, some parts can still be challenging to grasp. For example, what is considered an outlier and is the lifespan of a page relevant?
About the lifespan of a page
Within their web.dev documentation, "throughout the lifespan of a user's visit to a page" is important. The lifespan of a page stops when a user navigates to another page. And then a new page life cycle begins and metrics will be reset. New numbers within the new page (lifespan) will be reported once again for that pagehit.
SPA's versus non-SPA's
The above hopefully makes sense. And typically applies to the average site, sometimes called Multi Page Applications (MPA). But it works a bit different for Single Page Applications (SPA). Page navigations within SPA's are soft navigations; browsers don't know that users navigated. So, the lifecycle doesn't stop according to the browser. Or data trackers in general. Google Analytics for example doesn't know that a new page was visited. As a developer (or SPA platform) you would have to submit a new pagehit programatically yourselves.
The way Google is tracking and collecting metrics works the same. Because Google's Core Web Vitals aren't able (yet) to differentiate hard navigations from soft navigations. And unlike Google Analytics, we can't call a specific function to notify the Core Web Vitals data about a new pagehit.
Longer lifespan's within SPA's
In other words, while clicking around within an SPA -that is typically built using React, Vue or Angular- means that the lifespan of a page doesn't stop and restart while navigating. A lifespan will be longer than within MPA's. Most likely as long as the whole session (unless a user would manually refresh the page).
However, as the lifespan is longer, more interactions will happen within that lifespan. Increasing the chance of capturing a higher INP as well. The same applies to online games, that can be played via the web. It's likely more interactions will happen.
INP ignoring outliers
As a result, Google's Web Vitals tracking method will ignore outliers in certain conditions. Google is saying the following about this:
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
web.dev/inp/
But what does this mean?
Being an SPA or online game, higher numbers and maybe even outliers (compared to overall numbers) could be reported by Google. And when INP becomes part of Core Web Vitals, it could even impact your SEO.
Preventing popular sites from being penalized
But would it be fair if your site would be penalized, just because it received more interactions for whatever reason? Not really, is Google's conclusion. So, for every 50 interactions, they will ignore the highest delay and then pick the next in line. That will be reported as part of your Core Web Vitals INP metric score.
98th instead of 100th percentile
This is where INP's percentile comes into play. Instead of looking at the highest number (so, 100th percentile number) within a few interactions, they might ignore the highest number within 50 interactions. That leaves 49 interactions to look at, so (49 * 2) the 98th percentile will be used.
Google used to have documentation on this, but it was removed from their articles. This could indicate that Google is still experimenting with which percentile to use in what situation.
Nevertheless, optimizing your site's pages and in the case of INP specifically JavaScript and render tasks is always a good idea from a user experience perspective. Regardless of the percentile they will be using.
