The web has always been a single-threaded environment, with the DOM (Document Object Model) as its central bottleneck. But as applications grow more complex—with heavy data visualizations, sophisticated interactions, physics simulations, and the need to support low-powered devices—this single-threaded constraint becomes a performance liability.

Why Multi-Threaded Rendering Matters

A typical software engineer deals daily with threads, processes, synchronization, race conditions, and context sharing. A typical frontend engineer does not, but to build modern scalable interactive apps, one should.

The DOM remains single-threaded (and may stay that way forever), yet we want to do more with it. Here are scenarios where a single thread becomes a bottleneck:

• Heavy data visualizations and dashboards with multiple visualizations
• Apps with complex and sophisticated interaction patterns
• Interactive infographics
• Physics simulations
• Low-powered devices

The Four Categories of Multi-Threading on the Web

Multi-threading on the web can be classified into four broad categories, each with its own trade-offs and implementations.

1. Compute Only

This is the traditional Web Worker model where computation is distributed to multiple workers, but DOM access remains on the main thread.

Implementations:

• Web Workers and Friends (Shared worker, Service worker)
• AudioWorklet: Run audio processing in a separate thread
• React Worker DOM (Virtual DOM computes in a separate thread)
• WebGPU Compute Shaders

Pros:

• Supported by the platform out-of-the-box
• Workers are lightweight
• Can make HTTP calls

Cons:

• Limited to compute, no access to DOM
• API is a bit clunky in some cases
• Transferring data between workers can be expensive due to serialization
• Cannot transfer functions

Bonus: SharedArrayBuffer and Atomics

The Web Worker message-passing model has a fundamental limitation: data must be copied or transferred between threads. For large datasets, this serialization overhead can negate the benefits of offloading work.

SharedArrayBuffer solves this by allowing multiple threads to read and write to the same memory region. Combined with Atomics for synchronization, you get primitives similar to threads in C++ or Java.

Pros:

• Zero-copy data sharing between threads
• Significant performance gains for large datasets

Cons:

• Only works with typed arrays, not arbitrary objects
• Requires COOP/COEP headers, breaks embedding scenarios
• Still no access to DOM

2. Prioritized Scheduling

Work is rescheduled as per priority, giving a sense of a responsive application while still using a single thread.

Implementations:

• React concurrent mode
• Web Priority Task Scheduling API

Pros:

• Simple to use if you already use the latest React versions

Cons:

• No benefit to initial render performance
• Dependency on React as a framework for everything
• Single threaded, so low-end CPU devices do not benefit
• Reprioritizes existing work; strategy fails when there's just more work to do (like data visualizations)

3. Parallelized Create DOM

A single compute thread (main thread) shares the initial render load across multiple workers, typically server-side processes.

Implementations:

• Facebook: Bigpipe
• Ebay: Async Fragments

Pros:

• Fast initial render performance, as DOM can be precreated on the server

Cons:

• Hydration on the client might be complex/expensive
• No performance benefits beyond the first render
• Need to maintain a server-side DOM implementation
• Not all features are supported in server-side rendering

4. Parallelized Create and Mutate

This category splits into two approaches: Canvas-based and DOM-based parallel rendering.

Canvas-Based Parallel Rendering

With the Offscreen Canvas API (widely available since March 2023), you can create and control a canvas from a Worker.

Implementations:

• Offscreen Canvas with transferControlToOffscreen
• ChartJS Parallel rendering

Pros:

• Create and mutate visual elements from a Worker thread
• Simple API

Cons:

• Canvas is a very low-level API; need to use an abstraction layer
• Not too many feature-rich Canvas libraries exist vs SVG/HTML rendering (React, D3, Highcharts, etc.)
• WebGL/WebGPU support
• Canvas is not responsive; need to redraw when resized
• Need to handle DOM events from the Main thread, as workers do not have DOM access
• Canvas is stateless, so state updates/interactivity requires full redraw vs surgical updates

DOM-Based Parallel Rendering

The DOM is both created and mutated by separate workers. Two approaches make this possible:

Web Worker w/ DOM Worker DOM

Worker DOM library implemented DOM within web workers, with all mutations done within the worker and then periodically synced with the Main DOM.

Pros:

• Performance benefits both for the first render and subsequent mutations
• Uses the familiar WebWorker API

Cons:

• The complexity of maintaining a parallel DOM implementation, which will lag behind the browser's implementation
• Some APIs need a workaround to work
• Some APIs cannot be supported

Parallel DOM via Cross-Origin SubFrames

PDom: Multiprocess DOM via cross-origin Iframes

With the release of performance isolation in Chrome 88, it's now possible to have multiple subframes on a webpage, which might be running in a separate process. The PDoM library tries to exploit this capability by providing an ergonomic abstraction for web developers to use.

Pros:

• Uses the web platform, with a thin abstraction layer
• No new DOM implementation
• All DOM APIs are supported; no need to change the code
• First-class support to parallelize any React component

Cons:

• Need to set up a separate web server with specialized DNS config
• Only supported in Chromium-based browsers (Chrome/Edge) as of today

The Future: Combining Techniques

What we didn't talk about today is that you could also use the above techniques in combination with one another. For example, you could use "Compute only worker threads" with "Parallelized create only" to achieve performance benefits beyond just the initial render.

As web applications continue to push the boundaries of what's possible in the browser, multi-threaded rendering will become increasingly essential. The techniques outlined here represent the current state of the art, but the field is rapidly evolving. What's clear is that the single-threaded DOM bottleneck will need to be addressed through creative use of web platform features, new abstractions, and architectural patterns that distribute work across multiple threads while maintaining the simplicity and safety that web developers expect.

The definitive guide to multi-threaded rendering on the web is still being written, but understanding these approaches and their trade-offs is the first step toward building the next generation of high-performance, scalable web applications.