Profiling Worker CPU Usage with the Chrome Performance Tab

A worker that takes 14 ms to answer is not necessarily doing 14 ms of work — and the Performance panel will tell you exactly how much of it was your algorithm, if you record it correctly.

This page narrows postMessage Bottleneck Analysis, part of the Debugging, Profiling & Production Optimization reference, to one narrow task: reading a dedicated worker’s own track in Chrome DevTools and attributing every millisecond in it to either compute or message overhead. The companion page Measuring Structured Clone Cost with performance.now() puts numbers on that overhead from code; this one finds it in a trace.

What a Worker’s Track Actually Contains

Offloading work to a worker removes it from the main thread’s frame budget, but it does not make the work free, and it adds a cost that did not exist before: the payload has to be copied across the thread boundary in both directions. In a trace, all three of those costs land inside a single task on the worker’s track, in this order:

1. Deserialize. Before your handler body runs, the serialized payload has to become a live object graph on the worker’s heap. In Blink this is lazy — it happens on the first read of event.data — so it usually appears as an unattributed block at the top of the message-event task, right where a reader instinctively assumes their own code has started.
2. Compute. Your actual algorithm. This is the only part that a faster algorithm can shrink.
3. Serialize. The reply passed to self.postMessage() is serialized synchronously inside that call, so it is still part of the same task even though it looks like the task has ended.

Because all three are one contiguous task, the naive reading — “the worker task is 14 ms, so the algorithm is 14 ms” — is wrong by however much the payload costs, and for a large object graph that can be most of it.

Minimal Reproducible Example

The smallest instrumentation that makes the split visible is a pair of marks around the computation and a measure joining them. Everything else in the snippet exists to keep a long-lived worker from leaking entries:

// filter.worker.js — classic or module worker, both behave identically here
self.onmessage = (event) => {
  // Reading event.data forces deserialization; do it once, deliberately,
  // BEFORE the start mark so the mark does not straddle the copy.
  const { taskId, samples, threshold } = event.data;

  const start = `${taskId}:start`;
  const end = `${taskId}:end`;
  const span = `${taskId}:compute`;

  try {
    performance.mark(start);
    const result = filterAboveThreshold(samples, threshold);
    performance.mark(end);
    performance.measure(span, start, end);

    const [entry] = performance.getEntriesByName(span, 'measure');
    self.postMessage(
      { taskId, result, computeMs: entry ? entry.duration : 0 },
      [result.buffer]                   // transfer the reply, do not clone it
    );
  } finally {
    // A worker that lives for hours accumulates entries forever otherwise.
    performance.clearMarks(start);
    performance.clearMarks(end);
    performance.clearMeasures(span);
  }
};

function filterAboveThreshold(samples, threshold) {
  const input = new Float64Array(samples);
  const out = new Float64Array(input.length);
  let n = 0;
  for (let i = 0; i < input.length; i++) {
    if (input[i] > threshold) out[n++] = input[i];
  }
  return out.subarray(0, n);
}

The typed call site on the main thread, for a worker pool where several threads share one script:

interface FilterRequest {
  taskId: string;
  samples: ArrayBuffer;   // transferred, so the sender pays no copy
  threshold: number;
}

const worker = new Worker(new URL('./filter.worker.js', import.meta.url), {
  type: 'module',
  name: 'filter-0',       // shows up as self.name inside the worker
});

function send(samples: ArrayBuffer, threshold: number): void {
  const req: FilterRequest = { taskId: `filter-0/${crypto.randomUUID()}`, samples, threshold };
  worker.postMessage(req, [samples]);
}

Step-by-Step Walkthrough

const { taskId, samples, threshold } = event.data;

This destructuring is the deserialize step, not a free property read. Placing it above the start mark is deliberate: if the first touch of event.data happened inside the measured region, the band would include the copy and the whole exercise would measure nothing useful. Put the read before the mark and the band contains compute only, with the copy visible as the gap between the task’s left edge and the band’s left edge.

const start = `${taskId}:start`;

Mark names are per-global and unscoped, so a pool of eight workers running the same script produces eight streams of identically named entries in eight separate tracks. Prefixing with a task id — and, in a pool, with the worker’s name — means a band tells you which thread and which request it belongs to without cross-referencing anything. This matters because worker tracks are labelled by script URL, and eight workers from one script give you eight tracks with the same label.

performance.measure(span, start, end);

The measure, not the marks, is what you read in the timeline: marks render as instantaneous ticks, measures as bands with a width. Only the band lets you compare compute against the enclosing task by eye.

const [entry] = performance.getEntriesByName(span, 'measure');
self.postMessage({ taskId, result, computeMs: entry.duration }, [result.buffer]);

