Intent to Prototype: User-defined entry points in long animation frame timing
Chromestatus
Contact emails
nrose...@chromium.org, shas...@chromium.orgExplainer
https://github.com/w3c/long-animation-frames/blob/main/user-defined-script-entry-point-explainer.mdSpecification
https://w3c.github.io/long-animation-framesSummary
Long animation frames allow insight into main-thread bottlenecks that can result in jank and bad INP. Some of these insights are the monitoring of long "script entry points" - callbacks from the platform (event handlers/script blocks etc) that take more than 5ms. However, those "entry points" are often too coarse, and don't give enough insight about the true cause of the bottleneck This feature allows user code to define its own "entry points", and those entry points would appear as bottleneck in the LoAF API.
Blink component
Blink>PerformanceAPIsMotivation
See https://github.com/w3c/long-animation-frames/issues/3. From the inception of long animation frames, this was the biggest pain point, where bottlenecks were often attributed to "wrappers" of frameworks and RUM libraries, not giving actionable insight about the culprit script.
Initial public proposal
https://github.com/w3c/long-animation-frames/blob/main/user-defined-script-entry-point-explainer.mdTAG review
NoneTAG review status
PendingRisks
Interoperability and Compatibility
None
Gecko: No signal
WebKit: No signal
Web developers: No signals
Other signals:
WebView application risks
Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?
None
Debuggability
None
Is this feature fully tested by web-platform-tests?
NoFlag name on about://flags
NoneFinch feature name
NoneNon-finch justification
NoneRequires code in //chrome?
FalseEstimated milestones
No milestones specified