Closed noamr closed 7 months ago
@noamr, This is a great initiative! I would love to see something like this gets implemented and to experiement with this.
Some initial thoughts:
hasDocumentThatNeedsRender()
and hasRenderingOpportunity()
are mutially exclusive. Worth clarifying what these checks mean.executionStartTime - startTime
represents the parse+compile time? Or, are there additional steps included in that period?styleAndLayout
related properties to separate style
and layout
?PerformanceObserver
with a limited buffer would be a way to achieve that. Is that the intent?@noamr, This is a great initiative! I would love to see something like this gets implemented and to experiement with this.
Some initial thoughts:
- Clarifying the definitions of the LoAF entry properties. A diagram showing each property in the frame may really help.
- In the "prosessing model" section - isn't there a case where 2 reports are sent in the same animation frame? (unless
hasDocumentThatNeedsRender()
andhasRenderingOpportunity()
are mutially exclusive. Worth clarifying what these checks mean.
It needs to also reset frameTiming
to null, I'll fix that.
- 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.
- 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.
- Would it make sense to split the
styleAndLayout
related properties to separatestyle
andlayout
?
I'll add it as a future thing
- 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.
- 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 :)
- 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.
@nhelfman I've updated the explainer a bit. Thanks for your comments!
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!
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:
@sefeng211: Added a security & privacy blurb to the explainer PR: https://github.com/w3c/longtasks/pull/100/commits/cd59f77d056be802cfbb3a20be7908225fbcce60
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:
The revamp:
Counting frames instead of tasks: from the beginning of a task until one of the following:
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: https://github.com/w3c/longtasks/pull/100 Addresses https://github.com/w3c/longtasks/issues/89