Multithreading in Modern Web Apps: Web Workers, Transferable Objects, and SharedArrayBuffer

JavaScript in the browser runs on a single-threaded Event Loop. That single thread handles user input events, CSS animation style recalculations, DOM layout rendering, repaints, and your JavaScript application logic.

If a synchronous operation takes longer than 16.6 milliseconds, your frame rate drops below 60 FPS, causing frozen animations, unresponsive buttons, and poor core web vitals.

Web Workers provide true multithreading in modern web browsers, enabling background processing without locking up the UI.

In this guide, we will explore Web Worker types, zero-copy memory transfers with Transferable Objects, build a typed RPC worker wrapper, and offload CPU-heavy data parsing.

1. Main Thread Bottlenecks & The 16.6ms Budget

To maintain a fluid 60 frames per second (FPS) experience, the browser has a strict budget per frame:

Frame Budget = 1000ms / 60fps ≈ 16.67ms

If JavaScript executes a long-running loop (e.g., parsing a 50MB CSV file or processing image pixels), the main thread is blocked. Hover effects fail, scroll events queue up, and the browser displays the infamous "Page Unresponsive" popup.

code

Main Thread:   [ JavaScript Task (300ms) ] ───► DOM Paint Blocked! (Jank)
               ▲ User Clicks Button here (Ignored until JS task finishes)

Worker Thread: [ Heavy Calculation (300ms) ]
               ▲ Runs parallel on background CPU Core ───► Main Thread UI Stays at 60 FPS!

2. Dedicated vs. Shared vs. Service Workers

Web Workers come in three main varieties:

Dedicated Web Workers: Created by a single script execution context. Owned by a single browser tab and terminated when the tab closes.
Shared Workers: Accessible across multiple browser tabs, windows, or iframe instances under the same origin domain. Great for multi-tab state sync.
Service Workers: Act as programmable network proxies for offline caching, push notifications, and background sync.

3. Memory Overhead & Zero-Copy Transferable Objects

By default, passing data between the main thread and a Web Worker via postMessage() uses the Structured Clone Algorithm.

The browser serializes the object into a binary format and deserializes it inside the worker context. For a 100MB typed array, cloning creates a 100MB copy, doubling memory usage and wasting 50ms+ in CPU cloning overhead!

Zero-Copy Transferable Objects

Transferable Objects transfer ownership of the underlying memory buffer instantly (O(1) time complexity) without copying memory:

Supported transferable types: ArrayBuffer, MessagePort, ReadableStream, WritableStream, OffscreenCanvas, ImageBitmap.

typescript

// Main Thread Example
const hugeBuffer = new Float64Array(10_000_000).buffer; // ~80MB ArrayBuffer

console.log(hugeBuffer.byteLength); // 80,000,000 bytes

// Pass hugeBuffer in the transfer list (2nd parameter)
worker.postMessage({ type: 'PROCESS_DATA', buffer: hugeBuffer }, [hugeBuffer]);

// ⚠️ ZERO-COPY RESULT: hugeBuffer is detached on the main thread!
console.log(hugeBuffer.byteLength); // 0 bytes! Memory was transferred to Worker.

4. Building a Typed RPC Web Worker Wrapper

Raw postMessage and onmessage listeners can get messy quickly. We can abstract worker communication into a promise-based RPC (Remote Procedure Call) interface:

Step 1: `worker.ts` (The Background Worker)

typescript

// web-worker.ts
self.onmessage = (event: MessageEvent<{ id: string; action: string; payload: any }>) => {
  const { id, action, payload } = event.data;

  if (action === 'PARSE_CSV') {
    try {
      const lines = payload.csvString.split('\n');
      const parsedData = lines.map((line: string) => line.split(','));

      // Send result back with matching request id
      self.postMessage({ id, success: true, result: parsedData });
    } catch (err: any) {
      self.postMessage({ id, success: false, error: err.message });
    }
  }
};

Step 2: `WorkerRPC.ts` (Main Thread RPC Bridge)

typescript

export class WorkerRPC {
  private worker: Worker;
  private pendingRequests = new Map<
    string,
    { resolve: (val: any) => void; reject: (err: Error) => void }
  >();

  constructor(workerScriptUrl: string) {
    this.worker = new Worker(workerScriptUrl, { type: 'module' });
    this.worker.onmessage = this.handleMessage.bind(this);
  }

  private handleMessage(event: MessageEvent) {
    const { id, success, result, error } = event.data;
    const request = this.pendingRequests.get(id);

    if (request) {
      if (success) {
        request.resolve(result);
      } else {
        request.reject(new Error(error));
      }
      this.pendingRequests.delete(id);
    }
  }

  public exec<T>(action: string, payload: any, transferables: Transferable[] = []): Promise<T> {
    return new Promise((resolve, reject) => {
      const id = crypto.randomUUID();
      this.pendingRequests.set(id, { resolve, reject });
      this.worker.postMessage({ id, action, payload }, transferables);
    });
  }

