Every time a page scrolls, animates a button or switches theme, your browser is running a production chain that repeats dozens of times per second. It is not magic: it is the rendering pipeline —the set of stages that turn HTML and CSS into the pixels you see on screen— with such a strict time budget that every millisecond counts.
From text to a tree: the DOM and the CSSOM
It all starts when the browser receives the HTML. It parses it and builds the DOM (Document Object Model), a tree-shaped structure where every <div>, <p> or <img> tag becomes a node with its attributes. In parallel, the style sheets are turned into the CSSOM (CSS Object Model), another tree that stores which rules apply to each element and in what order.
Here comes the first costly decision: specificity. When two rules compete for the same element, the browser works out which one wins by adding up id, class and tag selectors. The more nested selectors you use, the more matching work the engine has to do.
The render tree and layout
The DOM and the CSSOM merge into the render tree, which only includes the visible elements: those with display: none or outside the viewport stay out. On top of that tree runs the layout (also called reflow), the phase where the browser computes the exact position and size of every box in pixels.
Layout is one of the most expensive stages, because a change in one element can propagate to its children, its siblings or even the whole page. That is why changes to width, height or position hurt performance the most: they force the full geometry to be recalculated before anything can be painted.
Painting and rasterizing
With the boxes measured, the painting phase arrives: the browser draws the colours, borders, shadows and text of each element onto a canvas, respecting the stacking order (including the z-index). Next, rasterization converts those vector drawing commands into a grid of pixels, usually delegating the work to the GPU (Graphics Processing Unit), the graphics card that accelerates pixel filling in parallel.
To avoid repainting the whole page on every change, the browser splits the content into layers. A layer with transform: translateZ(0) or will-change: transform is rasterized once and then only moved. That separation is the basis of smooth animations: moving an already-rasterized layer does not require recalculating layout or repainting.
Compositing and the 60 Hz frame
The last stage is compositing: the browser blends all the rasterized layers in the correct order and delivers the final result to the screen. This step runs on the GPU and is the cheapest of all.
A typical screen refreshes 60 times per second (60 Hz), meaning a complete frame must be produced every 16.6 milliseconds. If the pipeline takes longer than that budget, the browser drops frames and the page looks choppy (what is known as jank). That is why developers use requestAnimationFrame to sync their animations with the screen refresh, instead of arbitrary timers.
Repaint versus reflow
Not all changes cost the same. Changing an element’s colour only triggers a repaint: it is painted and composited again, but the geometry is not recalculated. In contrast, changing the width, the font or inserting a node triggers reflow, which drags layout, painting and compositing along. The practical rule is simple: to animate, move layers with transform and opacity, which only touch compositing, and avoid animating layout properties such as width, top or margin.
The invisible budget
The rendering pipeline is a reminder that the browser works with finite resources and a relentless clock. Understanding its stages —parsing, building the render tree, computing layout, painting, rasterizing and compositing— is the difference between a page that feels instant and one that stutters at the first scroll. Next time a website glides smoothly, you know what is happening behind the screen: a pixel factory that cannot afford a single extra millisecond.
