The Critical Rendering Path

How bytes become pixels — DOM → CSSOM → Render Tree → Layout → Paint → Composite — and the two resources that block it. The backbone topic that connects resource hints, async/defer, and Core Web Vitals.

1The pipeline, end to end

The Critical Rendering Path is the fixed sequence of steps the browser runs to turn HTML, CSS, and JS into pixels. Memorize it in three moves — construct the DOM and CSSOM in parallel (with JS able to interrupt the DOM branch to fetch/compile/run), combine them into the render tree, then render through layout → paint → composite. The shape matters: drawing the two branches merging — and showing where JS jams the parser — is what separates a Lead answer from a memorized list.

• DOM — the HTML parser builds a tree of nodes. It's incremental: the browser can start before the HTML is fully downloaded.
• CSSOM — all CSS is parsed into a tree of style rules. Unlike the DOM, this is not incremental for rendering (see §2).
• JS — not a tree, but a step inside DOM construction. When the parser hits a plain <script> it stops and runs the engine's own pipeline — fetch → parse + compile (bytecode) → execute — before resuming HTML parsing. That's why JS is parser-blocking; it also waits on any pending CSSOM (it may read computed styles) and can mutate the DOM mid-build. async/defer (§3) move this step off the critical parse.
• Render Tree — DOM + CSSOM merged, keeping only visible nodes. display:none is excluded; visibility:hidden stays (it occupies space).
• Layout (a.k.a. reflow) — computes the exact geometry of every node. Triggered by the viewport and box model.
• Paint — rasterizes pixels for text, colors, borders, shadows into paint layers.
• Composite — the GPU assembles layers in the right order. transform / opacity animations can run here alone — no layout, no paint — which is why they're cheap.

Sources: web.dev — Understand the critical path · MDN — Critical rendering path · MDN — <script> parsing & execution

2The whole interview is here: what blocks the path

Knowing the six boxes is table stakes. The Lead-level insight is which resources stall the pipeline, and why. There are exactly two villains.

That second sentence — “get script out of the parser's way” — is exactly what async and defer do. This is the rapid-fire question right after resource hints, so let's nail it.

3async vs defer — the script-loading lever

<script src="a.js"></script>              // parser STOPS: fetch + run, then resume
<script src="a.js" async></script>        // fetch in parallel, run ASAP, order NOT guaranteed
<script src="a.js" defer></script>        // fetch in parallel, run AFTER parse, IN ORDER

Attribute	Download	Executes	Order kept?	Blocks parser?
(none)	blocks parser	immediately, mid-parse	yes	yes
async	parallel	as soon as downloaded	no (whoever lands first)	only briefly, when it runs
defer	parallel	after parse, before DOMContentLoaded	yes	no

One more actor: the preload scanner

Even when a sync script blocks the parser, browsers run a secondary preload scanner that races ahead in the raw HTML and kicks off downloads for images, CSS, and scripts it spots. It's why fetches overlap instead of running strictly one-by-one — and why an inline script that injects resources defeats it (the scanner can't see resources that don't exist in the markup yet).

Sources: MDN — <script> (async/defer) · web.dev — Render-tree, Layout & Paint

4How a Lead optimizes the path

Optimization = shorten the path to first paint. Three concrete levers, all derived from §2:

• Shrink render-blocking CSS — inline critical CSS for above-the-fold, load the rest non-blocking (media tricks / rel=preload swap). Fewer bytes in the CSSOM = earlier first paint.
• Get JS off the parser — defer app code, async independent tags, code-split so less executes before interactive.
• Minimize critical resources / round-trips — the three knobs web.dev names: number of critical resources, their total bytes, and the critical path length (round-trips). [web.dev]

Notice how this chains to Lesson 01: resource hints make the critical bytes arrive sooner; the CRP is what the browser does with them. Next lesson connects the output of this path to the metrics — Core Web Vitals (LCP / INP / CLS).

5Check yourself — scenario quiz

Pick an answer; you get instant feedback. Push-back style, like the round.