Mastering Browser Architecture: From Multi‑Process to JS Event Loop

Recent articles on JavaScript's single‑threaded execution often cover only fragments and present inconsistent explanations, leading to confusion. This article systematically consolidates the knowledge, starting from the browser's multi‑process architecture to the JavaScript single‑threaded engine.

Scope

This is a systematic overview rather than a step‑by‑step tutorial. It connects key concepts across the entire stack to form a coherent knowledge framework.

Content Overview

We cover the journey from browser processes, through the browser engine, to the JavaScript single‑threaded model and the event loop, aiming to eliminate fragmented understanding and build a solid knowledge skeleton.

The target audience is experienced front‑end developers; beginners should postpone reading until they have a basic grasp of the fundamentals.

Outline

(1) Distinguish Processes and Threads

(2) Browser is Multi‑Process

What processes does a browser contain?

Advantages of browser multi‑process

Focus on the rendering process (Renderer)

Communication between Browser and Renderer processes

(3) Thread Relationships Inside the Browser Engine

GUI rendering thread vs. JavaScript engine thread

JavaScript blocks page loading

WebWorker – JavaScript multithreading?

WebWorker vs. SharedWorker

(4) Simplified Browser Rendering Flow

(5) JavaScript Execution via the Event Loop

Event loop details

Timers

Prefer setTimeout over setInterval

(6) Advanced Event Loop: macrotask vs. microtask

1. Distinguish Processes and Threads

A process is like a factory with its own resources; factories are independent. A thread is a worker inside a factory; multiple workers cooperate on tasks and share the factory's memory.

Key points:

Process = smallest unit of CPU resource allocation (has its own memory)

Thread = smallest unit of CPU scheduling (multiple threads can exist within a process)

2. Browser is Multi‑Process

Each opened tab usually creates an independent browser process. The main Browser process coordinates other processes.

Verification: open Chrome's task manager and observe multiple processes (one main, one per tab).

Key processes:

Browser process (main process): handles UI, tab management, network resources, and compositing.

Third‑party plugin processes: created on demand.

GPU process: handles 3D rendering.

Renderer process (per tab): performs page rendering, script execution, and event handling.

Advantages of multi‑process browsers:

Isolate crashes to a single tab or plugin.

Leverage multiple CPU cores.

Sandboxing improves stability and security.

3. Thread Relationships Inside the Browser Engine

GUI Rendering Thread vs. JavaScript Engine Thread

The GUI thread renders the UI, parses HTML/CSS, builds the DOM and render trees, and performs layout and painting. When the JavaScript engine runs, the GUI thread is paused; updates are queued until the JS thread becomes idle.

JavaScript Blocks Page Loading

If JavaScript execution is long‑running, the UI cannot update, causing perceived page freezes.

WebWorker – JavaScript Multithreading?

HTML5 introduces Web Workers, which run scripts in background threads without access to the DOM. Communication occurs via postMessage.

WebWorker vs. SharedWorker

WebWorker belongs to a single page (Renderer process).

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

4. Simplified Browser Rendering Flow

Parse HTML → build DOM tree.

Parse CSS → build render tree.

Layout (reflow) → calculate sizes and positions.

Paint → rasterize pixels.

Composite → GPU merges layers and displays on screen.

Note: CSS loading does not block DOM parsing but does block render‑tree construction.

5. JavaScript Execution via the Event Loop

JavaScript runs on a single thread, while asynchronous tasks are handled by auxiliary threads (event‑trigger thread, timer thread, etc.). After the call stack is empty, the engine processes the task queue.

Timers

setTimeout and setInterval are driven by a dedicated timer thread because the JS engine cannot reliably keep time while blocked.

Example: setTimeout(function() { console.log('hello!'); }, 1000); Another example demonstrating order:

setTimeout(function() { console.log('setTimeout'); }, 0); console.log('begin');

Result: "begin" logs before "setTimeout" because the callback is queued after the current stack finishes, and browsers enforce a minimum 4 ms delay.

Prefer setTimeout over setInterval

setTimeout avoids cumulative drift and avoids issues when the page is hidden or scrolling, where setInterval may fire multiple times after a pause.

6. Advanced Event Loop: macrotask vs. microtask

macrotask (task) includes main code, setTimeout, setInterval, etc. Each macrotask runs to completion before the next one starts, and the browser may render between tasks.

microtask (job) includes Promise callbacks and process.nextTick. Microtasks are executed immediately after the current macrotask finishes, before any rendering.

Example order:

console.log('start');
setTimeout(function(){ console.log('setTimeout'); }, 0);
Promise.resolve().then(function(){ console.log('promise1'); }).then(function(){ console.log('promise2'); });
console.log('end');

Output: start end promise1 promise2 setTimeout

In Node.js, process.nextTick runs before Promise microtasks.

Additional Notes

MutationObserver can be used to implement microtasks when Promise is unavailable.

Vue's nextTick historically used MutationObserver, later switched to MessageChannel (a macrotask).

After reading this article, you should have a clear understanding of browser processes, threading, the JavaScript single‑threaded model, the event loop, and related performance considerations.

After finishing this article, you should understand processes, threads, the browser's multi‑process architecture, the JavaScript single‑threaded engine, the event loop, and related performance implications.