Rendering with OffscreenCanvas in a Web Worker

A canvas that redraws every frame from the main thread runs its draw calls and 2D rasterization inside the one main-thread task queue, so each frame’s script blocks input dispatch and delays the next requestAnimationFrame — the symptom is a spiking INP and a stuttering animation while the GPU sits mostly idle. This guide is part of Off-Main-Thread Rendering, within Compositing and GPU Acceleration. The fix is to move the drawing surface — and the loop that paints it — onto a worker with OffscreenCanvas and transferControlToOffscreen(), leaving the main thread free to answer clicks and scrolls.

Why a Main-Thread Canvas Steals the Frame Budget

A <canvas> element’s 2D or WebGL context executes wherever the context was created. Create it on the main thread and every fillRect, drawImage, or shader submission is a main-thread instruction, tokenized into the same task that runs your React reconciler, your event listeners, and your layout code. The browser’s event loop is run-to-completion: once a task starts it cannot be interrupted, so a 38ms draw pass holds the thread for more than two frames, and any pointermove or click that arrives mid-draw waits in the queue until the draw finishes. That queued delay is exactly what the Interaction to Next Paint metric measures, which is why a heavy canvas tanks INP even when the animation itself looks smooth in isolation.

Crucially, none of this competes with the compositor for GPU time — it competes for the main thread. The pixels the canvas produces still hand off to the compositor thread the same way a promoted layer does, but the CPU-side work of issuing draw commands and rasterizing them (for a 2D context) is serialized against everything else your page wants to do. You can confirm the starvation with the Long Tasks API: each frame shows up as a >50ms task with the interaction stuck behind it.

Minimal reproduction

The pattern below is the standard “just draw in rAF” loop. It works, it is idiomatic, and on a busy scene it holds the main thread hostage:

// main.js — everything runs on the main thread
const canvas = document.querySelector('#viz')
const ctx = canvas.getContext('2d')

function frame(t) {
  ctx.clearRect(0, 0, canvas.width, canvas.height)
  for (let i = 0; i < 40000; i++) {
    drawParticle(ctx, i, t)   // ❌ every draw call executes in the main-thread task queue
  }
  requestAnimationFrame(frame)
}
requestAnimationFrame(frame)

The for loop is the responsible line: 40,000 drawParticle calls per frame are 40,000 main-thread instructions plus the 2D raster they trigger, all inside one uninterruptible task. Nothing here is a forced synchronous layout — it is pure scripting and painting cost — but the effect on interaction latency is the same: the thread is busy, so the page is unresponsive.

How transferControlToOffscreen Moves Rendering Off-Thread

OffscreenCanvas is a drawing surface that is not tied to the DOM. You obtain one from an existing <canvas> by calling transferControlToOffscreen(), which detaches the element’s backing surface and returns an OffscreenCanvas handle. From that moment the main-thread <canvas> becomes a placeholder: it still occupies its box in layout and still displays whatever the surface contains, but you can no longer call getContext() on it — the surface now lives elsewhere. You post the OffscreenCanvas to a worker inside a message’s transfer list, so it moves by reference rather than being structured-cloned, and the worker calls getContext('2d') (or 'webgl2', or 'webgpu') on it.

Once the context lives on the worker, the render loop lives there too. A worker has its own requestAnimationFrame driven by the same vsync signal, so frame() ticks at display refresh on the worker thread. When the worker draws, the produced bitmap is committed and the compositor picks it up and paints the placeholder — no main-thread involvement per frame. The main thread’s only remaining job is to forward small state deltas (pointer position, resize dimensions, a “pause” flag) via postMessage, which are kilobyte-sized structured clones, not per-frame pixel work.

The trace signature

Captured in the Performance panel, the before/after difference is unmistakable. Before, the whole frame is one long main-thread task with the interaction stranded behind it:

Main thread ▸ Performance (before)
[Task] 41.2ms  ← blocks input for ~2.5 frames
└─ Animation Frame Fired
    └─ Function Call  frame()
        ├─ clearRect              (0.3ms)
        ├─ 40k × drawParticle     (38.6ms)   ← script + 2D raster on the main thread
        └─ paint + composite deferred to end of task
[Event] pointermove  ← arrived at 3ms, dispatched at 41ms → INP = 44ms

After, the draw work is on a Worker track and the main thread only handles the tiny message, so the interaction is answered almost immediately:

Main thread (after)              Worker thread (after)
[Event] pointermove  1.1ms       [Task] Animation Frame Fired
  └─ postMessage (0.2ms)           └─ frame()
                                       └─ 40k × drawParticle  15.9ms
Compositor thread
  └─ Commit + Composite  2.4ms  ← worker frame picked up, no main-thread paint

