Understanding the Browser’s Rendering Cycle: A Developer’s Guide

Introduction: How Does the Browser Render a Web Page

When we build web apps, we usually write HTML, CSS, and JavaScript — but browsers don’t "understand" these directly. Behind the scenes, they go through a multi-step rendering process to turn our code into pixels on the screen.

This process is called the Rendering Pipeline or Render Cycle.

Browser Rendering Cycle

• HTML Parsing -> DOM Tree
  The browser parses the HTML and creates the DOM Tree (Document Object Model)
  Each HTML element becomes a node in the tree. The process is synchronous — large HTML can delay rendering.
• CSS Parsing -> CSSOM Tree
  It then parses all the CSS and builds the CSSOM Tree (CSS Object Model)
  External CSS files block rendering until fully downloaded and parsed. Without CSSOM, the browser can’t calculate layout — so rendering is delayed.
• DOM + CSSOM -> Render Tree
  These two trees are combined to form the Render Tree, which includes only the elements that will be visually rendered (visible nodes). Elements with display: none are excluded, but those with visibility: hidden still take up space and are included.
• Layout (Reflow)
  The browser calculates the position and size of every visible element — this is called the Layout Phase, or Reflow.
  It’s triggered by, DOM changes (adding/removing elements), Layout-affecting style changes (width, height, margin), Reading layout properties like offsetTop, clientHeight etc
• Paint (Repaint)
  Once layout is complete, the browser paints pixels for each element’s visual styles — including colors, borders, shadows, and text.
  Repaint is triggered when visual-only styles change without affecting layout.
• Composting
  Finally, the painted layers are combined (composited) into a single image and sent to our screen.
  If elements are on different layers (due to position: fixed, will-change, or GPU usage), compositing brings them all together.

Reflow: When the Browser Recalculates Layout

After the browser is done with constructing the render tree, it needs to figure out where each element goes on the screen, their position, size and how they are related with other elements.
This process is called Reflow, also known as the Layout phase.

What Triggers a Reflow?

So basically the reflow is triggered when:

• We add, remove or move DOM elements.
• We change layout-affecting CSS, like width, height, margin, position, etc.
• The window resizes or font loads (change in dimension)
• We read layout properties when layout is "dirty", offsetTop, scrollHeight, getBoundingClientRect(), etc

Why Is Reflow Expensive?

Reflow does not effect just one element, it can cascade through the following:

• Children (e.g., nested elements inside a resized container)
• Siblings (in a flex or grid layout)
• Even parents (if heights or widths depend on children)

The browser has to constantly re-calculate the layout tree and then trigger paint and compositing again. In large DOMs or animations, this becomes noticeably slow.

Repaint: When Only Visuals Change

After the layout is done, or the layout does not need to change at all, the browser still need to change the appearance of elements on the screen. This stage is called Repaint (also known as the Paint phase).

Unlike Reflow, which recalculates layout, Repaint simply redraws pixels for elements whose visual styles have changed.

What Triggers a Repaint?

Repaint is triggered when we make style changes that don’t affect layout.

• Changing, color, background-colour, border-color.
• Changing box-shadow, outline, text-decoration.
• Adjusting opacity.
• Updating visibility (but not display)
• Setting or animating CSS transitions for purely visual effects

Why Repaint Still Matters?

Repaint is less expensive than Reflow because it doesn’t affect layout. However:

• On large, complex elements (like a full-page div), repainting can still cause visible jitter
• Repaints during animations (e.g., rapidly changing background color) can drop frames if too frequent.

Repainting doesn't mean the browser will update the whole screen — but it will repaint the affected area, and that takes time as well.

Compositing: The Final Assembly of Layers

After painting is done, the browser has to assemble the painted elements into layers and combine them into a single image that can be sent to our screen.

Some elements may be placed into separate layers to improve rendering performance — especially when certain properties are used, like:

• position: fixed
• will-change
• transform (with GPU acceleration)
• opacity

These layers are independently painted and then merged (composited) in the final step.

Bonus: Pre-Paint in the Browser Rendering Cycle

Pre-Paint is the phase where the browser determines what needs to be painted, which regions are invalidated, and how layers should be updated — before the actual Paint phase begins.

It acts as a preparation step between Layout (Reflow) and Paint.

What Happens in the Pre-Paint Phase?

In the Pre-Paint phase, the browser:

• Identifies the regions of the screen that needs to be repainted
• Determines which elements will be affected
• Figures out which elements are part of separate layers (e.g., GPU layers)
• Decides how to schedule painting

It’s basically setup work for the Paint phase, but it’s critical for:

• Avoiding unnecessary painting
• Layer promotion/demotion decisions
• Efficient invalidation strategies

Thank you for reading. Sometimes performance isn’t about doing more — it’s about understanding how things work under the hood.