Browser Architecture: Processes and Threads

Your Browser Is an Operating System

Open Chrome's Task Manager (Shift+Esc on Windows/Linux, Window menu on macOS). You'll see something surprising: each tab runs in its own process. The browser itself has its own process. The GPU has its own process. Extensions get separate processes. A browser with 10 tabs easily has 20+ OS-level processes running.

This isn't an accident or a memory leak. It's architecture. Chrome uses a multi-process design where different responsibilities run in isolated OS processes. This means a crash in one tab doesn't bring down your entire browser. A malicious site in one tab can't read data from another tab. A runaway script in one tab doesn't freeze the browser's UI.

Understanding this architecture explains why things work the way they do — why your JavaScript blocks rendering, why heavy animations jank, why iframes from different origins are truly isolated, and why Chrome uses so much memory.

The Mental Model

Chrome's Multi-Process Architecture

Browser Process

The browser process is the boss. There's exactly one, and it's the first process that starts when you launch Chrome.

Responsibilities:

• Chrome UI — address bar, tabs, bookmarks, back/forward buttons, settings
• Process management — spawns and manages renderer, GPU, and utility processes
• Storage — manages cookies, localStorage, IndexedDB, Cache API
• Network dispatch — coordinates network requests (the actual I/O happens in a network service)

The browser process runs on its own thread and stays responsive even if a renderer process is stuck running heavy JavaScript.

Renderer Process

The renderer process is where the action happens. This is where your HTML gets parsed, your CSS gets applied, your JavaScript runs, and pixels get painted.

With site isolation (enabled by default since Chrome 67), each site gets its own renderer process. The key word is "site," not "tab":

Tab 1: example.com         → Renderer Process A
Tab 2: example.com/about   → Renderer Process A (same site)
Tab 3: stripe.com          → Renderer Process B (different site)
Tab 4: stripe.com (iframe) → Renderer Process B (same site)
Tab 5: evil.com (iframe inside Tab 1) → Renderer Process C (different site!)

Even an iframe from a different origin gets its own renderer process. This is critical for security — a compromised iframe can't access the parent page's memory because they're in separate OS processes.

GPU Process

The GPU process handles all GPU-accelerated operations:

• Compositing — combining layers from renderer processes into the final image
• Drawing — rendering the composited image to the screen
• Video decode — hardware-accelerated video playback
• WebGL/WebGPU — 3D graphics API execution

There's exactly one GPU process, shared by all tabs. It receives compositing instructions from renderer processes and handles the final draw to the display. This is why GPU-accelerated CSS transforms (transform, opacity) are so fast — they run on the GPU process, not the renderer's main thread.

Network Service

Network operations (DNS, TCP, TLS, HTTP) run as a service within the browser process (or as a separate process on some platforms). This centralizes all network I/O in one place, which enables:

• Connection pooling across tabs (HTTP/2 connection sharing)
• Centralized cache management
• Cookie handling and security policy enforcement
• Network-level security (certificate verification, HSTS)

Utility Processes

Chrome spawns additional processes for:

• Extensions — each extension runs in its own process
• Service workers — background workers get dedicated processes
• Audio — separate audio service process
• Storage — dedicated process for disk I/O operations

Inside the Renderer: Threads That Matter

The renderer process is where performance battles are won or lost. It contains multiple threads, but the most important ones are:

The Main Thread

The main thread is the single most important thread for web performance. It handles:

• HTML parsing — building the DOM tree
• CSS parsing — building the CSSOM tree
• JavaScript execution — ALL JavaScript runs here (unless you use Web Workers)
• Style calculation — computing final styles for every element
• Layout — calculating the geometry (position, size) of every element
• Paint — generating paint records (instructions for how to draw)
• Event handling — processing click, scroll, input events

All of these share one thread. When JavaScript runs a tight loop for 200ms, none of the other tasks can execute. The page can't respond to clicks, can't recalculate styles, can't layout new elements, can't paint updates. This is why long-running JavaScript causes jank and unresponsiveness.

The Compositor Thread

The compositor thread handles scrolling and CSS animations/transforms when possible, without involving the main thread:

• Scrolling — the compositor can scroll the page without waking up the main thread (if no scroll event listeners interfere)
• CSS transforms — transform: translateX(100px) can animate entirely on the compositor
• Opacity changes — opacity: 0.5 animates on the compositor
• Layer management — promotes elements to their own layers for independent composition

This is why transform and opacity animations are smooth even when JavaScript is busy — they bypass the main thread entirely.

Raster Threads

Raster threads (typically 4) convert paint records into bitmaps — the actual pixels. After the main thread generates paint instructions and the compositor determines which layers need painting, raster threads do the pixel work. This can be hardware-accelerated (GPU rasterization) or software-based.

Worker Threads

Web Workers run JavaScript on a separate thread from the main thread. They can't access the DOM directly, but they can perform heavy computation without blocking rendering:

const worker = new Worker('heavy-computation.js');
worker.postMessage({ data: largeDataset });
worker.onmessage = (e) => {
  updateUI(e.data.result);
};

Workers communicate with the main thread via postMessage (structured cloning). This is the primary escape hatch when you need heavy computation without freezing the page.

Site Isolation: The Security Architecture

Site isolation ensures that content from different sites runs in different OS processes. A "site" is defined as the scheme (https) + eTLD+1 (effective top-level domain plus one):

https://mail.google.com  → site: google.com
https://docs.google.com  → site: google.com (same site!)
https://evil.com          → site: evil.com (different site)

Why It Matters

Before site isolation, a malicious iframe on your page could potentially exploit Spectre-class CPU vulnerabilities to read your page's memory. With site isolation, that iframe runs in a completely different OS process with its own address space. It physically cannot access your page's memory.

This is also why cross-origin iframes can't access parent.document — they're not just blocked by the Same-Origin Policy in JavaScript. They're in a different process and don't share memory at all.

The Rendering Pipeline (Thread Perspective)

When you change the DOM, here's what happens across threads:

The critical insight: steps 1-4 all happen on the main thread. If JavaScript is busy, the rendering pipeline stalls. Steps 5-7 happen on other threads/processes and can proceed independently.

This is why compositor-only properties (transform, opacity) are fast — they skip steps 2-4 entirely and go straight to the compositor thread.

Common Mistakes

Key Takeaways