[INP] attribution should include all events from the same long animation frame

[mmocny]

For every interaction you have:

• A single interactionId
• A few Event Timings which share that interactionId, potentially with different presentation times
• A single "longest" Event, whose duration becomes the INP score

This is what is reported via INP attribution, today.

But each of these "longest" Events actually belong to a single (usually Long) Animation Frame, and that Animation Frame typically has multiple Events which get dispatched. It is often the case that multiple events have long processing times-- and sometimes "the interaction" event isn't even the main culprit.

Although just reporting "the interaction" event suffices for duration it is somewhat inadequate for attribution.

---

A better process may be to do something like the following:

1. Select important time ranges for Events.
   • e.g. based on all long Interactions, or
   • e.g. based of the single longest Interaction only (your INP)
2. Group all events that share that same animation frame
   • You can do this using just Event Timing startTime + duration (which is effectively a renderTime)
   • Note: because duration is rounded to 8ms, group by renderTime +/- 8ms.
3. Mark the smallest processingStart
4. Mark the largest processingEnd
5. Sum the total (non-overlapping) processing time

With that, you get a better model for:

• Input Delay
• All event's processing (time and range)
• Presentation Delay

You also get a "list of important events" rather than just a single event. Some of those events may have different event targets. Some of those events may actually have different interactionId's -- which itself is interesting for attribution: "actually, this is a rage click", etc.

You can read more about this in this workshop

---

However, the easiest and best way to accomplish this goal is to leverage LoAF (which also gets you script attribution and rendering-work attribution as distinct from "presentation delay")

Related to Issue #363.

[tunetheweb]

Resolved with #442