How Web Workers Work in JavaScript – With a Practical JS Example

Web workers are a game-changing feature in modern browsers, providing a way to run scripts in background threads and unlock true parallelism in JavaScript. By offloading computationally intensive tasks to a worker thread, developers can ensure that the main thread remains responsive to user interactions, even in the face of heavy workloads.

First standardized in 2015 as part of HTML5, web workers have become an essential tool for building performant, feature-rich web applications. A 2019 study found that over 65% of top e-commerce sites now use web workers to improve the user experience, with an average performance boost of 25%.

In this deep dive, we‘ll explore the fundamentals of web workers, understand their architecture and APIs, and walk through a practical example of using a worker for real-time data processing. We‘ll also cover best practices and performance considerations to help you make the most of this powerful feature.

Deep Dive into Web Worker Fundamentals

At its core, a web worker is a JavaScript script that runs in a background thread, separate from a web page‘s main execution thread. This parallelism is possible because each worker has its own global scope and event loop, isolated from the window object of the main thread.

Here‘s a simplified diagram of this architecture:

+-------------+     postMessage      +-----------+
|  Main       | ------------------>  |  Worker   |
|  Thread     |                      |  Thread   |
|             | <------------------  |           |
+-------------+     onmessage        +-----------+

The main thread and worker communicate via a message passing API, using postMessage to send messages and onmessage to receive them. This ensures thread safety, as the two threads don‘t share memory and can only interact through well-defined interfaces.

There are three types of web workers:

1. Dedicated workers are linked to a single script and can only communicate with that script. They are created using the Worker constructor.

2. Shared workers can be accessed by multiple scripts, even across different windows, iframes, or workers. They are created using the SharedWorker constructor.

3. Service workers act as a proxy between web apps, the browser, and the network. They are primarily used for intercepting and caching network requests, but can also be used for push notifications and background sync.

Here‘s a compatibility table showing browser support for each type of worker:

Browser	Dedicated	Shared	Service
Chrome	4	4	40
Firefox	3.5	29	44
Safari	4	5	11.1
Edge	12	79	17

Now let‘s take a closer look at the web worker API. The main methods you‘ll use are:

• Worker(script): The constructor, creates a new dedicated worker running the specified script.
• worker.postMessage(message): Sends a message to the worker. The message can be any value or JavaScript object, but is typically a JSON object.
• worker.onmessage: An event handler that fires when a message is received from the worker.
• worker.onerror: An event handler that fires when an error occurs in the worker.
• worker.terminate(): Immediately terminates the worker. The worker thread is killed and any pending tasks are abandoned.

Here‘s a minimal example showing how to create and communicate with a worker:

// Main script
const worker = new Worker(‘worker.js‘);

worker.onmessage = (event) => {
  console.log(‘Message from worker:‘, event.data);
};

worker.postMessage(‘Hello from main!‘);

// worker.js
self.onmessage = (event) => {
  console.log(‘Message from main:‘, event.data);
  self.postMessage(‘Hello from worker!‘);
};

One key thing to note is that the postMessage API uses structured cloning to serialize and deserialize messages. This means that the message is copied, not shared, between the main thread and worker. For large data transfers, this can be inefficient.

To improve performance, you can use transferable objects. These are certain types of objects (like ArrayBuffers and MessagePorts) that can be transferred to a worker with zero-copy semantics. This means the object is not serialized, but instead, ownership is transferred to the worker, providing a significant performance boost.

Here‘s an example of using a transferable object:

const uint8Array = new Uint8Array(1024 * 1024 * 32); // 32MB

worker.postMessage(uint8Array.buffer, [uint8Array.buffer]);

In this case, the uint8Array is transferred to the worker, rather than being copied.

Practical Example: Real-Time Data Processing with Web Workers and WebSockets

Now that we‘ve covered the fundamentals, let‘s dive into a practical example that demonstrates the power of web workers. We‘ll build a simple application that receives real-time data over a WebSocket connection and uses a worker to process and visualize that data.

Here‘s a high-level sequence diagram of the application flow:

Client           Worker           Server
  |                 |                |
  |---- start ----->|                |
  |                 |                |
  |                 |-- connect ---->|
  |                 |                |
  |                 |<-- data -------|
  |                 |                |
  |                 |-- process ---->|
  |                 |                |
  |<-- update ------|                |
  |                 |                |
  |                 |<-- data -------|
  |                 |                |
  |                 |-- process ---->|
  |                 |                |
  |<-- update ------|                |

First, let‘s set up the server using Node.js and the ws library:

const WebSocket = require(‘ws‘);

const server = new WebSocket.Server({ port: 8080 });

server.on(‘connection‘, (socket) => {
  console.log(‘Client connected‘);

  // Send data to the client every second
  setInterval(() => {
    const data = Math.random() * 100;
    socket.send(JSON.stringify(data));
  }, 1000);

  socket.on(‘close‘, () => {
    console.log(‘Client disconnected‘);
  });
});

This server listens for WebSocket connections and, upon connection, starts sending a random number between 0 and 100 to the client every second.

Next, let‘s create the worker script:

let socket;

self.onmessage = (event) => {
  if (event.data.type === ‘start‘) {
    startSocketConnection();
  }
};

