Consider evolving "first-input" to "first interaction"

[mmocny]

Today, Event Timing reports both "first-input" specifically, and then all "event" beyond that. The biggest key advantage of "first-input" is that it has no default durationThreshold requirement, while "event" has a default buffer threshold of 104ms.

We have added the concept of interactionId to events, which matches the goals that "first-input" has long had already. For example, "first-input" has always ignore pointerdown events which are followed by a pointercancel (i.e. scrolling) instead of pointerup.

A cleaner way to define "first-input" these days might be to just report the first "event" with interactionId that is non-0.

Beyond that, it might be useful for "first-input" to actually report a list of entries, i.e. all the entries that share the same interactionID. We already typically have to wait for the interaction to finish before reporting it to the timeline-- though this would entail a bit more waiting now.

---

There is some compatibility risk with reporting multiple entries for "first-input". It looks like web-vitals.js might be expecting to iterate all entries, for example.

[mmocny]

The primary goal for reporting list of entries would for for cases such as where the first tap on the page has a very small duration for pointerdown, but a larger duration for pointerup/click.

---

Counterpoints:

• If that larger duration is >104ms, it would have been reported to "event" timing anyway.
• Reporting just the events with the same literal interactionID is sort of only half the battle, for attribution. Ideally we would report the whole animation frame worth of event timings, any time an animation frame is deemed having events worth reporting. This typically happens automatically when its based on duration (as all events will have long duration if any do, typically).

[mmocny]

I recently presented at a WG meeting. There seemed no concerns with making this change, and I will try to take a stab at it. The spec changes which impact the first-input definition as first-event-with-interactionID does not need to be coupled with the exposing of the interactionID value.

--

Regarding dispatching all the entries related to the interaction, one alternative that came out of that discussion is that perhaps if Event Timing API itself just special cases the first interaction for buffering purposes, even if it was less than 104ms, that would accomplish similar goals with less compatibility risk.