New proposal: long animation frames

[noamr]

This is a revamp of proposals that went around before, with some changes.

Long tasks are marketed as the way to diagnose responsiveness/jank.
However, in the years since we've shipped them we found that they are lacking:

1. They don't contain the rendering phase, which means a lot of what goes into blocking interactivity is not counted
2. Long tasks are missing details about what made the task long 3. UI events are not specified not implemented in terms of tasks, causing confusion.
3. Internal changes in implementation change the meaning of a "task" too often.

The revamp:

Counting frames instead of tasks: from the beginning of a task until one of the following:

1. the frame has been rendered or the task is complete
2. The task was long and resulted in no changes.

In addition, add information about how long it took to style&layout, as well as a breakdown of long-running same-frame top-level scripts, plus additional information that can help diagnose long main-thread blocking periods.

Some of these details need to be fleshed out, we're planning to test what kind of information they produce in Chrome before going through scrutiny.

See explainer PR: #100
Addresses #89

[nhelfman]

@noamr, This is a great initiative! I would love to see something like this gets implemented and to experiement with this.

Some initial thoughts:

1. Clarifying the definitions of the LoAF entry properties. A diagram showing each property in the frame may really help.
2. In the "prosessing model" section - isn't there a case where 2 reports are sent in the same animation frame? (unless hasDocumentThatNeedsRender() and hasRenderingOpportunity() are mutially exclusive. Worth clarifying what these checks mean.
3. It may be useful to enable LoAF frame threshold as part of the observer init options. It can imagine important use cases where LAF shorter that the 50ms would be desired (e.g. smooth scrolling, dragging).
4. Is it correct to say that in the script entry executionStartTime - startTime represents the parse+compile time? Or, are there additional steps included in that period?
5. Would it make sense to split the styleAndLayout related properties to separate style and layout?
6. It feels like there is some overlap with the proposed JS-Propfiler-Markers . Does it make sense to collaborate with that proposal?
7. I would think that correlating Event Timing entries and JS-Self-Profiler sample entries with the LoAF entries would be an interesting way to get better insights for root cause analysis of performance bottlenecks.
8. Understanding the perf overhead this may introduce will be important. Being able to have throttle the overhead will be useful. My assumption is that use PerformanceObserver with a limited buffer would be a way to achieve that. Is that the intent?

[noamr]

@noamr, This is a great initiative! I would love to see something like this gets implemented and to experiement with this.

Some initial thoughts:

1. Clarifying the definitions of the LoAF entry properties. A diagram showing each property in the frame may really help.
2. In the "prosessing model" section - isn't there a case where 2 reports are sent in the same animation frame? (unless hasDocumentThatNeedsRender() and hasRenderingOpportunity() are mutially exclusive. Worth clarifying what these checks mean.

It needs to also reset frameTiming to null, I'll fix that.

3. It may be useful to enable LoAF frame threshold as part of the observer init options. It can imagine important use cases where LAF shorter that the 50ms would be desired (e.g. smooth scrolling, dragging).

I put it as a future thing in the end, wanted to start with the basics.

4. Is it correct to say that in the script entry executionStartTime - startTime represents the parse+compile time? Or, are there additional steps included in that period?

It's correct enough.

5. Would it make sense to split the styleAndLayout related properties to separate style and layout?

I'll add it as a future thing

6. It feels like there is some overlap with the proposed JS-Propfiler-Markers . Does it make sense to collaborate with that proposal?

Yes I'm aware of the JS profiler. The idea here is to have something with low overhead that you can keep running for a long time and not have to turn on/off. I see profiling vs. performance-observers as two different layers of performance measurements.

7. I would think that correlating Event Timing entries and JS-Self-Profiler sample entries with the LoAF entries would be an interesting way to get better insights for root cause analysis of performance bottlenecks.

Absolutely, as long as you're ok with the overhead of JS profiling :)

8. Understanding the perf overhead this may introduce will be important. Being able to have throttle the overhead will be useful. My assumption is that use PerformanceObserver with a limited buffer would be a way to achieve that. Is that the intent?

Exactly, LoAF performance observers, unlike JS profilers, aim to have near zero overhead.

[noamr]

@nhelfman I've updated the explainer a bit. Thanks for your comments!

[sefeng211]

Hi Noam,

Thanks for the work and I like the API!

For the privacy aspect, I wonder if you could add a section to the explainer to explain what origin can access what information? I'd assume that for things like layout computation time, we don't want third party to access them? I know you've explained this in the meeting, but still want to double check with you in case I missed anything.

My another concern is the performance overhead and glad that it's aiming for zero overhead.

Thanks!

[noamr]

Hi Noam,

Thanks for the work and I like the API!

For the privacy aspect, I wonder if you could add a section to the explainer to explain what origin can access what information? I'd assume that for things like layout computation time, we don't want third party to access them? I know you've explained this in the meeting, but still want to double check with you in case I missed anything.

Will do. For layout computation time, For frames in your own agent it's observable today if you layout-thrash or use resize observers. I'll add some wording on it here.

My another concern is the performance overhead and glad that it's aiming for zero overhead.

Aiming for negligible overhead :) not sure I can write any code with absolute zero overhead :)

I think there would have to be some fine tuning of:

• How long is a long script, the longer it is the less overhead to keep records
• How much details do we want to get. Perhaps some of them like source-location can be optional.

[noamr]

@sefeng211: Added a security & privacy blurb to the explainer PR: cd59f77