Most frontend developers spend their time inside frameworks like React, Vue, or Angular. But underneath every framework is the same system: the browser turning code into pixels on a screen.
This process is known as the browser rendering pipeline (or the critical rendering path).
In simplified terms:
HTML → DOM
CSS → CSSOM
DOM + CSSOM → Render Tree
Render Tree → Layout
Layout → Paint
Paint → Composite
Understanding this pipeline explains many real-world performance issues that developers encounter.
1. HTML Parsing → DOM Construction
The browser begins by parsing HTML and converting it into the Document Object Model (DOM), a tree structure representing the page.
Example HTML:
<body>
<h1>Hello</h1>
<p>Welcome</p>
</body>
DOM representation:
Document
└── body
├── h1
└── p
Browsers stream-parse HTML, meaning they start building the DOM before the entire document is downloaded.
However, JavaScript can interrupt this process. When the parser encounters a blocking script:
<script src="app.js"></script>
DOM construction pauses while the script executes. This is why script placement or using defer matters.
2. CSS Parsing → CSSOM Construction
While the DOM represents structure, CSS defines how elements should appear.
The browser parses CSS into the CSS Object Model (CSSOM).
Example CSS:
h1 {
color: red;
}
The browser resolves:
- the cascade
- specificity
- inheritance
Eventually, every element receives its computed styles.
3. DOM + CSSOM → Render Tree
The DOM alone isn’t enough to render a page. The browser merges the DOM and CSSOM to create a Render Tree, which contains only visible elements with their computed styles.
For example:
DOM:
body
├─ h1
├─ p
└─ script
Render Tree:
body
├─ h1 (styled)
└─ p (styled)
Elements such as <script>, <meta>, or elements with display: none are excluded.
The render tree represents what actually needs to be drawn.
4. Layout (Reflow)
Once the render tree is built, the browser calculates the geometry of each element. This stage is called layout (or reflow).
The browser determines:
- width and height
- position
- spacing and box model calculations
Example:
h1 → x:0 y:0 width:800 height:40
p → x:0 y:40 width:800 height:20
Layout can be expensive because a change in one element may affect many others. For example, changing a container’s width might require recalculating layout for the entire subtree.
5. Paint
After layout, the browser converts elements into drawing instructions.
Painting includes:
- text
- colors
- borders
- shadows
- images
At this stage the browser determines how elements should be visually drawn, but pixels are not yet combined into the final frame.
6. Compositing
Modern browsers split the page into layers and send them to the GPU compositor.
Certain properties create separate layers, including:
transformopacityposition: fixedvideocanvas
The GPU then combines these layers into the final image displayed on the screen.
This step is what enables smooth animations and efficient rendering.
The 16ms Frame Budget
Browsers aim for 60 frames per second, which means each frame must be processed within about 16 milliseconds.
Within that time the browser must run:
JavaScript
Style calculation
Layout
Paint
Composite
If the work exceeds this budget, the result is dropped frames and visible UI lag.
Not All CSS Changes Are Equal
Different CSS properties affect different stages of the pipeline.
Layout-triggering properties (expensive)
Examples: width, height, margin, top, left
Pipeline:
Style → Layout → Paint → Composite
Paint-only properties
Examples: background-color, border-color, box-shadow
Pipeline:
Style → Paint → Composite
Composite-only properties (fastest)
Examples: transform, opacity
Pipeline:
Style → Composite
This is why modern animation guidelines recommend using transform and opacity.
Why This Matters
Many developers blame frameworks when performance issues appear. In reality, problems usually come from:
- excessive DOM updates
- layout thrashing
- expensive paint operations
- overly complex render trees
Frameworks may change, but browser fundamentals remain the same.
Most developers think in terms of:
Components → State → UI
But the browser ultimately thinks in:
DOM → Style → Layout → Paint → Composite
Understanding that model is what separates framework users from true frontend engineers.