js-profiling in dedicated workers

concepts

1. Worker Profile

   Spins up a Dedicated Worker that does some real CPU work, profiles it for ~2 seconds, then renders the captured frames as a hot-functions list.

2. Trace upload

   Worker A runs the load and profiles it. Worker B aggregates the trace off the main thread into a compact payload, then navigator.sendBeacon fires it at a telemetry endpoint — the WICG-recommended pattern for RUM profiling at scale.

3. Profile Comparator

   Runs an identical CPU-intensive task (prime factorisation) on both the main thread and a Dedicated Worker and profiles both with the JS Profiler API. Chrome 147 enables the Profiler inside workers — compare the sample traces and timings side by side.

4. Profiler API Explorer

   Three-tab explorer. Main thread tab: configurable sample interval and buffer size, runs Fibonacci or sort workload, renders trace as a horizontal flame-graph. Worker tab: detects Profiler inside a Blob Worker and posts the trace back. Comparison tab: overlays main vs worker samples per function in a paired-bar chart.

5. Compatibility Lab

   Detects the Profiler API on both main thread and inside a Worker. Runs a live profiler test in a blob worker and reports sample counts. Provides the performance.mark() fallback and the complete worker-messaging pattern for environments without Document-Policy: js-profiling.

why it shipped

Lots of work has moved off the main thread — image processing, parsing, AI inference, codecs. But the JS Self-Profiling API was main-thread-only, so the moment something interesting moved into a worker, sites lost the ability to attribute time. The fix is to apply the same Profiler primitive inside dedicated workers, gated by the same js-profiling Document Policy. Performance teams now get a complete picture of where execution time lands.

references

• ChromeStatus entry
• JS Self-Profiling spec