v147 · developer trial · workers · performance
JS Profiling in Dedicated Workers
Chrome 147 adds developer trial support for the JavaScript Self-Profiling API (Profiler) inside dedicated workers. Previously only available on the main thread, this lets worker scripts collect their own JavaScript call-stack samples, enabling fine-grained profiling of CPU-intensive work that's already been offloaded to a worker.
chrome://flags/#enable-experimental-web-platform-features to try it. The API surface may change before it ships. Do not use in production.
at a glance
| Status in Chrome 147 | Developer trial (behind a flag) |
|---|---|
| Extends | JS Self-Profiling API (Profiler), available on main thread since Chrome 94 |
| Flag | enable-experimental-web-platform-features |
| Spec | WICG JS Self-Profiling API |
| ChromeStatus | 5159559872249856 — JS Profiling in Dedicated Workers |
why it exists
Many performance-sensitive applications move heavy computation into dedicated workers to keep the main thread responsive — data processing, cryptography, image manipulation, WebAssembly wasm calls, etc. Without profiling support in workers, developers had to rely on external DevTools profiling or indirect measurement.
The JS Self-Profiling API allows scripts to collect statistical call-stack samples of their own execution and report them as structured JSON-compatible traces. Extending this to dedicated workers lets performance engineers measure exactly where worker CPU time is spent without special DevTools attachment.
Source: WICG JS Self-Profiling APIexample
// Inside a dedicated worker script (requires flag in Chrome 147)
const profiler = new Profiler({
sampleInterval: 10, // ms between samples
maxBufferSize: 10_000, // max samples before auto-stop
});
// ... run your computation ...
await doHeavyWork();
const trace = await profiler.stop();
// trace is a ProfilerTrace object with stacks and frames
postMessage({ trace });