Offload CPU-intensive work to a Web Worker and explain communication.

WHAT THIS TESTS: The interviewer wants to know if you understand the browser's single-threaded event loop and how CPU-bound work blocks the main thread, causing frame drops and an unresponsive UI. They are checking whether you know the Web Workers API as the standard primitive for true multi-threading in the browser, and whether you grasp the structured clone communication model, worker scope limitations, and lifecycle management including termination.

A GOOD ANSWER COVERS: First, instantiate a dedicated worker in the main script using new Worker(url) where the URL points to a separate JavaScript file containing the heavy logic. Second, explain that the worker runs on a background thread with its own event loop, so the main thread remains free for user input, layout, and painting. Third, describe the bidirectional message channel: the main thread calls worker.postMessage(data) to send input, and the worker calls self.postMessage(result) to return output; both sides listen via the onmessage event handler whose event.data property contains the payload. Fourth, note that data is copied using the structured clone algorithm, meaning functions and DOM nodes cannot be sent, but most plain objects, arrays, and TypedArrays work fine. Fifth, mention cleanup by calling worker.terminate() or allowing the worker to close itself when finished.

COMMON WRONG ANSWERS: A major red flag is suggesting that the worker can directly access the DOM or call window.alert because the global scope inside a dedicated worker is DedicatedWorkerGlobalScope, not Window. Another mistake is claiming that postMessage shares memory by reference; in reality the data is cloned and transferred, so mutations on one side do not affect the other. Candidates also err by describing setTimeout or requestIdleCallback as alternatives that fully solve the problem; those still run on the main thread and only defer work rather than parallelize it.

LIKELY FOLLOW-UPS: The interviewer may ask how you would handle errors by listening to worker.onerror or using onmessageerror for deserialization failures. They might probe shared workers versus dedicated workers, asking when you would use SharedWorker for multi-tab communication. Another follow-up is transferables: explain how to transfer ownership of a large ArrayBuffer rather than copying it to avoid memory duplication. You might also be asked how to spawn a worker from an inline blob URL for bundler environments where separate files are inconvenient, or how to use a worker pool to manage multiple concurrent jobs.

ONE CONCRETE EXAMPLE: Imagine a photo editor that needs to apply a Gaussian blur to a 4096 by 4096 pixel canvas. Doing this in the main thread would freeze the UI for hundreds of milliseconds. Instead, the main thread extracts the ImageData, calls worker.postMessage({ pixels, width, height }), and the worker performs the nested loop convolution. When complete, the worker calls self.postMessage({ blurredPixels }) and the main thread paints the result back to the canvas, keeping the app at sixty frames per second throughout.

Source: developer.mozilla.org