Critical Rendering Path — Cheat Sheet

FE Lead prep · ref 02

The pipeline

DOMparse HTML

→

CSSOMparse CSS

→

Render Treevisible nodes

→

Layoutgeometry / reflow

→

Paintrasterize

→

CompositeGPU layers

JS step (inside DOM build): sync <script> → fetch → parse+compile → execute, then parsing resumes. Parser-blocking; also waits on pending CSSOM (may read computed styles).
Render tree = DOM + CSSOM, visible only. display:none excluded; visibility:hidden stays.
Composite-only (cheap, no layout/paint): transform, opacity. Animating width/top forces reflow.

What blocks the path (the whole interview)

Resource	Blocks	Why	Fix
CSS	rendering (render tree)	rules cascade → can't paint till CSSOM complete	inline critical CSS, load rest non-blocking
Sync JS	the parser (DOM)	can mutate DOM; also waits on pending CSS (may read styles)	`defer` / `async`, code-split

async vs defer

	async	defer
download	parallel	parallel
executes	ASAP on arrival	after parse, pre-DCL
order kept	NO	YES
use for	independent tags	app / ordered code

Optimize = shorten to 1st paint

↓ number of critical resources
↓ critical bytes
↓ critical path length (round-trips)
un-block: inline critical CSS, defer JS
Preload scanner races ahead in raw HTML — inline-injected resources defeat it

Lead one-liner (memorize)

Say first “Two things stall the page: CSS blocks painting, JS blocks parsing. So two fixes: ship less critical CSS, and get JS off the parser with defer/async.”

Sources: web.dev — critical path · MDN — CRP · MDN — <script> · web.dev — render tree

Don't fail the interview

1. CSS blocks rendering, not DOM construction — DOM & CSSOM build in parallel.

2. A sync script also waits for CSS — it may call getComputedStyle.

3. async = no order guarantee → only for independent scripts. Ordered code → defer.

4. Animate transform/opacity (composite), never width/top (reflow).