Finish adding getINP() #221
Conversation
src/getINP.ts
Outdated
| if (existingInteractionIndex >= 0) { | ||
| const interaction = longestInteractions[existingInteractionIndex]; | ||
| interaction.latency = Math.max(interaction.latency, entry.duration); | ||
| interaction.entries.push(entry); |
There was a problem hiding this comment.
Will these be sorted by duration ever?
I think we have sample code that uses .entries[0] and performance.measure, as a simple way to visualize the latency on timeline, for example.
There was a problem hiding this comment.
That was an open question I had (what to sort them by). I think (?) we want to keep them in the order they were dispatched and leave any sorting up to the debug code, but let me know if you disagree and think it's important to have the largest duration first.
There was a problem hiding this comment.
Alright, fair enough.
While I think making the first entry the largest would be reasonable given the current implementation -- my ultimate preference is to report all entries that present the same frame such that we can create a summary of where time was spent overall. (Or even just report the summary as part of the Metric return value).
So leaving it up to debug code sgtm.
There was a problem hiding this comment.
I very much agree with that ultimate goal. Let's keep it simple for now and re-evaluate once we have more options there or when we plan to release this as stable.
| } | ||
| const handleEntries = (entries: Metric['entries']) => { | ||
| (entries as PerformanceEventTiming[]).forEach((entry) => { | ||
| if (entry.interactionId) { |
There was a problem hiding this comment.
FYI, we could potentially polyfill for Firefox by assigning an interactionId for the entry here, for events of specifics types. This would include more events than we want, ideally, but could still be useful.
interactionCount estimate would be off, so we could just always return 1.
I'm not sure how much error that approach would have, and how that compares to historical attempts to polyfill features.
There was a problem hiding this comment.
I can experiment.
I did experience some with your earlier polyfill using eventCounts, and that didn't work in Firefox because (IIRC) it doesn't seem to emit pointercancel events. I could try this and see how well it works.
Fixes #208.
This PR builds on top of what @mmocny added in #213 with the following:
observemodule logic to support processing a list of entries rather than each individually.interactionCountlogic into its own module and rewrites it as a "polyfill" so it won't run if the browser natively supportsinteractionCount(hopefully coming to Chrome soon).Metric.entriesvalue to all reported entries from the INP interaction, rather than just the longest. (As discussed we should extend this to all entries in the frame, but we probably need a dedicated API for this first.)durationThresholdto 50 as a compromise between performance and more accurate duration values at lower percentiles.