the worker's own PerformanceObserver
—
Not run yet.
v153 · loaf in workers
Blocking a worker on purpose
A real worker, a real busy loop, and three witnesses asked afterwards what they saw. The main thread keeps sending pings throughout, so the stall is measurable from outside even when nothing inside the worker can report it.
Jam the worker
the main thread's observer
—
Not run yet.
a round-trip ping
—
Not run yet.
Ping log
The page stays responsive throughout — the block is in the worker, not here. That is exactly what makes it hard to find: nothing janks, a message is simply late, and by the time you notice, the worker has moved on.
What the ping can and cannot tell you
A round trip that takes 400ms instead of 1ms proves the worker was busy. It does not say for how long, exactly — the ping was sent at some point during the block and answered at the end of it — and it says nothing at all about what the worker was doing. In production you do not get to send pings during the stall you are trying to diagnose; you get a report from a user's machine, after the fact.
That is the difference an entry makes. A long-animation-frame entry inside the worker carries the duration, the blocking duration, and the scripts responsible with their source URLs and character positions — a stack trace's worth of attribution, recorded without anyone having to be watching at the time.