Critical Rendering Path

The problem

The HTML arrives, and the page doesn’t appear. It feels as though the browser should be able to show something the moment it has the text. Why can’t it?

Because showing a page isn’t one step. The browser has to build two separate models, combine them, work out where every box goes, then draw. Each stage needs the output of the one before it, and some of them need things from the network. If one input is late, everything behind it waits.

That sequence is the critical rendering path. The widget below runs it for a whole page load.

Things to try

1. Watch the red card. Drag the CSS size up. The DOM finishes early, but the render tree sits blocked until the CSSOM exists.
2. Stop the parser. Tick the synchronous script. The DOM card goes red, because the parser can’t continue, and the script itself waits for the CSS first.
3. Make the hero huge. First paint doesn’t move, but the largest paint does. Different metrics measure different parts of the path.
4. Hide the text. Tick the web-font option: the page paints at first paint, but there’s nothing readable until the font lands.
5. Break the layout. Remove the image’s dimensions and watch Layout and Paint run a second time (the ×2), and the text jump.
6. Fix it. Press “…then fix the CSS”, or tick “Inline critical CSS”, and compare first paint to the broken version.

The stages

HTML → DOM

The parser turns markup into a tree of nodes, and it does so incrementally as bytes arrive. It doesn’t wait for the whole document. While it parses, a lookahead “preload scanner” spots stylesheets, scripts and images early so their downloads can start.

CSS → CSSOM

Stylesheets are parsed into a model of every rule. The browser can’t safely use a partial CSSOM, because a later rule can override an earlier one, so it waits for all render-blocking CSS. That is why CSS is “render-blocking”.

Render tree

The DOM and the CSSOM are combined, keeping only what is visible and attaching its computed styles. display: none content isn’t in it.

Layout

Computes the size and position of every box. Sometimes called reflow. If a size changes later, layout has to run again.

Paint

Turns boxes into pixels: backgrounds, text, borders, images, in layers.

Composite

Layers are combined and sent to the screen, largely off the main thread. This is why animating only transform and opacity is cheap: those changes can skip layout and paint entirely.

Two kinds of blocking

Render-blocking resources (normally stylesheets in <head>) stop the browser from painting. Parser-blocking resources (a classic <script>) stop it from building the DOM, because the script might change the page as it runs.

They interact. A script has to wait for any stylesheet still loading, in case the script asks what colour something is. So a synchronous script after a big stylesheet makes both problems worse, as you saw in the widget.

Problems and what fixes them

Big render-blocking CSS

Ship less CSS. Inline the small amount needed for the first view and load the rest without blocking, or split styles by media or route. The widget’s “inline critical CSS” does this. The trade-off: the rest of the CSS arrives later and causes a restyle, and critical CSS must be kept in sync as the design changes.

Blocking script

defer runs the script after parsing, in order. async runs it as soon as it arrives, in any order. Module scripts are deferred by default. Neither makes the script itself cheap, as Experiment 03 showed.

Oversized image

It won’t delay first paint, but it sets your largest paint. Right-size and compress it, and don’t lazy-load it. See Experiment 02.

Web font

The font is requested only after the render tree exists. Choose a font-display behaviour, preload it, and keep it small. See Experiment 04.

Layout shift

Give images and embeds dimensions so layout runs once. Anything that changes a box’s size later forces layout, and often paint, again.

Common misconceptions

See it on a real page

1. Open DevTools, then Performance, and record a reload with CPU throttling on. In the Main track you’ll see Parse HTML, Recalculate Style, Layout, Paint and the same stalls as above. The Timings track marks FP, FCP and LCP.
2. In Network, look at what is requested before first paint, and which requests are marked render-blocking.
3. Ask the browser for the paint timings:

   performance.getEntriesByType('paint').forEach((e) => console.log(e.name, Math.round(e.startTime)));

4. In the Rendering panel, turn on Layout shift regions and Paint flashing to see what re-runs and what jumps.
5. Lighthouse’s “Eliminate render-blocking resources” and “Avoid large layout shifts” audits point at the same causes.

Model assumptions