Understanding Browser Process Architecture and Rendering Pipeline

Introduction

The article examines how browsers manage multiple processes to render pages, focusing on the cooperation between these processes and the overall rendering workflow.

1. Evolution of Browser Process Architecture

Process and Thread

A process is an isolated execution environment containing code, data, and a main thread; threads are lightweight tasks within a process that share resources but can cause the entire process to crash if one fails.

Single‑Process vs Multi‑Process Browsers

Single‑Process Browsers

All modules (network, plugins, JavaScript engine, rendering engine, etc.) run in one process, leading to instability, poor responsiveness, and security risks because a crash or vulnerability in any module can affect the whole browser.

Multi‑Process Browsers

Modern browsers like Chrome isolate functions into separate processes: a browser process (UI and management), renderer processes (HTML/CSS/JS execution), network process, plugin process, and GPU process. Inter‑process communication (IPC) keeps them coordinated while providing sandboxing for security.

2. Navigation Flow

The navigation sequence starts when the browser process receives a URL, forwards it to the network process, which fetches resources, sends response headers back, and then the browser process instructs the renderer to commit the navigation and begin parsing the HTML.

3. Rendering Flow

Rendering Pipeline Stages

The pipeline consists of DOM construction, style calculation, layout, layering, painting, rasterization, and compositing.

DOM Construction

The HTML parser builds a DOM tree that the rendering engine can understand.

Style Calculation

CSS text is transformed into styleSheets, property values are normalized (e.g., {color: blue} → {color: rgb(0, 0, 225)} , {font-weight: bold} → {font-weight: 700} ), and computed styles are stored.

Layout

The engine creates a layout tree and computes geometric positions for visible elements.

Layering

Complex effects (3D transforms, scrolling, z‑index) cause certain nodes to be promoted to separate layers, forming a layer tree.

Painting

Each layer is broken into paint commands that form a paint list.

Rasterization

The paint list is handed to the compositor thread, which divides layers into tiles and rasterizes them (often using the GPU) into bitmaps.

Compositing and Display

Rasterized tiles are assembled into DrawQuad commands, sent to the browser process, and finally displayed on the screen.

Reflow and Repaint

Changing geometric properties triggers a reflow (layout & layer recomputation), which is the most expensive operation. Changing only paint properties causes a repaint, skipping layout and layering, thus being cheaper.

GPU‑Accelerated Compositing

When only compositing‑friendly CSS properties (e.g., transform , opacity , filter ) change, the engine can skip layout and paint, performing the animation directly on the compositor thread for higher performance.

Reference

[1] Browser Working Principles and Practice: https://time.geekbang.org/column/intro/100033601

[2] Evolution of Browser Process Architecture: https://zhuanlan.zhihu.com/p/96957235