This entry was synthesized from an external technical resource.
View Original SourceTL;DR: The browser is a single-threaded virtual machine that turns raw text into pixels via the Critical Rendering Path (CRP). Performance is managed by optimizing five distinct stages: Network, Parsing, Tree Building, Layout, and Paint.
To master performance, view the browser as a single-threaded virtual machine, not a document viewer.
Its job is to convert raw text into millions of pixels, 60 times per second. Every Lighthouse delay reveals a bottleneck in the Critical Rendering Path (CRP).
This is the forensic anatomy of how a browser turns code into a visual experience.
The Macro Pipeline
The journey from URL to pixels happens in five stages:
1 1. Bytes ──> 2. Parsing ──> 3. Tree Building ──> 4. Render Engine ──> 5. Pixels
2[Network] [HTML/CSS] [DOM & CSSOM] [Layout/Paint] [GPU]Fetching Bytes
The browser must fetch data before rendering pixels. Standard TCP/TLS handshakes occur, but the primary metric is TTFB (Time to First Byte). The browser sits idle until the first HTML bytes arrive. Once the stream begins, the Main Thread wakes up.
Building Object Models
Browsers do not understand HTML or CSS. They understand object models. The engine must parse raw bytes into formats it can manipulate.
Document Object Model
As HTML streams in, the parser converts bytes into tokens, then nodes, and finally the DOM tree.
1Bytes: 3C 62 6F 64 79 3E 48 69...
2 ↓
3Characters: <body>Hi...
4 ↓
5Nodes: HTMLBodyElement, TextNode
6 ↓
7DOM TREE:
8 html
9 / \
10 head body
11 | |
12 title p ("Hi")The browser builds the DOM incrementally, processing nodes as they arrive.
CSS Object Model
Encountering a <link rel="stylesheet"> triggers a CSS request. Unlike HTML, CSS cannot be parsed incrementally. A rule at the bottom can override one at the top, so the engine must parse the entire file before proceeding.
This makes CSS render-blocking. The browser refuses to paint a half-styled page to prevent Flash of Unstyled Content (FOUC).
The JavaScript Blockade
Scripts stop the parser. JavaScript can alter the DOM or CSSOM, so the browser halts parsing to download, compile, and execute JS. High-performance sites use defer or async to download scripts in the background while the tree continues building.
The Render Tree
The engine combines content (DOM) and styles (CSSOM) into the Render Tree.
1[DOM Tree] [CSSOM Tree]
2 | |
3 +-----> ⨁ <-------+
4 |
5 [ Render Tree ]The browser traverses the DOM and maps CSSOM styles to it. Invisible elements like <head>, <script>, or display: none are dropped. If it does not need pixels, it stays out of the tree.
Layout and Reflow
The Render Tree knows what to show, but not where. Layout calculates the geometry of every node based on the viewport.
The browser converts relative units (vw, %) into absolute pixels. This is CPU-intensive. Changing an element’s width later forces a recalculation (often called Reflow) for that element and its neighbors.
Paint and Compositing
With geometry calculated, the browser enters Paint. It rasterizes text, colors, shadows, and images into pixels.
To maintain speed, modern browsers use Compositing:
1[ Layer 1: Background & Text ] <-- CPU
2[ Layer 2: Sticky Header ] <-- CPU
3[ Layer 3: GPU Animated Div ] <-- GPU
4 ↓
5 [ COMPOSITOR ]
6 (Draws layers to screen)The Main Thread hands painted layers to the Compositor Thread, which communicates with the GPU. This separation makes transform and opacity animations smooth; they skip Layout and Paint to happen directly on the GPU.
Why This Matters
Understanding this lifecycle replaces guessing with engineering. Knowing that CSS blocks rendering or that 3000px images penalize the Paint phase on mobile allows you to write better code instead of chasing plugins.
To see this theory applied to a real site, read A Tale of Web Vitals.