#1012: User-defined script "entry points" for performance timing
Discussions
Log in to see TAG-private discussions.
Discussed
Jan 13, 2025 (See Github)
Amy: (End) user needs are not explicitly stated.
Comment by @matatk Jan 15, 2025 (See Github)
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.
Discussed
Feb 10, 2025 (See Github)
Matthew: no input on either of these... We're still waiting for an update.
Discussed
Mar 17, 2025 (See Github)
Matthew: Wrote a comment about this in internal thread. Lots of technical stuff. Needs more eyes. Some considerations: the Explainer talks about two ways to do this on the platform but we kind of don't because both are only in Chromium. In the alternative section: it also mentions why it isn't suitable. That's sounsd about right. Then why not fix that API in the WG instead of proposing it here in the Explainer. Wasn't quite sure.
Jeffrey: Is user timing more widely implemented?
Matthew: It's Baseline.
Jeffrey: It'd be nice if the Explainer would say that. Probably worth posting the questions to the discussion thread.
Matthew: Will mention if they have considered it in the WG. Fix/Augment/Replace to address the needs they got. Will draft.
Matthew: We asked some things to be added to the Explainer. Specifically end-user needs. And less specific about alternatives considered.
Comment by @matatk Mar 17, 2025 (See Github)
Hi @noamr. We discussed your work on this again today. Further to our comment above, we're still keen to get your input (via the explainer) on the end-user needs addressed by the work. We also have a couple more specific questions on the "alternatives considered" section:
-
Did you look into whether any part of the existing User Timing APIs could be fixed - or perhaps more likely replaced - in order to overcome the limitations you list for them?
-
Did you either consider, or already try, starting this work within the Web Performance WG?
OpenedNov 6, 2024
こんにちは 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.
Further details: