Questions › Browser

The critical rendering path

RenderingMediumBrowser

How does the browser turn HTML, CSS, and JS into pixels? Why is CSS render-blocking and where does JS block parsing?

What it tests

Whether you know DOM+CSSOM→render tree→layout→paint and what blocks each step.

Approach & answer

The critical rendering path is the sequence the browser runs to first paint: (1) parse HTML into the DOM tree incrementally; (2) parse CSS into the CSSOM; (3) combine DOM + CSSOM into the RENDER TREE (only visible nodes — display:none nodes are excluded); (4) LAYOUT (reflow) computes each box's exact position and size; (5) PAINT rasterizes pixels; (6) COMPOSITE assembles layers. CSS is render-blocking: the browser won't paint until the CSSOM is ready, because it would otherwise flash unstyled content — so ship critical CSS small and early. A synchronous <script> (no async/defer) is PARSER-blocking: when the parser hits it, it must stop building the DOM, download and execute the script (which can also read/modify the not-yet-complete CSSOM/DOM), then resume — which is why scripts traditionally go at the end of <body>. defer downloads in parallel and runs after parsing in order; async runs as soon as it downloads, order not guaranteed. Optimizations: inline critical CSS, defer non-critical JS, preload key assets, minimize the number of round-trips before first paint.

Use this technique when

Optimizing first paint / LCP: shrink render-blocking CSS, defer JS, preload above-the-fold assets.

Code

DOM  ─┐
       ├─► Render Tree ─► Layout (reflow) ─► Paint ─► Composite
CSSOM ─┘

CSS  = render-blocking (no paint until CSSOM ready)
<script>          = parser-blocking (stops DOM construction)
<script defer>    = runs after parse, in order
<script async>    = runs on download, order not guaranteed

References