  public terminate() {
    this.worker.terminate();
  }
}

5. Usage in a React / Next.js Component

tsx

import { useState } from 'react';
import { WorkerRPC } from './WorkerRPC';

export default function HeavyParserComponent() {
  const [status, setStatus] = useState<string>('Idle');
  const [recordCount, setRecordCount] = useState<number>(0);

  const handleFileUpload = async (e: React.ChangeEvent<HTMLInputElement>) => {
    const file = e.target.files?.[0];
    if (!file) return;

    setStatus('Processing on Worker thread...');

    // Instantiate worker RPC
    const workerRPC = new WorkerRPC('/workers/csv-parser.worker.js');
    const text = await file.text();

    const startTime = performance.now();
    
    // Execute off-main-thread!
    const parsedRows = await workerRPC.exec<string[][]>('PARSE_CSV', { csvString: text });
    
    const duration = (performance.now() - startTime).toFixed(2);
    setStatus(`Parsed ${parsedRows.length} rows in ${duration}ms without dropping frames!`);
    setRecordCount(parsedRows.length);

    workerRPC.terminate();
  };

  return (
    <div className="p-6 rounded-lg bg-zinc-900 border border-zinc-800 text-white">
      <h3 className="text-xl font-bold mb-4">Background Worker CSV Parser</h3>
      <input type="file" accept=".csv" onChange={handleFileUpload} />
      <p className="mt-4 text-zinc-400">{status}</p>
      {recordCount > 0 && <p className="text-green-400">Total Records: {recordCount}</p>}
    </div>
  );
}

Summary Best Practices

Keep main thread light: Offload any computational task taking >10ms to Web Workers.
Use Transferables for big data: Pass ArrayBuffer instances in the transfer array to avoid memory cloning delays.
Wrap workers in RPC: Use promise wrappers (or libraries like comlink) to keep worker messaging clean.
Isolate Worker scope: Web Workers do not have access to the DOM (window, document). Perform calculations in the worker and update the DOM on the main thread.

If a synchronous operation takes longer than 16.6 milliseconds, your frame rate drops below 60 FPS, causing frozen animations, unresponsive buttons, and poor core web vitals.

Web Workers provide true multithreading in modern web browsers, enabling background processing without locking up the UI.

In this guide, we will explore Web Worker types, zero-copy memory transfers with Transferable Objects, build a typed RPC worker wrapper, and offload CPU-heavy data parsing.

1. Main Thread Bottlenecks & The 16.6ms Budget

To maintain a fluid 60 frames per second (FPS) experience, the browser has a strict budget per frame:

Frame Budget = 1000ms / 60fps ≈ 16.67ms

code

Main Thread:   [ JavaScript Task (300ms) ] ───► DOM Paint Blocked! (Jank)
               ▲ User Clicks Button here (Ignored until JS task finishes)

Worker Thread: [ Heavy Calculation (300ms) ]
               ▲ Runs parallel on background CPU Core ───► Main Thread UI Stays at 60 FPS!

2. Dedicated vs. Shared vs. Service Workers

Web Workers come in three main varieties:

Dedicated Web Workers: Created by a single script execution context. Owned by a single browser tab and terminated when the tab closes.
Shared Workers: Accessible across multiple browser tabs, windows, or iframe instances under the same origin domain. Great for multi-tab state sync.
Service Workers: Act as programmable network proxies for offline caching, push notifications, and background sync.

3. Memory Overhead & Zero-Copy Transferable Objects

By default, passing data between the main thread and a Web Worker via postMessage() uses the Structured Clone Algorithm.

Zero-Copy Transferable Objects

Transferable Objects transfer ownership of the underlying memory buffer instantly (O(1) time complexity) without copying memory:

Supported transferable types: ArrayBuffer, MessagePort, ReadableStream, WritableStream, OffscreenCanvas, ImageBitmap.

typescript

// Main Thread Example
const hugeBuffer = new Float64Array(10_000_000).buffer; // ~80MB ArrayBuffer

console.log(hugeBuffer.byteLength); // 80,000,000 bytes

// Pass hugeBuffer in the transfer list (2nd parameter)
worker.postMessage({ type: 'PROCESS_DATA', buffer: hugeBuffer }, [hugeBuffer]);

// ⚠️ ZERO-COPY RESULT: hugeBuffer is detached on the main thread!
console.log(hugeBuffer.byteLength); // 0 bytes! Memory was transferred to Worker.

4. Building a Typed RPC Web Worker Wrapper

Raw postMessage and onmessage listeners can get messy quickly. We can abstract worker communication into a promise-based RPC (Remote Procedure Call) interface:

Step 1: `worker.ts` (The Background Worker)

typescript

