Add INP breakdown timings and LoAF attribution

[philipwalton]

This PR updates the INP attribution logic from an "interaction-based" model to a "frame-based" model. This better aligns this library's attribution data with what's exposed in the Interactions track in DevTools, as well as with the Long Animation Frame API.

The following are the most important changes that PR introduces:

In /src/onINP.ts:

• Before, the metric.entries array would only include entries with the same interactionId value. Now, metric.entries will include all event entries whose processing time occurs between the user interaction and the next frame painted. This allows developers to more accurately attribute the full "processing time" of the interaction.

In /src/attribution/onINP.ts:

• Support for the Long Animation Frame API has been added. The new longAnimationFrameEntry property will look for a corresponding long-animation-frame entry, and report it if found (i.e. if the browser supports the API and the frame was long enough for the entry to be dispatched).
• Breakdown timings for inputDelay, processingTime, and presentationDelay have been added (see the README for detailed description of each).
• All of the event* names in the INPAttribution interface have been renamed to interaction* since now there is no single event entry that gets reported (so the term "interaction" now is much more suitable).

To see these changes visualized, below are two screenshots of traces from the INP Demo page showing the new INP attribution data in action. Notice how the "Interaction" and "Event" measures in the Timings track line up perfectly with what DevTools displays in the Interactions track (including the breakdown timing whiskers), as well as with the events in the main thread flame chart below:

[tunetheweb]

In general LGTM. But do have some comments/questions

[philipwalton]

@mmocny FYI the logic to select which LoAF entries get attributed to INP is here.

[philipwalton]

Hey all, thanks for the extensive reviews. Based on feedback (and internal discussions) I've updated the logic quite a bit. Here are the main changes:

• I've moved the logic to group event entries by animation frame into the attribution build, so metric.entries will continue to only include entries with matching interactionId values (as it does currently, and I've added attribution.processedEventEntries which will contain all event entries that were processed within the same animation frame as the INP candidate interaction.
• I've also added a attribution.nextPaintTime which is a convenience for startTime+duration but also clamps the value so that it's never less than processingEnd or renderTime (from LoAF).
• I've updated attribution.longAnimationFrameEntry (single LoAF) to longAnimationFrameEntries (array of LoAFs) based on internal discussion. This should allow developers to get full LoAF attribution for everything that's happening during the INP candidate interaction.
• attribution.interactionType is no longer 'keyboard' | 'pointer', I've reverted it back to being the entry.name for the INP entry.

@mmocny @tunetheweb Please take a look and let me know if you have any additional feedback.

[philipwalton]

@mmocny if you have time to review this function, that would be helpful. This function isn't part of the public API, but if any part of this logic fails (or is incorrect) then it could result in issues, so I'd love a second pair of eyes on it.

In short, this function tries to remove references to event and LoAF entries that are no longer needed (so we're not just storing everything in memory), but there's the potential that I could remove a reference to something that will later been needed and then it won't get reported in the attribution object (or worse, there will be an error because other code will try to reference a property of an object that no longer exists).

[tunetheweb]

LGTM with two outstanding questions.

Awesome work here!