Reference guide · performance · Published 2026-08-15 · 3 min read
The critical rendering path
The critical rendering path explained: parse, CSSOM, render tree, layout and paint, and why script and stylesheet order decides first paint.
- ·The pipeline
- ·Why order matters
- ·Measure with Lighthouse
The pipeline
The critical rendering path is the sequence a browser follows to turn a URL into the first painted frame. Every page walks the same order:
- HTML parse. The browser reads the bytes, tokenizes tags, and builds the Document Object Model (DOM).
- CSSOM build. CSS, whether inline or from
<link>stylesheets, becomes the CSS Object Model (CSSOM). - Render tree. The browser combines the DOM and CSSOM into a tree of nodes that will actually paint, skipping
display: noneand pseudo-elements. - Layout. Also called reflow, it computes geometry: sizes, positions, and the final boxes.
- Paint. It draws pixels to the screen.
Every one of those steps must complete for the first visible frame, and they run on the main thread. A page-wide stylesheet, a synchronous script mid-body, or a slow hero image lengthens the walk.
What the browser waits for
Some resources extend the path, and some do not:
| Resource | Effect on the path |
|---|---|
CSS in <head> | Blocks paint until its stylesheet arrives and builds |
JS before <body> ends | Blocks parsing and the path entirely |
JS with defer | Downloads in parallel, runs after the DOM |
JS with async | Downloads in parallel, runs when ready (no ordering) |
| Images, fonts | Do not block first paint, but move LCP time |
The name for a resource the browser must wait on is a render-blocking resource. CSS is blocking by default, JavaScript is blocking by default, and both are the target of first-paint optimisations.
Why order matters
The order of the steps is a constraint, not a suggestion. The CSSOM cannot be built until the last stylesheet the HTML needs arrives; a script that sits between two sheets pauses the parser while it downloads and runs. The consequence: the smallest element that changes above-the-fold can slide the entire timeline for a complex page. A hero image that arrives after a deferred CSS bundle paints later than it should, even though its download finished earlier.
The practical rules:
- Push parsing JavaScript out of the path with
defer. - Inline the CSS that styles the first screen; move the rest behind a loader.
- Preload the largest element so its request is already in flight when parsing reaches it.
- Never let layout-reading JavaScript run on an interaction-heavy path; it forces layout on every touch. The heavy site page shows the long-task cost of doing so.
Measure with Lighthouse
Lighthouse's "Largest Contentful Paint element" and "Eliminate render-blocking resources" audits report the path in measurable legs: the server time, the resource time, and the render time of the LCP candidate. The LCP optimisation page turns those legs into their fixes. A page that walks this path fast looks the same as any other page to the user; what they feel is the first frame arriving sooner, which is exactly what the render path decides.