Web Worker

The browser's main thread is responsible for painting the screen, handling clicks and scrolling, and running JavaScript. When large JSON parsing, complex calculations, or image processing all happen there too, button clicks lag and scrolling stutters. That is the classic 'the UI froze' experience. The issue is not that JavaScript is inherently slow. It is that too many important jobs are standing in the same line waiting for the same thread. The calculation may still be necessary, but it needs an execution model that keeps it out of the line where rendering and user input must stay responsive.

Early web pages were mainly documents with modest interaction, so a single main thread was enough. But browsers now host data visualization, audio editing, CAD, huge tables, and even machine-learning inference. Once those workloads moved into the browser, keeping every computation on the main thread became incompatible with a responsive UI. Browsers do not expose arbitrary threading in the way native applications do, but they do provide a safe model for isolating computation: Web Worker. The browser prevents direct UI access while still allowing code to run in a separate context and coordinate through messages.

The main thread creates a worker with `new Worker()` and starts a separate script. Inside that worker there is its own global scope and event loop, where heavy computation and parsing can run independently. The main thread and the worker do not share ordinary memory by default. Instead, they communicate through `postMessage`, and the browser either clones the data using the structured clone algorithm or transfers ownership for transferable objects such as ArrayBuffer. That means designing the message contract matters more than thinking in terms of function calls. A worker cannot directly read or mutate the DOM. It sends results back to the main thread, and the main thread applies the UI update. That restriction is what lets the browser isolate heavy work while preserving UI consistency.

Web Worker and Service Worker both execute off the main thread, but their relationship to the current page is different. A Web Worker exists to offload computation on behalf of a page that is currently open. A Service Worker exists to control requests, caching, and certain background events between the browser and the network. It is also important to remember that a Web Worker does not make DOM work disappear. If the bottleneck is expensive DOM mutation itself, that cannot simply be moved into the worker. The worker is for computation and parsing; the UI still lives on the main thread. Choosing what stays where is the whole design boundary.

Web Worker has immediate impact in products that perform meaningful computation in the browser. Log search, huge-table filtering, image conversion, and real-time message parsing are typical examples where the main thread must not be blocked while the user is interacting. In practice, it is usually better to move only the operations that measurably block the main thread rather than trying to shard everything aggressively. If messages bounce back and forth too often, the communication cost can erode the benefit. A worker also does not erase memory and copying costs. Repeatedly cloning large objects can become a burden of its own, so transferable objects or smaller message payloads matter. The goal is not to move work at random, but to push the user-visible bottleneck off the main thread.