INP duration reported less than 40 milliseconds with entry type first-input

[darlinge]

The section in the README for the onINP() function states that a "custom durationThreshold configuration option can optionally be passed to control what event-timing entries are considered for INP reporting. The default threshold is 40, which means INP scores of less than 40 are reported as 0."

The comment on the Performance Observer in the source code states that "This threshold is chosen to strike a balance between usefulness and performance. Running this callback for any interaction that spans just one or two frames is likely not worth the insight that could be gained."

Further down a second Performance Observer is set for "first-input" with the comment to "Also observe entries of type first-input. This is useful in cases where the first interaction is less than the durationThreshold." This Performance Observer for "first-input" does not pass a value for durationThreshold.

I'm observing many cases where the web-vitals library reports an INP duration less than 40 milliseconds, with the entry type of "first-input" as in the following example.

The Chrome DevTools Performance Panel also reports the INP duration of less than 40ms.

Based on the source code this appears to be intentional from the "first-input" Performance Observer, but the comments on the README suggest that values below 40 milliseconds should be treated as zeroes.

For clarification I'm wondering if INP values less than 40 milliseconds should even be reported by the web-vitals library?
Or should we be filtering out any INP values less than 40 milliseconds once we have captured the INP data?

[tunetheweb]

We do expose first-input entries (which as you say has no threshold) as part of #228 as we got reports of it being weird to have a FID value but no INP just because of the threshold.

[tunetheweb]

And further comments (shared offline):

The goal of reporting even fast interactions (using first-input is just a detail), is to ensure that you report an INP score for all pages which have at least 1 interaction, even if the score is good.

If you didn't do that, you would have fewer reported INP scores in total. These really fast page loads would be hidden from your data, and so you might have have skewed histograms.

Let me share one anecdote: one popular Google product a few years ago chose to only report slow interactions, and the component event target. The data showed that a very critical user interaction was often surprisingly slow. Until we realized we weren't reporting fast interactions, so only observed rare events. When we reported all interactions (at least counts), we found that it was only slow a very tiny fraction of the time. But because other parts of the UI are used less often, even when they were slow more often when used, the raw number of slow field samples was misleading.

There really are a few distinct cases:

• A page visit didn't have any interactions at all. You might assume 0ms score, or just omit/segment these from data.
• A page visit had interactions, but they were all fast.
• A page visit had interactions, and some were slow.

I'm sure you can make alternative decisions in your own reporting, but remember that INP is meant to be the p75 value of the reported data, including the fast values.