Adjust the INP duration threshold

[rviscomi]

INP currently shows as "waiting for input" even after interacting with the page, if the interaction latency is sufficiently small. As a result, we show data for FID, but not INP. This might throw people off, so look into lowering the reporting threshold for INP events in web-vitals.js.

We could lower the default threshold or let developers choose a threshold in the extension options to balance reporting with performance.

cc @philipwalton @mmocny

[mmocny]

Makes sense to me.

Pasting a bit more context here from prior conversations:

• We may be able to decide if its better to add a config option or just default to 16ms after this issue is resolved.
• Specifical to "FID shows and INP doesn't" I think it can happen even with 16ms durationThreshold. Maybe we should just address that issue directly. One idea Philip had was to just update web-vitals.js to expose the FID time data as the first INP score. We actually already do expose duration value for first-input and it looks like that includes times <16ms.

There could be value to doing both of the above, the the latter seems easier, more valuable, and less risky.

So, filed GoogleChrome/web-vitals#228

[mmocny]

GoogleChrome/web-vitals#228 is fixed and so now first input now always counts as an INP score.

There's more follow-up there chrome-side to change the reporting of FID, but I think if we just update the web-vitals library this issue will get a lot better.

I did also benchmark PO (this issue) and found that the there is no measurable overhead that I could find... but even adding something like a console.log can change to affect perf, and saving state from callbacks can affect things link GC. All that said, probably having DevTools perf panel open is a much larger effect on perf itself than this extension :)

[tunetheweb]

Looks to be resolved.