ReactJs Performance ~ Web Workers for Heavy Computations ~

Source: Dev.to

When Web Workers are useful

• Processing images or videos in the browser
• Handling large datasets (sorting, filtering, transformations)
• Performing CPU‑heavy calculations (e.g., simulations, analytics)
• Parsing large files like CSV, JSON, or XML
• Running cryptographic or hashing operations
• Managing real‑time data streams without blocking the UI

Web Worker implementation example

dataWorker.js

// dataWorker.js
self.addEventListener('message', event => {
  const { items, taskType } = event.data;

  const output = runBackgroundTask(items, taskType);

  self.postMessage({
    status: 'completed',
    result: output,
  });
});

function runBackgroundTask(items, taskType) {
  if (taskType !== 'transform') {
    return items;
  }

  return items.map(item => {
    return applyHeavyTransformation(item);
  });
}

function applyHeavyTransformation(item) {
  // Put CPU‑heavy logic here
  return {
    ...item,
    processed: true,
  };
}

DataProcessor.jsx

// DataProcessor.jsx
import { useEffect, useState } from 'react';

function DataProcessor({ items }) {
  const [result, setResult] = useState([]);
  const [isRunning, setIsRunning] = useState(false);

  useEffect(() => {
    const backgroundWorker = new Worker(
      new URL('./dataWorker.js', import.meta.url)
    );

    backgroundWorker.addEventListener('message', event => {
      setResult(event.data.result);
      setIsRunning(false);
    });

    setIsRunning(true);

    backgroundWorker.postMessage({
      items,
      taskType: 'transform',
    });

    return () => {
      backgroundWorker.terminate();
    };
  }, [items]);

  if (isRunning) {
    return ;
  }

  return ;
}

In this example, the expensive transformation is moved outside the main React rendering flow. The component sends raw data to the worker, waits for the processed result, and keeps the UI responsive while the task runs in the background.

Performance Comparison by Task Type

Things to know before using Web Workers

• Workers cannot directly interact with the DOM.
• Memory is isolated from the main thread (SharedArrayBuffer is an advanced workaround).
• Communication between threads introduces latency (~5–10 ms per message).
• Data must be serialized/deserialized when passing between threads.

When should you actually use them?

A good rule of thumb: If a task takes longer than ~50 ms, it’s a candidate for a Web Worker.
For shorter operations, the cost of message passing can outweigh the performance gains. In those cases, consider:

• requestIdleCallback → run tasks when the browser is idle
• Simple async patterns → avoid blocking rendering

Modern tooling makes it easier

• Vite / Webpack → allow direct worker imports with minimal setup.
• Comlink → abstracts message passing into a simple function‑call‑like API.

These tools reduce boilerplate and simplify integration of background processing into modern frontend applications.

Practical perspective

Use Web Workers selectively. They shine in CPU‑heavy scenarios, but for lightweight tasks, simpler approaches often lead to better overall performance and maintainability.