Browser Rendering Pipeline

Written by Backbone Tutorials Team

Last updated: June 2026 · 9 min read

Sixty times a second, the browser has to answer one question: what should the screen look like right now? Everything you write, the markup, the styles, the scripts, exists to feed that answer, and the machinery that produces it is the rendering pipeline. Learning its stages is the closest thing frontend work has to learning how the engine runs, because nearly every performance rule you have heard, animate transform, avoid layout thrash, do not block the parser, is just a consequence of how this pipeline works.

This guide opens the rendering cluster. It gives the platform foundation that frontend performance builds on, and the browser-side counterpart to how Googlebot renders pages.

From code to pixels

Before zooming into any one stage, it helps to see the whole assembly line. Each frame the browser shows is the output of a fixed sequence of steps, and the order of those steps explains their cost.

The stages at a glance

The browser parses HTML into the DOM and CSS into the CSSOM, combines them into a render tree of visible elements, computes layout to give each element a size and position, paints the result into pixels, and composites the painted layers into the frame on screen. The crucial property is that a change re-runs the pipeline from the stage it touches downward: alter geometry and you pay for layout, paint, and composite; alter only a compositor property and you pay almost nothing. That single rule drives most rendering performance advice.

Parsing: the DOM and CSSOM

Everything starts as text over the network, and the browser's first job is turning that text into structures it can work with. Two languages produce two trees.

Two trees from two languages

The HTML parser builds the DOM, a tree of elements that scripts can read and modify, while the CSS parser builds the CSSOM, the tree of style rules. Parsing is incremental, the browser starts building as bytes arrive, but it can be interrupted: a classic <script> without defer or async halts HTML parsing until it downloads and runs, because the script might change the document. That is why where and how you load scripts shapes how quickly the first stages of the pipeline can finish.

Style and layout

With both trees in hand, the browser must work out what is actually visible and where everything goes. This is where structure becomes geometry.

Computing what goes where

Style calculation matches CSSOM rules to DOM nodes and produces the render tree, which contains only visible elements with their computed styles; anything under display: none drops out here and costs nothing further. Layout, also called reflow, then walks that tree computing the exact box of every element. Because boxes depend on each other, one change can ripple widely, making layout the most expensive stage to trigger. Giving images explicit width and height is a small example of respecting it: the box is known up front, so late-arriving pixels do not shift the page.

Paint

Geometry alone is invisible. The next stage fills the computed boxes with actual pixels, and its cost is easy to underestimate.

Rasterizing the boxes

Paint rasterizes each element, text, backgrounds, borders, images, shadows, into bitmaps, usually split across several paint records. Its cost scales with the area painted and the effects applied: a large region with blur and layered shadows is dramatically more expensive to paint than flat color. When a visual change does not move anything, the browser can skip layout and repaint only the damaged region, which is cheaper, but heavy paint on a big area can still miss the frame budget on its own.

Compositing and layers

The final stage is the one that makes modern scrolling and animation smooth. Rather than repainting the world for every change, the browser assembles it from pieces.

Assembling the frame from layers

/* Compositor-only changes: no layout, no paint */
.card {
  transition: transform .2s ease, opacity .2s ease;
}
.card:hover { transform: translateY(-4px); }

The page is split into layers that are painted once and then composited, positioned, blended, and combined, often on the GPU, by a compositor that can run off the main thread. transform and opacity are special because the compositor can apply them to existing layers without rerunning layout or paint, which is why they animate smoothly even while the main thread is busy. Animating top or width instead drags the whole pipeline back through layout on every frame.

JavaScript and the pipeline

Scripts do not stand outside this machinery; they share its thread. How your code schedules its work decides whether the pipeline gets its turn.

Working with the frame, not against it

// Align visual updates with the next frame
requestAnimationFrame(function () {
  box.style.transform = 'translateX(' + x + 'px)';
});

Style, layout, paint, and your JavaScript all compete for the same main thread, so a long task delays the next frame and the page visibly stutters, the responsiveness problem frontend performance framed with a roughly sixteen-millisecond budget per frame. requestAnimationFrame schedules visual updates right before the browser renders, so changes land once per frame instead of fighting it. Treat the pipeline as a collaborator with a deadline: do your work early, hand it compositor-friendly changes, and it will keep the screen smooth. The next guide moves up a level, following the rendering lifecycle of an application from state change to painted frame.

Read next: the Rendering hub for the full cluster, or frontend performance for the budgets this pipeline must meet.