DEV Community

Cover image for How the Browser Rendering Pipeline Actually Works
Vishwajeet Kondi
Vishwajeet Kondi

Posted on • Originally published at coderlegion.com

How the Browser Rendering Pipeline Actually Works

#webdev #css #webperf #frontend

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
Enter fullscreen mode Exit fullscreen mode

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>
Enter fullscreen mode Exit fullscreen mode

DOM representation:

Document
 └── body
      ├── h1
      └── p
Enter fullscreen mode Exit fullscreen mode

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>
Enter fullscreen mode Exit fullscreen mode

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;
}
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

Render Tree:

body
 ├─ h1 (styled)
 └─ p (styled)
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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:

  • transform
  • opacity
  • position: fixed
  • video
  • canvas

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

Paint-only properties

Examples: background-color, border-color, box-shadow

Pipeline:

Style → Paint → Composite
Enter fullscreen mode Exit fullscreen mode

Composite-only properties (fastest)

Examples: transform, opacity

Pipeline:

Style → Composite
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

But the browser ultimately thinks in:

DOM → Style → Layout → Paint → Composite
Enter fullscreen mode Exit fullscreen mode

Understanding that model is what separates framework users from true frontend engineers.

Top comments (0)