Fix 228: Change onINP to also use FID duration when under durationTheshold

[mmocny]

This is a PROTOTYPE for adding support for registering multiple observer types with the same PO observer -- specifically to use both first-input and event timing together, with the same PerformanceObserver / handler.

I have not tested this thoroughly, just checking to see how it would look for now and to continue conversation.

Context:

• Consider expose FID duration as first INP score, for cases when its under durationThreshold #228 (comment)
• Chromium is fixing the fact that FID does not have interactionID

[mmocny]

I considered making this string || string[] and adjusting this implementation to support either option... decided it was better to make a single choice but totally understand alterantive.

[mmocny]

Right now, the same options are passed for all registered types. This is fine for this specific case.

But in general we may want to have [string, PerformanceObserverInit][] (aka array of tuple) instead

[mmocny]

This is only needed until first-input gets a proper interactionID.

For now, this leads to the "10 worst" list being 1 larger. But since web-vitals.js doesn't use that to count number of interactions, it doesn't really matter. The only time it matters is if the first-input duration becomes the 10th largest and ends up evicting another interaction from the list, and then you also have 500 interactions.

[philipwalton]

Thanks for filing @mmocny. This PR helped me realize that the change to support #228 wouldn't end up being much extra code.

I did have some concerns about this implementation, though, so I filed #232 to compare. One issue I encountered with this PR is that some of the tests fail (specifically the ones that test the high-percentile logic) because they create a long first interaction and then assert that that interaction is not INP after 50 additional interactions. But if we don't dedupe cases where the first-input entry is also one of the longest interactions, then that logic breaks. In reality I don't think it would be a huge deal, but it was easy enough for me to dedupe those, and then I didn't have to change the test logic.

I also thought it would be easier to do a one-off additional observe() call in onINP() rather than adding support for additional types in the helper module.

LMKWYT.

[mmocny]

Yes I figured those types of tests would break, but decided it wasn't likely a big deal on real sites (i.e. the difference wouldn't come up in p75 field data).

However, if you found a way to dedupe, woot! I'll take a look at that patch.