OffscreenCanvas and Web Workers: Moving Browser Game Logic Off the Main Thread
You probably think a stuttering browser game is a rendering problem — the GPU is choking, the draw calls are too heavy, the engine needs swapping out. However, the frame you dropped almost never died in the rasterizer; it died waiting in line behind everything else your main thread was asked to do that tick.
The browser hands a game exactly one main thread, and that thread serializes your input handling, your physics step, your requestAnimationFrame callbacks, your garbage collection, and any DOM layout into a single queue. When one of those jobs overruns the ~16.6ms budget of a 60fps frame, the next frame is already late before a single pixel reaches the screen.
This piece is about relocating the two heaviest offenders — simulation and rendering — onto Web Workers using OffscreenCanvas, and doing it without paying the input-latency tax that naive worker setups quietly introduce. It is a threading problem, not a renderer problem, which is why swapping your draw API rarely fixes it on its own.
Browser games drop frames when the main thread misses its roughly 16.6ms budget at 60fps, because input handling, physics, animation callbacks, garbage collection, and DOM layout all share that single thread. When any one job overruns, the next frame is already late before rendering even starts.
Why The Main Thread Becomes The Bottleneck
Every browser tab runs your JavaScript, your style and layout recalculation, and your event dispatch on one thread by design. The compositor and raster work happen elsewhere, but the logic that decides what to draw — your game loop — does not.
That means a single expensive collision pass, a large allocation that triggers a garbage-collection pause, or a synchronous layout read can blow the frame for reasons that have nothing to do with your renderer. Keep in mind that the GPU can be almost idle while your game stutters, because the bottleneck sits upstream of it.
Whichever rendering path you chose — and we covered that decision in depth in our canvas-versus-WebGL renderer comparison — it still executes inside that same contended queue while it lives on the main thread. Moving the renderer to a worker changes which thread owns the draw, not which API draws.
What OffscreenCanvas Actually Moves
OffscreenCanvas is a canvas surface decoupled from the DOM, which is the property that lets a worker own it. A normal <canvas> element is tied to the document, and the document only exists on the main thread.
You take a regular canvas, call transferControlToOffscreen() on it, and hand the resulting object to a worker through postMessage with a transfer list. From that point the worker holds a 2D, WebGL, or WebGPU context against that surface and draws to it directly, while the main thread keeps the on-screen element it can no longer paint to itself.
OffscreenCanvas is a canvas rendering surface decoupled from the DOM, which is the property that lets a Web Worker own and draw to it instead of the main thread. You call transferControlToOffscreen() on a regular canvas, post the handle to a worker, and from there every draw happens off the main thread.
Note that the same approach works whether you draw with the 2D context, raw WebGL, a three.js scene, or a WebGPU-based browser renderer. The transfer mechanism is identical; only the context you request from the OffscreenCanvas differs.
What A Worker Cannot Touch
The worker boundary is a hard wall around the DOM, and that wall shapes every decision that follows. A worker has no document, no window layout, and no access to CSS, which is why input and HTML overlays stay on the main thread.
A worker has no DOM access, so you cannot read CSS layout, touch the document, or use any API bound to window — including the input events themselves, which must stay on the main thread. OffscreenCanvas, fetch, WebGL, WebGPU, SharedArrayBuffer, and most timers all work inside a worker.
In practice this draws a clean seam through your codebase. Rendering, simulation, networking, and asset decoding move into workers, while a thin main-thread shell owns the canvas element, the input listeners, and any HTML UI layered over the game.
How To Hand A Canvas To A Worker
The handoff is two steps and one constraint. First, on the main thread, you detach the canvas drawing surface; second, inside the worker, you accept that surface and request a context from it.
The constraint is that transferControlToOffscreen() is a one-way move — once transferred, the main thread can no longer get a context from that element. For instance, calling getContext() on the original canvas after the transfer throws, which is the correct mental model: ownership left the building.
Here is the sequence the two sides follow:
- Detach on the main thread. Call const offscreen = canvas.transferControlToOffscreen(), then worker.postMessage({ canvas: offscreen }, [offscreen]) so the surface is transferred rather than copied.
- Receive in the worker. In the worker onmessage handler, pull the canvas off the event data and call getContext('webgl2') or getContext('2d') against it.
- Drive the loop in the worker. Run requestAnimationFrame inside the worker — it exists there — so the render loop ticks on the worker timeline, not the main thread.
That last point is the one people miss. requestAnimationFrame is available inside a worker that owns an OffscreenCanvas, so your entire draw loop relocates rather than being remote-controlled frame by frame from the main thread.
Where The Input-Latency Tradeoff Hides
This is the part that sinks naive implementations. Input events — keydown, pointermove, gamepad polling — fire on the main thread, because they are DOM events and the DOM only lives there.
So the moment your simulation moves to a worker, every input has to cross a thread boundary to reach the code that consumes it. If you forward each event with its own postMessage, you have added a serialize-queue-deserialize hop between the player's finger and the game state, and under load that hop lands exactly when the main thread is busiest.
Not if you architect it correctly, though input events still fire on the main thread, so the risk is adding a postMessage hop between the keypress and the simulation that consumes it. Forwarding raw events into a SharedArrayBuffer ring the worker polls each tick keeps that hop under a frame and avoids the latency penalty.
The fix is to stop sending messages and start sharing memory. You allocate a SharedArrayBuffer, write each input event into a small lock-free ring buffer from the main thread, and let the simulation worker drain that ring at the top of every tick.
That converts a scheduled, queued message into a plain memory read the worker performs on its own schedule. The main-thread handler does almost nothing — it writes a few integers into a typed array — so it stays cheap even when the rest of the page is thrashing.
If you are already buffering and de-jittering input for responsiveness, this slots directly into that layer; our breakdown of input buffering for browser games covers the consumption side that pairs with this transport.
Splitting Simulation From Rendering
One worker is often enough. For a game whose per-frame logic comfortably fits the budget, moving the whole loop — input drain, simulation, and draw — into a single worker removes the contention and you are done.
Physics-heavy titles want a second split. Here you run a fixed-timestep simulation worker that advances the world at a stable rate, say 60 or 120 Hz, and a separate render worker that interpolates between the two most recent states and draws at the display refresh rate.
For simple games one worker is enough, but physics-heavy titles should split them, with a fixed-timestep simulation worker writing state into a SharedArrayBuffer and a separate render worker interpolating and drawing from it. The split lets simulation run at a stable rate while rendering tracks the display refresh independently.
The two workers communicate through the same primitive you used for input: shared memory. The simulation writes positions, velocities, and entity flags into a SharedArrayBuffer double buffer, and the render worker reads whichever buffer is complete, so neither thread blocks on the other.
This is the same decoupling principle behind a fixed-timestep loop on a single thread, but now the simulation rate is genuinely insulated from rendering hitches. A dropped render frame no longer drags the physics clock with it, which is what kept your collision behavior deterministic in the first place.
If your simulation is heavy enough to want native-speed math, this is also where compiling the hot loop to WebAssembly pays off — see our look at WebAssembly game engines for where that line sits. The worker boundary and the wasm boundary compose cleanly, since wasm runs inside the worker just as it does on the main thread.
Three Architectures, Compared
The right choice depends on how heavy your simulation is and how much input latency your genre tolerates. The table below maps the three common arrangements against the tradeoffs that actually decide between them.
| Architecture | Main-thread load | Input latency | Best for |
|---|---|---|---|
| Main thread only | High — everything competes | Lowest, no hop | Prototypes, light puzzle and UI games |
| Single worker + OffscreenCanvas | Low — input dispatch only | Low if input shares memory | Most action games and side-scrollers |
| Two workers + SharedArrayBuffer | Low — input dispatch only | Low, decoupled from render hitches | Physics-heavy, deterministic sims |
Notice that input latency is not worst in the worker setups — it is worst when you forward input by message instead of by shared memory. The architecture is not the variable that hurts you; the transport is.
How Do You Know It Actually Worked?
Average FPS is the wrong number, because it hides exactly the stutter you set out to remove. A loop that runs at 60fps for 58 frames and stalls for two will report a healthy average and still feel broken.
Record a Chrome DevTools Performance trace and read the main-thread track, which after the move should show almost nothing but requestAnimationFrame, input dispatch, and the occasional garbage collection, with long tasks gone. Measure P95 frame time and dropped-frame count before and after rather than average FPS, which hides exactly the stutter you removed.
Open the Chrome DevTools Performance panel and record a few seconds of real play. Before the move, the main-thread track is a wall of scripting; after it, that track should be mostly idle with input dispatch and the occasional garbage collection, while the worker tracks carry simulation and draw.
Watch three numbers specifically. Long tasks over 50ms should vanish from the main thread, P95 and P99 frame time should converge toward your budget, and the dropped-frame count from the Frame Timing data should fall.
The PerformanceObserver API reports long tasks programmatically, so you can assert against them in a perf test rather than eyeballing a flame chart. That turns 'it feels smoother' into a regression you can actually fail a build on.
Moving The Work Is The Easy Half
The mechanics here are small — a transfer call, a shared buffer, a worker that owns its loop. The hard half is the architecture around them: where the input ring lives, how state is double-buffered, and how you prove the stutter is gone rather than relocated.
If you are scoping a browser game and deciding how to thread simulation and rendering before you commit to an engine, the team at iSimplifyMe builds and operates production real-time web systems across rendering, networking, and state-sync layers every week. Reach out for a working session — we will map your frame budget, name the threading and input-latency failure modes you are about to hit, and leave you with a deployable architecture for getting the logic off the main thread.
Frequently Asked Questions
Is OffscreenCanvas supported across browsers in 2026?
Yes. OffscreenCanvas has stable support in Chrome, Edge, Firefox, and Safari, including WebGL and WebGPU contexts inside workers. SharedArrayBuffer requires cross-origin isolation — you must serve the page with COOP and COEP headers — so confirm those headers are set before relying on the shared-memory input path.
Can I use three.js or Babylon.js inside a worker?
Yes, both render against an OffscreenCanvas WebGL or WebGPU context inside a worker, since neither library needs the DOM to draw. You do lose direct access to DOM-based controls and CSS overlays, so any HUD built from HTML elements stays on the main thread and talks to the worker through messages or shared memory.
Do I still need requestAnimationFrame if rendering is in a worker?
Yes, and you call it inside the worker. requestAnimationFrame exists in the worker scope when that worker owns an OffscreenCanvas, and it stays synchronized to the display refresh. Using it keeps your draw cadence tied to vsync rather than a setInterval timer that drifts and tears.
What happens to audio when the game loop moves off the main thread?
Web Audio scheduling stays on the main thread, so the worker signals audio events through messages or shared flags that a thin main-thread layer reads and schedules. Because Web Audio uses its own high-precision clock, you schedule sounds slightly ahead of time rather than at the instant of the event, which absorbs the small messaging delay.
Is the message-passing version ever good enough on its own?
For turn-based games, menus, and slow simulations, plain postMessage between main thread and worker is fine and far simpler than shared memory. The SharedArrayBuffer ring matters when input-to-state latency is felt every frame, in fast action, fighting, and twitch genres. Match the transport to how tight your input loop needs to be.
