Intent to Prototype: Support Long Animation Frames API in Web Workers

17 views
Skip to first unread message

Chromestatus

unread,
Jul 20, 2026, 5:03:00 PM (19 hours ago) Jul 20
to blin...@chromium.org, jo...@chromium.org, joon...@microsoft.com
Contact emails
jo...@chromium.org, joon...@microsoft.com

Explainer
https://github.com/WICG/delayed-message-timing/blob/main/loaf-congested-moments/explainer.md

Specification
No information provided

Summary
This feature extends the existing Long Animation Frames (LoAF) API to Web Workers. Today LoAF reports only on the main thread and is anchored to rendering frames, so it cannot observe work that blocks a worker's event loop. With this change, a long task that blocks a worker's event loop is reported as a long-animation-frame entry that is observable from inside the worker via PerformanceObserver, with the usual per-script attribution. The prototype starts with dedicated workers, reporting a single long task that blocks the worker's event loop. The broader goal is to surface congested moments, intervals where an event loop remains busy and runnable work is delayed. This includes detecting a flood of many small tasks that keeps the event loop busy and reporting it as a long-animation-frame entry, as well as supporting the main thread. This is planned as follow-up work.

Blink component
Blink>PerformanceAPIs

Web Feature ID
long-animation-frames

Motivation
Web apps increasingly offload work to Web Workers, but a worker that blocks its own event loop is invisible to today's performance APIs. Workers usually have no rendering lifecycle, so there are no animation frames for LoAF to anchor to, and the main-thread LoAF and Long Tasks APIs cannot observe work running in a worker. As a result, a long task in a worker, which delays incoming message events and any OffscreenCanvas rendering, goes unreported even though it directly degrades responsiveness. Rather than introduce a new API, we extend LoAF, because detecting a long animation frame and detecting a congested moment are fundamentally the same task: identifying bottlenecks in an event loop and attributing them to the responsible scripts. Reusing the existing API gives developers a single, familiar mechanism for diagnosing blocking work across both documents and workers.

Initial public proposal
https://github.com/WICG/delayed-message-timing/blob/main/loaf-congested-moments/explainer.md

Goals for experimentation
None

Requires code in //chrome?
False

Tracking bug
https://issues.chromium.org/issues/534893134

Estimated milestones

No milestones specified



Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5387465121726464?gate=4706842090536960

This intent message was generated by Chrome Platform Status.
Reply all
Reply to author
Forward
0 new messages