Section 1: Browser Process Architecture

The Big Picture: One Building, Many Locked Rooms

A web browser is not one program doing one job. It is closer to an office building with many locked rooms. In each room, a worker handles one task. If one worker faints, the other rooms keep working. If a thief breaks into one room, the locked doors stop them from walking into the others.

In this chapter we mostly describe Chromium, the open-source engine behind Google Chrome and Microsoft Edge (and several other browsers). Firefox is built differently inside; we will say where it differs. Details also change from version to version, so treat the process names below as a model, not a promise.

Remember from Chapter 9 — Processes: a process is a running program with its own private memory. One process cannot normally read the memory of another. A browser uses that rule on purpose.

 What you see                    What is really running

 ┌──────────────────┐            ┌────────────────────────────────┐
 │  One browser     │            │  Many processes, each with its │
 │  window, a few   │   ───►     │  own private memory and job    │
 │  tabs            │            │  (often 10 or more of them)    │
 └──────────────────┘            └────────────────────────────────┘

1.1 The Multi-Process Model

What it is: The browser splits its work into separate processes. Each process has one kind of job. They talk to each other through a controlled channel called IPC (Inter-Process Communication: a safe way for two processes to pass messages).

The main players in a Chromium browser:

                        ┌──────────────────────────┐
                        │      BROWSER PROCESS     │
                        │  window, tabs, address   │
                        │  bar, bookmarks, control │
                        └────────────┬─────────────┘
                                     │  IPC messages
        ┌──────────────┬─────────────┼─────────────┬──────────────┐
        ▼              ▼             ▼             ▼              ▼
 ┌────────────┐ ┌────────────┐ ┌───────────┐ ┌───────────┐ ┌────────────┐
 │ RENDERER A │ │ RENDERER B │ │    GPU    │ │  NETWORK  │ │  UTILITY / │
 │ site-a.com │ │ site-b.com │ │  PROCESS  │ │  SERVICE  │ │ EXTENSION  │
 └────────────┘ └────────────┘ └───────────┘ └───────────┘ └────────────┘
   runs page     runs page      draws via     DNS, TLS,     small jobs,
   code (JS)     code (JS)      GPU driver    HTTP, cache   add-ons

The browser process is the boss, but not the worker. It does not run web pages. A web page cannot talk to your files or your network card directly. It must ask the browser process (through IPC) and the browser decides yes or no.

Firefox differs. Firefox also uses many processes, but its layout is different. It has a main (parent) process, several content processes that run web pages (the number is limited by a setting), and separate processes for the GPU, networking helpers and other jobs. The idea is the same (isolation) but the names and counts differ, and Firefox has historically used fewer content processes than Chrome uses renderers. Safari and other browsers have their own variations.

1.2 Why Tabs Are Separate Processes (Isolation and Crash Containment)

What it is: Instead of running every tab inside one big program, the browser gives pages their own process. There are two big reasons.

Reason 1: Stability (crash containment). Web pages run code written by strangers. Some of it has bugs. If every tab lived in one process, one bad page that crashes would take all your tabs and your half-written email with it. With separate processes, only that page's process dies. You see the "Aw, Snap!" or "This page has crashed" message in that one tab; other tabs carry on.

Reason 2: Security (isolation). A malicious page may try to attack the browser through a bug. Because each process has private memory, a page in one process cannot simply read the memory of another process, which might hold your bank site. The operating system enforces this wall, not the web page.

 ONE-PROCESS BROWSER (old, risky)         MULTI-PROCESS BROWSER (modern)

 ┌─────────────────────────────┐    ┌────────┐ ┌────────┐ ┌────────┐
 │ tab: bank  tab: game        │    │ bank   │ │ game   │ │ news   │
 │ tab: news  tab: shady       │    │ (own   │ │ (own   │ │ (own   │
 │ all share ONE memory        │    │ memory)│ │ memory)│ │ memory)│
 │ crash = everything dies     │    │        │ │        │ │        │
 └─────────────────────────────┘    └────────┘ └────────┘ └────────┘
                                           a crash or hack stays in its room

Site isolation. Chrome and Edge go further than "one process per tab". With site isolation, pages from different sites are put in different renderer processes, even inside the same tab. For example, a page on shop.example that embeds a frame (a page-inside-a-page) from ads.other-site.example runs that frame in a different process. Why does that matter? In 2018 a class of CPU flaws (Spectre, see Chapter 2 — CPU Internals) showed that code might trick the CPU into leaking memory that sits in the same process. If different sites never share a process, there is nothing from the other site to leak. A "site" here means roughly the registrable domain plus scheme (for example https://example.com); the exact rules are detailed and may change.

It is not free. More processes use more RAM (each one has its own copy of some browser code and data). That is why a browser with many tabs can use gigabytes. Browsers reduce the cost by reusing processes in some cases, by discarding or freezing tabs you have not used for a while, and by sharing read-only memory. Settings called "Memory Saver" (Chrome) or "Sleeping tabs" (Edge) do this. Menu names change between versions.

1.3 The Sandbox: A Locked Room With a Small Window

What it is: Renderer processes (and most other helper processes) run inside a sandbox: the operating system removes most of their power. Even if a hacker takes over a renderer, the process is not allowed to read your documents, start programs or open arbitrary network connections.

On Windows, Chromium builds the sandbox from features you met in Chapter 26 — Windows Security Architecture. Without going deeper than we are sure of, the main ideas are:

So a renderer is like a worker in a locked room with a small window. To do anything real (save a download, open a file picker, send a network request) it passes a note through the IPC window to the browser process, which checks the request first.

1.4 Seeing the Processes for Yourself

The browser's own Task Manager. In Chrome and Edge press Shift + Esc. (You can also open the browser menu and look under "More tools" for a Task Manager entry; menu names may differ.) You will see one row per tab, extension, and helper such as "GPU Process" or "Network Service", with memory and CPU columns. You can select a row and use End process to close a frozen tab without closing the whole browser.

Windows Task Manager. Open it with Ctrl + Shift + Esc (Chapter 11). In the Processes tab, the browser appears as one group such as "Google Chrome (24)". Expand it to see the pieces. In the Details tab you will see many lines named chrome.exe or msedge.exe: all are the same program file started many times, each as its own process with its own PID (process ID). See Chapter 11 — Windows Task Manager and Chapter 9 — Processes.

 Task Manager > Details tab (example, numbers will differ)

 Name         PID     Memory       What it probably is
 ──────────── ─────── ──────────── ──────────────────────────
 chrome.exe   10412     180 MB     browser (main) process
 chrome.exe   10788      95 MB     GPU process
 chrome.exe   10932     310 MB     a renderer for a tab
 chrome.exe   11004      60 MB     network service
 chrome.exe   11250     140 MB     another renderer

Why do they all have the same name? Because the browser launches itself with different command-line flags (such as "you are a renderer", "you are the GPU process"). Right-click a column header in the Details tab and add Command line to see the --type=renderer or --type=gpu-process text. This is read-only and safe.

Each renderer also uses threads (Chapter 10 — Threads): a main thread that runs JavaScript, plus helper threads for painting and more. Section 3 explains why that main thread matters.

Summary