Re: [w3ctag/design-reviews] Long Animation Frame API (LoAF) (Issue #911)

> Hi @noamr, thanks for the additional context.
> 
> > We have discussed some of this with other browser vendors, and the conversation goes on.
> 
> I can't tell how supported the feature by other browser vendors is by this statement. Can you please elaborate or point me to observable discussions?

Of course! Minutes of the discussion at TPAC: https://w3c.github.io/web-performance/meetings/2023/2023-09-TPAC/index.html

Search LoAF.
According to WebKit folks this is more implementable than long tasks, and according to Firefox this is more in line with
benchmarks like Speedometer 3. We filed standards position requests with both (https://github.com/mozilla/standards-positions/issues/929, https://github.com/WebKit/standards-positions/issues/283).

> 
> > The major details in the spec expose things that are well specified and already observable like the stages in the rendering pipeline. We're making sure that whatever is in the spec matches those existing concepts.
> 
> I am concerned that LoAF is attempting to expose something observable today, and make it easier to obtain, cross-origin and cross-frame without justifying if it is good for users or not. In particular, this type of exposure appears as [ancillary user data](https://w3ctag.github.io/privacy-principles/#ancillary-uses) - is it?

The data observed in LoAF is how long rendering in your own origin was delayed.
This is information you should probably know, and have access to anyway. The way in which this API exposes this information is marginally easier than measuring it yourself - the main thing that this API makes easier is understanding the root cause of delays caused by your own origin. An equivalent would be resource timing, where if you have other origins clogging your network bandwidth it would be observable as slow downs for your own resources.

I think it follows the principles in https://w3ctag.github.io/privacy-principles/#information: "New APIs which add new ways of getting information must be [guarded](https://w3ctag.github.io/privacy-principles/#dfn-access-guard) at least as strongly as the existing ways". This holds here. Information about how much rendering was delayed is not currently guarded in any way (and cannot be guarded, except by means of process isolation).  
 
> 
> Couple of additional points:
> 
> * Interop (similar to my first question above), I still can't tell how well implementable the feature across engines is (great to see you're working with Moz and Webkit).

Waiting for them to respond to the standards position open issues.

> * The overall extensibility model - for me, the major benefit of the feature compared to what is possible today (despite not being too easy) is the ability to create causality - "what is causing a chain of events that is resulting in a long running animation?", and I can't tell what that would look like from the current work. Perhaps you can point me to additional examples, or work in progress I can learn from?

Not only "long running animation", but also "slow responsiveness".
See the earlier attached TPAC minutes for use case from Microsoft, they've been successfully using it to reduce scroll jankiness, and also [success stories from RUMVision](https://www.linkedin.com/posts/erwinhofman_performance-javascript-corewebvital-activity-7122519650461958144-FFK5/) where they actively use this (as part of the origin trial) to pinpoint scripts responsible for sluggish websites for their customers.




-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/911#issuecomment-1864189948
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/911/1864189948@github.com>