Shipping computeMs back with the result gives you the same number without DevTools open — useful for a production histogram, and useful as a cross-check that what you are reading in the flame chart is the region you think it is. The second argument transfers the result buffer, so the serialize suffix of this task stays near zero instead of scaling with the output size; that is the same ownership handoff described in Transferable Objects & Zero-Copy.

} finally {
  performance.clearMarks(start);

The user-timing buffer has no automatic eviction for marks and measures. A worker handling 50 requests per second accumulates 150 entries per second indefinitely; over an hour that is half a million objects that will never be collected and will slow every subsequent getEntriesByName call, because the lookup walks the buffer.

Capturing a Trace That Contains the Worker

1. Open the Performance panel and record with the reload-and-profile control rather than the plain record button. A worker constructed during page startup may never get a track if the recorder attaches after construction; reloading under the recorder guarantees the thread’s creation is inside the trace.
2. Trigger the workload, then stop as soon as the reply lands. Ten seconds of idle timeline makes the interesting 14 ms unreadably narrow.
3. Find the track group labelled with the worker’s script URL. Collapse the main thread and the rendering tracks — or hide them entirely through the timeline’s track configuration — so the worker occupies the vertical space.
4. Zoom to a single message-event task. The user-timing band from your performance.measure() renders beneath the stack frames for that thread; align its edges against the task’s edges to read the overhead prefix and suffix directly.
5. Select the range covered by the band and switch the call tree to Bottom-Up, sorted by Self Time. Restricting the selection first is what keeps deserialization frames out of the ranking.

Compute Time Versus Transfer Strategy

The reason to split the task is that the two halves respond to completely different fixes. Optimising a loop does nothing for a serialization-dominated task, and switching to transfers does nothing for a genuinely CPU-bound one.

Reading the Flame Chart Once the Band Is in Place

With the compute region delimited, the shapes inside it become meaningful:

• Wide, flat blocks are a single synchronous function holding the thread. Trace it in Bottom-Up by Self Time; this is the one shape a better algorithm reliably fixes.
• Long runs of narrow, repeated blocks are per-item call overhead — a callback invoked once per element, or an allocation inside a hot loop. Hoisting the allocation out of the loop typically collapses these more than micro-optimising the body does.
• A deep, stable stack that never widens is usually fine. Depth costs almost nothing; width is time.
• Gaps inside the band mean the worker yielded — a setTimeout(…, 0) chunk boundary, or an await. That is intentional in cancellable jobs but it inflates the measure’s duration beyond actual CPU time, so read computeMs as wall clock, not as CPU, whenever the region contains an await point.
• Cross-thread correlation. Line the worker’s task up against the main thread’s frames in the same trace. If main-thread frames still drop while the worker is busy, the offload is not the fix you thought it was — the jank is coming from the messages, not the work.

Gotchas & Edge Cases

Sub-millisecond functions can vanish from the flame chart

The flame chart for JavaScript is built from a sampling profiler running on the order of one sample per millisecond, so a function that takes 0.3 ms may be sampled once, or not at all, and its apparent width will move between recordings. User-timing bands come from explicit instrumentation and do not have this problem. Below about 2 ms, trust the band and the duration value you posted back; treat the flame chart as a map of where to put the next mark, not as a measurement.

The two threads’ clocks do not share an origin

performance.now() in a worker counts from the moment its global scope was created, not from navigation start, so a worker spawned eight seconds into a page’s life reports timestamps about 8000 ms behind the document’s. Subtracting a worker timestamp from a main-thread one to get message latency produces a plausible-looking, badly wrong number. Convert both to performance.timeOrigin + performance.now() before subtracting — the clock-alignment procedure is worked through in full on Measuring Structured Clone Cost with performance.now(). DevTools itself does this alignment for you when it draws the tracks, which is why a trace can look consistent while your own arithmetic does not.

Blob and inline workers produce unreadable track labels

A worker created from URL.createObjectURL(new Blob([src])) gets a track labelled with an opaque blob: URL that changes on every reload, and a pool of them is indistinguishable. Pass a name to the constructor, echo self.name into your measure names, and the bands become self-identifying regardless of what the track label says. If you need file-level attribution too, append a //# sourceURL=filter.worker.js comment to the generated source.

Timer resolution is coarse unless the page is cross-origin isolated

Outside a cross-origin-isolated context, performance.now() is quantized to 100 µs as a Spectre mitigation, so a 0.3 ms compute band carries roughly ±20% error and two candidate implementations differing by 50 µs are indistinguishable. Serving the profiling build with Cross-Origin-Opener-Policy: same-origin and Cross-Origin-Embedder-Policy: require-corp restores 5 µs resolution — the same isolation SharedArrayBuffer requires. Those headers also block third-party frames and images that do not opt in via CORS or CORP, so apply them to a dedicated profiling page rather than the whole application.

A measure that spans a yield is not CPU time

If the compute region contains await, setTimeout, or a nested postMessage round trip, the measure’s duration includes time the worker spent idle. Either place the marks inside each synchronous chunk and sum the durations, or accept the number as end-to-end latency and label it as such.

Performance Note

The number worth carrying out of a profiling session is the ratio of the user-timing band to its enclosing task, not the task duration. On a mid-range laptop, a worker task that spends more than about 30% of its width outside the band is dominated by message overhead, and the highest-value change is the transfer strategy rather than the algorithm — roughly 0.7 ms per megabyte for flat typed arrays, and ten to thirty times that for dense object graphs, in each direction. Below that threshold the algorithm is genuinely the cost, and the Bottom-Up view sorted by Self Time inside the band tells you exactly which frame to attack.