Finish adding getINP()

[philipwalton]

Fixes #208.

This PR builds on top of what @mmocny added in #213 with the following:

• Updates the observe module logic to support processing a list of entries rather than each individually.
• Moves the interactionCount logic into its own module and rewrites it as a "polyfill" so it won't run if the browser natively supports interactionCount (hopefully coming to Chrome soon).
• Sets the Metric.entries value 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.)
• Updates the durationThreshold to 50 as a compromise between performance and more accurate duration values at lower percentiles.
• Adds bfcache support.
• Adds tests

[mmocny]

Changes look solid, nice!

Most comments are nits, but I think a few may be actual bugs.

I didn't review or try the unit tests.

[mmocny]

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.

[philipwalton]

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.

[mmocny]

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.

[philipwalton]

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.

[mmocny]

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.

[philipwalton]

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.

[mmocny]

Event Timing is rounded to the nearest 8ms. That makes the duration a nice round number (either 48ms or 56ms).
That means that this 50ms durationThreshold is effectively a 56ms duration threshold, which we may want to be explicit about.

TL;DR I think this is a good threshold. But here are some nuances:

• At 60hz, 56ms is 3.5 frames, which means it can effectively get presented at the same time as other entries with 64ms of latency.
• Conversely, if you were to change to 48ms durationThreshold, you really should probably use 40ms to include entries that take 2.5 frames @ 60hz.
• If you wanted to group entries by frame (i.e. by presentation time) you would need to take startTime + duration and then group entries which are within 8ms windows. A single shared presentation time can include entries with a wide range of durations. An entry with less than durationThreshold duration can have large processing time. (This is one reason why we may want a dedicated api)

[philipwalton]

Maybe 40 makes more sense then? I think the spirit of that comment is actually what I'm trying to report on. I.e. missing a frame deadline is probably inevitable for most pages, but once you're missing more than 2 or more frames it's probably worth knowing about.

[philipwalton]

Done.