Browser Architecture
🧠 TL;DR — A modern browser isn't one program, it's several separate processes — browser, renderer, GPU, network — talking to each other. Splitting them up is what keeps one crashed tab from taking down your whole browser.
Everything we've covered so far in this series — parsing, the render tree, layout, paint, compositing — happens inside a single renderer process. But that's only one piece of the browser. Here's the bigger picture.
flowchart TB
A[Browser Process] --> B[Renderer Process — Tab 1]
A --> C[Renderer Process — Tab 2]
A --> D[GPU Process]
A --> E[Network Process]
A --> F[Extension Processes]
🧭 The browser process
The browser process is the coordinator. It owns the address bar, bookmarks, back/forward buttons, and the window chrome itself. It's the only process with direct access to disk and the network on behalf of the others, and it decides which renderer process handles which tab.
🖥️ Renderer processes
Each tab (roughly) gets its own renderer process, running the parsing → render tree → layout → paint → compositing pipeline we've spent this whole series on. Renderer processes are deliberately sandboxed — they can't touch the filesystem or make raw network calls directly; they have to ask the browser process to do it for them.
| Process | Can access disk? | Can access network? | Runs your page's JS? |
|---|---|---|---|
| Browser process | ✅ | ✅ (brokers requests) | ❌ |
| Renderer process | ❌ | ❌ (sandboxed) | ✅ |
| GPU process | ❌ | ❌ | ❌ |
⚡ Tip: This is why one tab crashing (a renderer process dying) usually doesn't take down your whole browser — it's an isolated process. You'll have seen this as Chrome's "Aw, Snap!" page.
🎮 The GPU process
Remember rasterization and compositing from the last two posts? A lot of that pixel-pushing work is handed to a dedicated GPU process, shared across all tabs, so renderer processes don't each need their own direct line to the graphics hardware.
🌐 The network process
Fetching resources — HTML, CSS, images, API responses — goes through a separate network process. Centralizing it lets the browser manage things like the HTTP cache and connection pooling consistently across every tab.
✅ Key takeaways
A browser is a small distributed system of processes, not one monolithic program.
Renderer processes are sandboxed for security and stability — that's why a bad tab doesn't crash everything.
The rendering pipeline from this series (parsing → paint → compositing) is just the renderer process's job; the browser process, GPU process, and network process each handle a different slice of the work.
#browsers #architecture #chromium #performance