User-defined script "entry points" for performance timing

[noamr]

こんにちは TAG-さん!

I'm requesting an early TAG design review of User-defined script "entry points" for performance timing.

"Long animation frames" help diagnose main-thread bottlenecks and attribute them to causes like scripts. However, for overhead reasons, we currently only report script "entry points" (platform callbacks, event listeners, script blocks, platform-promise resolvers) - which is often not granular enough.

The proposal is to allow user code to define their functions as "entry points" that would be reported when attributing long animation frames.

• Explainer¹: https://github.com/w3c/long-animation-frames/blob/main/user-defined-script-entry-point-explainer.md
• User research: Since the inception of long animation frames, this has been the top issue that came back from adopters. See [LoAF] Allow for annotations for long animation frame to further help debugging w3c/long-animation-frames#3
• Security and Privacy self-review²: here
• GitHub repo: https://github.com/w3c/long-animation-frames
• Primary contacts: @noamr, Google; @tunetheweb, Google.
• Organization/project driving the design: Google
• Multi-stakeholder feedback³:
  • Chromium comments: planning to prototype this and work with the WebPerfWG.
  • Mozilla comments: TBD
  • WebKit comments: TBD
  • See initial WebPerfWG discussion at TPAC.

Further details:

• I have reviewed the TAG's Web Platform Design Principles
• The group where the incubation/design work on this is being done (or is intended to be done in the future): WebPerfWG
• The group where standardization of this work is intended to be done ("unknown" if not known): WebPerfWG
• Existing major pieces of multi-implementer review or discussion of this design:
• Major unresolved issues with or opposition to this design: need to check if microtask support is feasible in all implementations.
• This work is being funded by: Google

[matatk]

Hi @noamr, thanks for your review request. We have been discussing entry points today, and have a question about the explainer. We would really like to see the (end-)user needs made explicit. It can be tough (or perhaps seem obvious) when proposals are deeply technical, but it's helpful for us in weighing up the trade-offs made by a proposal.

One example of a fairly technical explainer that talks first about the needs of the user is Autoplay Policy Detection - this is linked from our guidance on explainers.