search

w3c / long-animation-frames

Long Animation Frame API specification repository
Other
8 stars 1 forks source link

LoAF: `firstUIEventTimestamp` contains non-INP events #1

Open tunetheweb opened 7 months ago

tunetheweb commented 7 months ago

firstUIEventTimestamp measures the first user interface event, which may include events that are not considered as “interactions” for the more restrictive Interaction Track of DevTools Perormance panel and INP as these only look at certain events with an interactionId. For example,pointerover, pointerdown, mousedown… etc. could all register as the firstUIEventTimestamp but would not count towards Interactions track/INP which might happen later in the frame (or not at all!).

While I think it’s right to measure these in LoAF , it could be confusing to developers if they are using firstUIEventTimestamp to measure LoAFs with interactions.

Should we add a firstInteractionEventTimestamp?

At the very least we should document this.

Reference: https://x.com/blue2blond/status/1751192272572420563?s=46&t=72NqVYI80BM0T97DHBG8iQ

anatdagan commented 7 months ago

This is critical for us, since we use firstUIEventTimestamp to calculate rum INP.Please find a solution for this🙏

tunetheweb commented 7 months ago

@anatdagan could you please explain a little more about how this impacts you? You cannot use firstUIEventTimestamp to calculate RUM INP, and even if you could it wouldn't necessarily reflect the correct INP since firstUIEventTimestamp may not be related to the INP event.

vanderhoop commented 7 months ago

Should we add a firstInteractionEventTimestamp?

@tunetheweb If this were added (and the what-constitutes-an-interaction logic was consistent between loafs and inp attribution), would mapping a long animation frame to an INP attribution be as simple as loaf.firstInteractionEventTimestamp === inpAttribution.eventTime? Or would there be additional considerations?

It'd be helpful regardless, as I had to poke around quite a bit to find the issues with firstUIEventTimestamp and why it wasn't used in Noam's linking gist.

tunetheweb commented 7 months ago

You could in theory have two interactions within the same frame, and the INP could be the second one so might not be the firstInteractionEventTimestamp. Or two interactions that start on the same timestamp.

Though struggling to see how, as presumably the render delay part of INP wouldn't be until the end of the frame so the first one should be the longest... 🤔

anatdagan commented 7 months ago

Hi Barry,We collect LoAF RUM data, and we consider the longest LoAF of the page with firstUIEventTimestamp >0 as the INP of the page.Sent from my iPhoneOn 29 Jan 2024, at 19:04, Barry Pollard @.***> wrote: You could in theory have two interactions within the same frame, and the INP could be the second one so might not be the firstInteractionEventTimestamp. Or two interactions that start on the same timestamp. Though struggling to see how, as presumably the render delay part of INP wouldn't be until the end of the frame so the first one should be the longest... 🤔

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>

mmocny commented 7 months ago

As one thing to consider-- LoAF is used for more than just INP measurement. Some folks have been using it for Smoothness and a type of "FPS" measure.

In those cases, firstUIEventTimestamp might represent the e.g. pointermove/scroll events.

I cannot say if the current value is useful or not, but if the issue is INP overlap I think there is a wider discussion about how best to do EventTiming <-> LoAF attribution and we can delay this decision until we gain more experience on this type of attribution work?