// web-worker.ts
self.onmessage = (event: MessageEvent<{ id: string; action: string; payload: any }>) => {
  const { id, action, payload } = event.data;

  if (action === 'PARSE_CSV') {
    try {
      const lines = payload.csvString.split('\n');
      const parsedData = lines.map((line: string) => line.split(','));

      // Send result back with matching request id
      self.postMessage({ id, success: true, result: parsedData });
    } catch (err: any) {
      self.postMessage({ id, success: false, error: err.message });
    }
  }
};

Step 2: `WorkerRPC.ts` (Main Thread RPC Bridge)

typescript

export class WorkerRPC {
  private worker: Worker;
  private pendingRequests = new Map<
    string,
    { resolve: (val: any) => void; reject: (err: Error) => void }
  >();

  constructor(workerScriptUrl: string) {
    this.worker = new Worker(workerScriptUrl, { type: 'module' });
    this.worker.onmessage = this.handleMessage.bind(this);
  }

  private handleMessage(event: MessageEvent) {
    const { id, success, result, error } = event.data;
    const request = this.pendingRequests.get(id);

    if (request) {
      if (success) {
        request.resolve(result);
      } else {
        request.reject(new Error(error));
      }
      this.pendingRequests.delete(id);
    }
  }

  public exec<T>(action: string, payload: any, transferables: Transferable[] = []): Promise<T> {
    return new Promise((resolve, reject) => {
      const id = crypto.randomUUID();
      this.pendingRequests.set(id, { resolve, reject });
      this.worker.postMessage({ id, action, payload }, transferables);
    });
  }

  public terminate() {
    this.worker.terminate();
  }
}

5. Usage in a React / Next.js Component

tsx

import { useState } from 'react';
import { WorkerRPC } from './WorkerRPC';

export default function HeavyParserComponent() {
  const [status, setStatus] = useState<string>('Idle');
  const [recordCount, setRecordCount] = useState<number>(0);

  const handleFileUpload = async (e: React.ChangeEvent<HTMLInputElement>) => {
    const file = e.target.files?.[0];
    if (!file) return;

    setStatus('Processing on Worker thread...');

    // Instantiate worker RPC
    const workerRPC = new WorkerRPC('/workers/csv-parser.worker.js');
    const text = await file.text();

    const startTime = performance.now();
    
    // Execute off-main-thread!
    const parsedRows = await workerRPC.exec<string[][]>('PARSE_CSV', { csvString: text });
    
    const duration = (performance.now() - startTime).toFixed(2);
    setStatus(`Parsed ${parsedRows.length} rows in ${duration}ms without dropping frames!`);
    setRecordCount(parsedRows.length);

    workerRPC.terminate();
  };

  return (
    <div className="p-6 rounded-lg bg-zinc-900 border border-zinc-800 text-white">
      <h3 className="text-xl font-bold mb-4">Background Worker CSV Parser</h3>
      <input type="file" accept=".csv" onChange={handleFileUpload} />
      <p className="mt-4 text-zinc-400">{status}</p>
      {recordCount > 0 && <p className="text-green-400">Total Records: {recordCount}</p>}
    </div>
  );
}

Summary Best Practices

Keep main thread light: Offload any computational task taking >10ms to Web Workers.
Use Transferables for big data: Pass ArrayBuffer instances in the transfer array to avoid memory cloning delays.
Wrap workers in RPC: Use promise wrappers (or libraries like comlink) to keep worker messaging clean.
Isolate Worker scope: Web Workers do not have access to the DOM (window, document). Perform calculations in the worker and update the DOM on the main thread.

Multithreading in Modern Web Apps: Web Workers, Transferable Objects, and SharedArrayBuffer

1. Main Thread Bottlenecks & The 16.6ms Budget

2. Dedicated vs. Shared vs. Service Workers

3. Memory Overhead & Zero-Copy Transferable Objects

Zero-Copy Transferable Objects

4. Building a Typed RPC Web Worker Wrapper

Step 1: `worker.ts` (The Background Worker)

Step 2: `WorkerRPC.ts` (Main Thread RPC Bridge)

5. Usage in a React / Next.js Component

Summary Best Practices

Understanding DOM Events: Event Bubbling, Event Capturing, and Event Delegation

Demystifying React Fiber: Architecture, Work Loop, and Concurrency

Multithreading in Modern Web Apps: Web Workers, Transferable Objects, and SharedArrayBuffer

1. Main Thread Bottlenecks & The 16.6ms Budget

2. Dedicated vs. Shared vs. Service Workers

3. Memory Overhead & Zero-Copy Transferable Objects

Zero-Copy Transferable Objects

4. Building a Typed RPC Web Worker Wrapper

Step 1: `worker.ts` (The Background Worker)

Step 2: `WorkerRPC.ts` (Main Thread RPC Bridge)

5. Usage in a React / Next.js Component

Summary Best Practices

Understanding DOM Events: Event Bubbling, Event Capturing, and Event Delegation

Demystifying React Fiber: Architecture, Work Loop, and Concurrency