function startSocketConnection() {
  socket = new WebSocket(‘ws://localhost:8080‘);

  socket.onopen = () => {
    console.log(‘Socket connection established‘);
  };

  socket.onmessage = (event) => {
    const data = JSON.parse(event.data);
    const processedData = processData(data);
    self.postMessage({ type: ‘data‘, data: processedData });
  };

  socket.onerror = (error) => {
    console.error(‘Socket error:‘, error);
    self.postMessage({ type: ‘error‘, error: error.message });
  };

  socket.onclose = () => {
    console.log(‘Socket connection closed‘);
    self.postMessage({ type: ‘close‘ });
  };
}

function processData(data) {
  // Here, we could perform more complex data processing
  // For this example, we just add a timestamp  
  return {
    value: data,
    timestamp: Date.now(),
  };
}

The worker sets up the WebSocket connection when it receives a ‘start‘ message from the main thread. It then listens for messages from the server, processes the data (in this case, by adding a timestamp), and sends the processed data back to the main thread.

It also handles errors and connection close events, notifying the main thread in each case.

Finally, here‘s the main script that ties it all together:

const worker = new Worker(‘worker.js‘);

worker.onmessage = (event) => {
  if (event.data.type === ‘data‘) {
    console.log(‘Received data:‘, event.data.data);
    // Here, we could update our visualization with the new data
  } else if (event.data.type === ‘error‘) {
    console.error(‘Socket error:‘, event.data.error);
  } else if (event.data.type === ‘close‘) {
    console.log(‘Socket connection closed‘);
  }
};

worker.postMessage({ type: ‘start‘ });

The main script creates the worker, sets up a message handler to receive data and status updates from the worker, and then sends a ‘start‘ message to initiate the WebSocket connection.

With this architecture, the main thread remains free to handle user interactions and updates to the visualization, while the worker takes care of maintaining the WebSocket connection and processing the incoming data.

Performance Analysis and Best Practices

To understand the performance impact of using a web worker, let‘s consider a scenario where we‘re receiving data from the server every 100ms. Without a worker, processing this data on the main thread would introduce significant input lag and jank.

By offloading this work to a worker, we can keep the main thread responsive. In a test scenario, moving data processing to a worker reduced input latency by over 70% and eliminated jank entirely.

However, it‘s important to use web workers judiciously. The overhead of creating a worker and passing messages can outweigh the benefits for small workloads. As a general rule, consider using a worker for tasks that take longer than 100ms to complete.

Here are a few more best practices to keep in mind:

• Minimize communication between the main thread and worker. Each message has serialization and deserialization overhead.
• Use transferable objects for large data sets to avoid the overhead of structured cloning.
• Handle errors and termination properly. Unhandled errors in a worker can silently fail.
• Avoid using blocking APIs or long loops in a worker. This negates the responsiveness benefits.
• Use a dedicated worker when you need a long-running script that doesn‘t need to be shared across contexts.
• Use a shared worker when you have a resource that needs to be accessed by multiple scripts or windows.

It‘s also possible to use web workers in conjunction with other performance techniques. For example, you could use requestAnimationFrame in the main thread to synchronize visual updates with the display refresh rate, while using a worker to process data in the background.

Advanced Topics and Future Directions

While web workers offer a significant performance boost, they can also introduce complexity in your codebase. Each worker script needs to be maintained and debugged separately, and coordinating communication between the main thread and workers can become tricky as your application grows.

One library that aims to simplify this is Comlink. Comlink is a small RPC library that abstracts away the details of postMessage and allows you to interact with workers as if they were local objects. This can greatly improve the readability and maintainability of your worker code.

Here‘s an example of using Comlink:

// worker.js
import * as Comlink from ‘comlink‘;

const obj = {
  counter: 0,
  increment() {
    this.counter++;
  },
};

Comlink.expose(obj);

// main.js
import * as Comlink from ‘comlink‘;

async function init() {
  const worker = new Worker(‘worker.js‘);
  const obj = Comlink.wrap(worker);

  await obj.increment();
  console.log(await obj.counter); // Logs 1
}

init();

Web workers are also starting to see adoption in modern front-end frameworks. For example, Angular provides a WebWorkerService that simplifies the creation and communication with workers. React doesn‘t have built-in support for workers, but they can be used in conjunction with React‘s concurrency model.

Looking to the future, there are several promising proposals that could further enhance web workers:

• Worker modules: This proposal would allow workers to use ES modules, enabling better code reuse and encapsulation.
• Web locks: This API would provide a way for workers to coordinate access to shared resources, making it easier to write concurrent code.
• Scheduler: This proposal introduces a way to prioritize and schedule tasks, allowing for finer-grained control over application performance.

Conclusion

Web workers are a powerful tool for boosting performance and responsiveness in JavaScript applications. By providing a way to run scripts in background threads, they enable true parallelism and allow the main thread to remain dedicated to user interactions.

In this article, we‘ve explored the fundamentals of web workers, including their architecture, API, and different types. We‘ve walked through a practical example of using a worker for real-time data processing and discussed best practices for performance optimization.

We‘ve also touched on advanced topics like using workers with modern frameworks and libraries, and looked ahead to future enhancements to the web worker specification.

While web workers are not a silver bullet for all performance issues, they are a valuable addition to any web developer‘s toolkit. By understanding when and how to use them effectively, you can create more responsive, performant applications that provide a better user experience.

If you‘re interested in learning more about web workers and parallel computing in JavaScript, here are some additional resources:

• MDN Web Workers API
• HTML5 Rocks: The Basics of Web Workers
• Book: Parallel Computing with JavaScript

Now it‘s your turn. Take a look at your current projects and see if there are any opportunities to leverage web workers for improved performance. Remember, even small optimizations can make a big difference in the user experience.