← Chrome 147 reference

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.

Developer trial This API is behind a flag in Chrome 147. Enable 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 147Developer trial (behind a flag)
ExtendsJS Self-Profiling API (Profiler), available on main thread since Chrome 94
Flagenable-experimental-web-platform-features
SpecWICG JS Self-Profiling API
ChromeStatus5159559872249856 — JS Profiling in Dedicated Workers
Source: chromestatus.com/feature/5159559872249856

Gating and status divergence, both sides reported rather than resolved (fetched 2026-10-06): this page presents the API as Developer trial, flag-gated in Chrome 147, while ChromeStatus feature 5159559872249856 reads status “Proposed” with no desktop milestone field at all and describes the surface as “remaining gated by Document Policy”, with Document Policy support for workers tracked separately. The cited WICG draft is where that gate is defined: it specifies a js-profiling-mode document policy that rejects with NotAllowedError, which this page does not mention. One statement is carried by neither cited source — that the main-thread API has been available since Chrome 94 — and it is reported here as a page-only claim rather than silently removed.

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 API

example

// 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 });
Source: WICG JS Self-Profiling API

browser support

BrowserDedicated-worker profiling status
Chrome 147This page describes a flag-gated developer trial, but the cited ChromeStatus record still reads “Proposed” with no desktop milestone. The WICG draft also specifies a js-profiling-mode Document Policy gate; the flag alone does not establish usable worker support.
EdgeWorker support is not established by the cited sources.
FirefoxWorker support is not established by the cited sources.
SafariWorker support is not established by the cited sources.

Main-thread Profiler availability does not establish support inside dedicated workers in any browser.

Sources: ChromeStatus feature 5159559872249856; WICG JS Self-Profiling API draft.

see also