Mastering Browser Processes, Threads, and the JavaScript Event Loop

Preface

Note: The author welcomes corrections and acknowledges the article is lengthy with many images.

Many articles only cover parts of JavaScript's single‑threaded execution, leading to confusion. This article systematically consolidates knowledge from browser multi‑processes to the JavaScript event loop, aiming to build a complete mental model.

The presentation is a top‑down system overview rather than a step‑by‑step tutorial, linking key concepts together.

Outline

Distinguish processes and threads

Browser is multi‑process

What processes does a browser contain?

Advantages of multi‑process browsers

Focus on the rendering process

Communication between Browser and Renderer processes

Thread relationships inside the rendering engine

GUI rendering thread vs. JS engine thread

JS blocking page load

WebWorker – JavaScript multithreading?

WebWorker vs. SharedWorker

Simple browser rendering flow

Order of load and DOMContentLoaded events

Does CSS loading block DOM tree rendering?

Normal layers vs. composited layers

JavaScript runtime from the Event Loop

Further details on the event loop

Timers

setTimeout vs. setInterval

Advanced event loop: macrotask vs. microtask

Final thoughts

Distinguish Processes and Threads

A common beginner mistake is confusing processes and threads. Think of a process as a factory with independent resources, and threads as workers inside the factory sharing space.

- Process is a factory, with its own memory resources.
- Factories are independent of each other (processes are isolated).
- Threads are workers that cooperate to complete tasks.
- A process can have one or more threads.
- Threads within the same process share the program's memory space (code, data, heap, etc.).

On Windows, you can see processes and their memory/CPU usage in Task Manager.

Process is the smallest unit of CPU resource allocation (the system gives it memory).

Process: smallest unit that can own resources and run independently.

Thread: smallest unit of CPU scheduling, built on a process; a process can contain multiple threads.

Tips

Inter‑process communication is possible but costly.

Common terminology: “single‑thread” and “multi‑thread” refer to the number of threads within a single process.

Browser Is Multi‑Process

After understanding processes and threads, note that a browser runs as multiple processes.

Each opened tab creates an independent browser process.

The system allocates CPU and memory to these processes.

Open Chrome’s Task Manager to see multiple processes: a main Browser process and a Renderer process for each tab.

Note that Chrome may merge some processes for optimization, so the one‑process‑per‑tab rule is not absolute.

What Processes Does a Browser Contain?

Browser (main) process – single instance, handles UI, tab management, and network resources.

Third‑party plugin process – created only when a plugin is used.

GPU process – at most one, for 3D rendering.

Renderer (rendering) process – usually one per tab, runs multiple threads for page rendering, script execution, and event handling.

Opening a webpage essentially starts a new process (which itself contains multiple threads).

Advantages of Browser Multi‑Process

Crash of a single page does not affect the whole browser.

Crash of a third‑party plugin does not affect the whole browser.

Better utilization of multi‑core CPUs.

Sandbox isolation improves stability.

The trade‑off is higher memory consumption.

Focus on the Rendering Process

The rendering process (Renderer) is where page rendering, JavaScript execution, and the event loop occur. It is multithreaded.

GUI rendering thread – renders the UI, parses HTML/CSS, builds the DOM and render trees, performs layout and painting. It is mutually exclusive with the JS engine thread; when JS runs, the GUI thread is paused and its updates are queued.

JS engine thread – runs JavaScript (e.g., V8). Only one JS thread runs per renderer process. It waits for tasks from the task queue.

Event trigger thread – belongs to the browser, not the JS engine. It adds asynchronous events (e.g., setTimeout, AJAX callbacks) to the task queue.

Timer thread – handles setTimeout/setInterval timing so that the JS engine is not blocked.

Async HTTP request thread – handles XHR network requests and posts state‑change events to the task queue.

Understanding these threads is essential before diving into the event loop.

Web Workers – JavaScript Multithreading?

HTML5 introduces Web Worker to run scripts in background threads without blocking the UI.

Web Worker provides a simple way to run scripts in a background thread. Workers run in a separate global context and cannot access the DOM directly.

Creating a Worker spawns a new thread managed by the browser; communication occurs via postMessage and serialization.

SharedWorker differs: it is shared across multiple pages and runs in its own process.

Simple Browser Rendering Flow

Steps (simplified):

Parse HTML → build DOM tree.

Parse CSS → build render tree (DOM + CSS).

Layout (reflow) – calculate sizes and positions.

Paint – rasterize pixels.

GPU compositing – combine layers and display.

After painting, the load event fires.

load vs. DOMContentLoaded

DOMContentLoaded

fires when the DOM is fully parsed (styles, images, async scripts may still be loading). load fires when the entire page (DOM, styles, scripts, images) is completely loaded.

Order: DOMContentLoaded → load.

Does CSS Loading Block DOM Rendering?

CSS loads asynchronously and does not block DOM tree construction.

However, CSS blocks the render tree because layout and painting need final styles.

Normal Layers vs. Composited Layers

During rendering, the browser creates normal layers and composited layers. A composited layer is rasterized separately (often via GPU) and does not trigger reflow of the whole page when it changes.

Hardware acceleration (e.g., transform: translate3d(), opacity, will-change) forces an element onto its own composited layer.

From Event Loop to JavaScript Runtime

JavaScript runs on a single thread, but the browser uses additional threads to handle events and timers. The event loop processes tasks (macrotasks) and microtasks.

Timers

setTimeout/setInterval are driven by a dedicated timer thread so that the JS engine’s single thread is not blocked.

setTimeout(function(){ console.log('hello!'); }, 1000);

Even a zero‑delay timer is clamped to a minimum of 4 ms by the HTML spec.

setTimeout vs. setInterval

setTimeout

schedules a single callback; chaining it can avoid cumulative drift. setInterval schedules repeated callbacks but can cause overlapping executions if a callback takes longer than the interval.

In scrolling or when the tab is hidden, browsers may pause timers, causing a burst of callbacks when resumed.

Advanced Event Loop: macrotask & microtask

Macrotasks include the main script, setTimeout, setInterval, and I/O callbacks. Microtasks include Promise callbacks and process.nextTick (Node.js).

Execution order:

Run a macrotask.

During its execution, queue any microtasks.

After the macrotask finishes, drain the microtask queue before rendering.

Render, then pick the next macrotask.

Final Thoughts

Understanding the full stack—from browser processes to the JavaScript event loop—provides a clearer mental model than fragmented pieces. Front‑end development involves many layers, and deeper exploration (e.g., lexical analysis, execution contexts) can be pursued in future articles.

If you found this useful, please give it a like.

Original source: Zhihu article https://zhuanlan.zhihu.com/p/33230026 (authorized reproduction by IMWeb)