How browser works part 1: Browser architecture

This is the first article in the series on understanding how browsers work. In this post we provide a high-level overview of the browser's process architecture, which lays a solid foundation for deeper exploration later on.

Chrome browser architecture

If you are a front-end developer, you've probably heard of the browser's main thread. Most of the code we write runs on this main thread, and you've likely heard that JavaScript execution and page rendering happen on this single thread. But how does the browser really work? Is everything in the browser running on this single main thread?

The short answer is no.

Let's start with a process architecture diagram.

From this architecture diagram, we can draw the following conclusions:

Three-layer architecture: software, OS, hardware

The diagram is split into three layers from top to bottom:

• The top layer is the software (application) layer: our front-end app (mostly in the renderer process main thread) and the browser itself run here.
• The middle layer is the operating system: the OS sits between applications and hardware, providing the interface for apps to use hardware resources.
• The bottom layer is hardware: this includes many things, but the core is computation, typically CPU (general-purpose processing) and GPU (specialized processing, very efficient for certain tasks).

Responsibilities of major browser processes

Browser Process

• UI Thread: controls the Chrome UI (address bar, bookmarks, back/forward buttons, etc.).
• Network Thread: handles low-level network requests. Requests from renderer processes are ultimately handled by the Network Thread. You can think of it as the browser process spinning up a network task for each request. Concurrency is limited, usually around 6 concurrent requests per domain.
• Storage Thread: handles storage-related tasks such as local file system access.

1. In reality, the browser process has more kinds of threads; we only list common ones here.
2. When hardware permits (for example, enough memory), some threads may run in separate processes, such as the Network Thread running in a Network Process.

Renderer Process

The Renderer Process is where our web app actually runs. In Chrome, each tab has its own renderer process. If one tab crashes, it does not affect other tabs.

• Main Thread: the thread we know best as front-end developers; most of our code runs here.
• Worker Threads: present when the app uses web workers or service workers.
• Compositor Thread: the main thread sends layer and paint order information to the compositor thread. The compositor thread breaks layers into smaller tiles and hands them to raster threads; raster threads rasterize the tiles into GPU memory. The compositor thread then combines them into a compositor frame and passes it to the browser process, which forwards it to the GPU for display.
• Raster Thread: rasterizes the tiles produced by the compositor thread using the GPU.

The compositor and raster threads primarily exist to improve rendering performance.

Summary

1. Even though most front-end code runs on the main thread, user input is not received directly by the renderer main thread. It is received by the browser process.

• For example: when you type a URL in the address bar, the browser process handles the input and its initial processing. It acts like the central dispatcher.
• Another example: when a user clicks in your app, the browser process receives the input and forwards it to your app.

2. Coordination between the browser process and the renderer process ensures efficient application execution.

What happens after a user input?

Let's use a user typing "https://www.example.com" in the address bar to describe how the browser's components cooperate:

1. User input phase

• The user types a URL in the address bar; the UI Thread in the browser process captures the input event.
• The UI Thread processes the input in real time, such as showing suggestions and autocomplete.

2. Navigation initialization phase

• When the user presses Enter, the UI Thread starts a new navigation flow.
• The UI Thread hands control to the Network Thread to process the URL.

3. Network request phase

• The Network Thread first checks the local cache for a response.
• If it needs to fetch from the network, the Network Thread performs DNS lookup and establishes a TLS connection (for HTTPS).
• The Network Thread issues the actual HTTP request.

4. Response handling phase

• After receiving the response, the Network Thread inspects Content-Type and other metadata to decide how to handle it.
• If it is an HTML response, the Network Thread hands control back to the UI Thread to render the page.
• If it is a file download, control is handed to the download manager.

5. Renderer process initialization phase

• Once the UI Thread decides to render the page, it launches a new renderer process.
• The browser process assigns a sandboxed environment to the renderer process for security.

6. Navigation confirmation phase

• Once the renderer process is ready, the browser process transfers data via IPC (inter-process communication).
• The browser process updates the UI, such as:
  • updating the address bar
  • updating navigation history
  • updating back/forward buttons
  • showing a loading indicator

7. Rendering phase (inside the renderer main thread)

• The main thread parses HTML.
• Builds the DOM tree.
• Executes JavaScript.
• Builds the CSSOM.
• Performs layout.
• Builds the layer tree (paint to layer tree).

8. Compositing and display phase

• The compositor thread receives layer information from the main thread.
• Splits layers into tiles.
• The raster threads rasterize the tiles into GPU memory.
• The compositor thread generates a compositor frame.
• The compositor frame is sent via the browser process to the GPU for display.

This flow shows how the browser's multi-process architecture works together:

• The browser process is the conductor, coordinating navigation.
• The network thread handles network operations.
• The renderer process renders the page.
• The GPU process handles final display (not shown in the diagram).

This architecture improves stability (one tab crash does not affect others) and boosts performance and security by separating tasks.

1. Steps 7 and 8 are directly related to app performance, and step 7 happens on the single main thread. This is why we often say JS execution and page rendering happen on a single thread.
2. Steps 7 and 8 together are commonly called the render pipeline or pixel pipeline. Front-end performance optimization is essentially about optimizing this pipeline.

References

• An Introduction to the Browser Rendering Pipeline
• Rendering performance
• Inside look at modern web browser
• Populating the page: how browsers work