Closed rviscomi closed 1 year ago
Makes sense to me.
Pasting a bit more context here from prior conversations:
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 https://github.com/GoogleChrome/web-vitals/issues/228
https://github.com/GoogleChrome/web-vitals/issues/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 :)
Looks to be resolved.
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