Note the per-frame draw also got faster (38.6ms → 15.9ms) because the worker thread is not contending with layout, style, and framework work — it has the CPU to itself. The same long-task starvation, viewed per-frame, is easiest to keep an eye on with the long animation frames API.

The Fix: A Dedicated Rendering Worker

The migration is mechanical: transfer the surface, move the loop into a worker file, and reduce the main thread to a message forwarder. Here is the complete before/after.

Before — one file, everything on the main thread:

// main.js (before) — draws on the main thread every frame
const canvas = document.querySelector('#viz')
const ctx = canvas.getContext('2d')     // context lives on the main thread
let pointer = { x: 0, y: 0 }
addEventListener('pointermove', (e) => { pointer = { x: e.clientX, y: e.clientY } })

function frame(t) {
  ctx.clearRect(0, 0, canvas.width, canvas.height)
  for (let i = 0; i < 40000; i++) drawParticle(ctx, i, t, pointer) // blocks the main thread
  requestAnimationFrame(frame)
}
requestAnimationFrame(frame)

After — two files. main.js transfers the surface and forwards input; render-worker.js owns the loop:

// main.js (after) — hand the surface to a worker, then stay out of the way
const canvas = document.querySelector('#viz')
const offscreen = canvas.transferControlToOffscreen() // main thread gives up the surface
const worker = new Worker('./render-worker.js', { type: 'module' })

worker.postMessage(
  { type: 'init', canvas: offscreen, dpr: devicePixelRatio },
  [offscreen], // transfer list: zero-copy handoff, NOT a structured clone
)

// only tiny state deltas cross the boundary now — no per-frame pixels
addEventListener('pointermove', (e) => {
  worker.postMessage({ type: 'pointer', x: e.clientX, y: e.clientY })
})

// render-worker.js (after) — owns the OffscreenCanvas and the render loop
let ctx, pointer = { x: 0, y: 0 }

onmessage = ({ data }) => {
  if (data.type === 'init') {
    ctx = data.canvas.getContext('2d')  // OffscreenCanvas 2D context, on the worker
    requestAnimationFrame(frame)        // worker rAF — driven by the compositor's vsync
  } else if (data.type === 'pointer') {
    pointer = data                      // cheap message, no drawing on the main thread
  }
}

function frame(t) {
  const c = ctx.canvas
  ctx.clearRect(0, 0, c.width, c.height)
  for (let i = 0; i < 40000; i++) drawParticle(ctx, i, t, pointer) // runs on the worker thread
  requestAnimationFrame(frame)          // OffscreenCanvas 2D auto-commits at end of frame
}

A 2D OffscreenCanvas commits its contents automatically when the animation-frame callback returns — there is no manual commit() call in the current specification. The pointer handler still runs on the main thread (input must), but it now does a 0.2ms postMessage instead of 38ms of drawing, so the interaction lands within one frame. Because the drawing moved wholesale, the split of responsibilities across threads is clean:

Mapping the change back to the pipeline shows where each cost went:

One caveat worth internalizing: OffscreenCanvas moves CPU rendering off the main thread, but it does not add GPU capacity. If your bottleneck is actually GPU rasterization or texture upload — common with large WebGL scenes — a worker will not conjure headroom that isn’t there, and you should first check whether you are near the GPU memory limits Chrome enforces on compositing. The win here is specifically about main-thread contention and interaction latency.

Verification

Confirm the migration actually offloaded the work rather than just relocating a bug:

• transferControlToOffscreen() is called exactly once per canvas — a second call throws InvalidStateError.
• The OffscreenCanvas is listed in the transfer array [offscreen], not merely referenced in the message body (otherwise it is cloned, not moved, and detaches nothing).
• No getContext() call remains against the placeholder canvas element on the main thread.
• DevTools Performance shows the draw stack under a Worker track, not the Main track.
• The longest main-thread task during animation is under 50ms (verify with the Long Tasks observer).
• INP under interaction stays under 200ms while the canvas animates continuously.
• The loop uses the worker’s own requestAnimationFrame, so it throttles with tab visibility and matches vsync.
• A feature-detect fallback renders on the main thread where OffscreenCanvas is unavailable.

Frequently Asked Questions

Related Guides

• Off-Main-Thread Rendering — the parent topic covering worker-driven and off-thread rendering strategies.
• Observing Long Tasks with PerformanceObserver — catch the >50ms main-thread tasks that a busy canvas creates.
• Tracking Long Animation Frames — per-frame attribution to confirm the worker offload landed.
• Promoting Layers Safely with translateZ — how the compositor handles the surface the worker commits to.
• GPU Memory Limits in Chrome Compositing — check this when a worker offload does not relieve the frame budget.