I have collected a lot of INP data. However, I found a very weird situation that the element in the report doesn't even existed when the report was sent.
I use a very simple way to prove this:
Log the element's status with the report. For instance:
document.getElementById('logged element selector');
and it returns null (and yes, in my product, I removed that button after the user clicks it).
I also logged the time. It was some times 30-60 seconds later after the element was removed.
So, is the web vitals js library trigger an INP event later than its actual happening time?
My web vitals js sdk version: 3.5.2
Yes it does report it later for two reasons:
First up web-vitals.js use PerformanceObservers which emit their events (usually shortly) after the events happen.
More importantly, web-vitals.js tries its best to report only the final value for each of the Core Web Vitals.
As the INP event is the longest one, a later, longer, interaction can become the INP event. For this reason web-vitals.js waits until the user navigates away from the page before emitting the “final” INP event (note it also does it when you background the tab as, in this case, it may never be foregrounded again so this is the last guaranteed time to send it - this can lead to INP being reported multiple times if it is foregrounded again and a higher INP interaction happens).
You can control the latter by using the reportAllChanges which will report each larger INP event as soon as it becomes the largest INP event rather than waiting. Note it only reports changes to the largest INP—it doesn’t report ALL interactions, just each time a larger one is emitted and overtakes the previous largest to become the largest INP interaction.
You cannot control the former as it’s just the way PeformanceObservers work.
Both of these can mean the target is reported after having been removed from the DOM. Which also mean the browser is unable to list the target because it needs it to be in the DOM to be reported.