Critical Rendering Path

⏱️ ~3-minute bite · solve the sandbox to master

0%lesson

🧒

5-Year-Old Metaphor

— The physical, real-world picture. No jargon.

🏠 Building a house — you can't paint before measuring, and you can't move in without permits.

The construction analogy

HTML = the blueprint. Your architect's plans define every room, wall, and doorway. Without the blueprint, the contractor (browser) can't build anything. This is the DOM — the structural skeleton of your page.

CSS = paint and finish specifications. You know which walls get which color, what flooring goes where. You can't apply finishes until you know what they are — so CSS is render-blocking. The CSSOM is the browser's complete understanding of every style rule.

Blocking resources = waiting for permits. A blocking <script> is like a building permit that stops all construction until an inspector signs off. The entire crew (parser) waits, doing nothing, until the permit clears. async and defer are like getting a fast-track permit that doesn't pause the crew.

Render Tree = contractor's final working plan. The contractor combines the blueprint (DOM) with the finish specs (CSSOM) and marks which rooms will actually be visible. Sealed-off storage rooms (display:none) are crossed off entirely. Rooms with the lights off (visibility:hidden) are measured but not painted.

Layout = measuring every room. Before a single brushstroke, the contractor measures every dimension precisely — box model, margins, padding. Change a wall (reflow) and everything must be re-measured.

Paint = applying paint and wallpaper. Pixels are filled in. A color change means repainting, but no re-measuring.

Composite = hanging the art on the GPU wall. Separate layers (CSS layers, transforms) are assembled on the GPU — the fastest, most parallel step. Animations using transform happen here, completely bypassing Layout and Paint.

ASCII: the full CRP pipeline

1	HTML bytes → [Parse] → DOM
2	CSS bytes → [Parse] → CSSOM
3	DOM + CSSOM → [Render Tree] → [Layout] → [Paint] → [Composite] → 🖥️
4
5	Blocking resources:
6	<script> → STOPS parser entirely (use async/defer)
7	<link rel=css> → STOPS rendering (not parsing)
8	CSS @import → SERIALIZES downloads (use <link> instead)
9
10	Animation cost:
11	width/height/top/left → Layout → Paint → Composite (expensive)
12	color/background → Paint → Composite (moderate)
13	transform/opacity → Composite (GPU only — FREE)

The critical rule — what "render-blocking" really means

A resource is render-blocking if the browser will not paint a single pixel until that resource is downloaded and processed. CSS stylesheets are always render-blocking by default. Scripts are parser-blocking AND render-blocking unless marked async or defer. Your LCP (Largest Contentful Paint) score is directly determined by how many render-blocking resources sit in the critical path.

The 5 CRP phases at a glance

📄HTML Parsing

Bytes tokenized into DOM nodes. <script> blocks the parser.

🌳DOM Construction

DOM tree built. <link rel=css> blocks rendering (not parsing).

🎨CSSOM Construction

CSS parsed into cascade tree. @import chains are serialized.

🌐Render Tree

DOM + CSSOM merged. display:none excluded. visibility:hidden included.

🖌️Layout→Paint→Composite

Geometry calculated, pixels filled, GPU layers assembled.

🎛️

Interactive Sandbox

— Move something, see it react instantly.

Phase

HTML bytes are tokenized into DOM nodes. A blocking <script> tag stops the parser entirely.

Waterfall timeline

free

Download HTML20ms

Network fetch

free

Tokenize5ms

Bytes→tokens

free

Build DOM15ms

Tokens→nodes

BLOCK

Parser STOPS. Script must download+execute before DOM continues

free

Resume parsing8ms

Only after script completes

Step 1/5: Download HTML —Network fetch

1 / 5

⚠️ Gotcha: Even <script async> blocks if it finishes loading before the parser reaches it.

💡 Insight: async downloads in parallel but executes immediately on load, potentially blocking. defer always executes after parsing completes, in order.

✅ Optimization: Use async or defer on non-critical scripts. Inline critical JS.

Completed:📄🌳🎨🌐🖌️

🎯

Challenge

Step through all 5 CRP phases to the final step. Note which steps block rendering — that's what controls your page's time-to-first-paint.

Try it

🎯

Why Should I Care?

— The exact interview question + the bug it kills.

Exact interview questions

Q: What makes a resource render-blocking?

A resource is render-blocking if the browser must download and process it before it can render any content to the screen. CSS stylesheets are render-blocking by default because the browser needs the complete CSSOM to build the render tree — rendering without it would cause a flash of unstyled content. Scripts are both parser-blocking and render-blocking unless tagged async or defer. The critical path is the sequence of render-blocking resources that determine Time to First Paint.

html

1	<!-- Render-blocking — slows first paint -->
2	<link rel="stylesheet" href="styles.css" />
3	<script src="app.js"></script>
4
5	<!-- Not render-blocking -->
6	<link rel="stylesheet" href="print.css" media="print" />
7	<script src="analytics.js" defer></script>
8	<link rel="preload" href="font.woff2" as="font" crossorigin />

Q: Why does JavaScript block HTML parsing?

JavaScript can manipulate the DOM via document.write() and can query the DOM layout, so the browser must stop parsing HTML when it encounters a synchronous <script> tag. If parsing continued and the script tried to access a node that hasn't been parsed yet, the result would be non-deterministic. The browser has a preload scanner that speculatively downloads script src URLs even while the parser is blocked — but execution still waits.

html

1	<!-- Blocks parser — bad for performance -->
2	<script src="heavy.js"></script>
3
4	<!-- Downloads in parallel with parsing, executes immediately on load -->
5	<script src="heavy.js" async></script>
6
7	<!-- Downloads in parallel, executes after DOM is complete, in order -->
8	<script src="heavy.js" defer></script>
9
10	<!-- Inline critical JS — no download, no blocking -->
11	<script>window.__INITIAL_STATE__ = {...};</script>

Q: How does async vs defer differ?

Both async and defer download the script in parallel with HTML parsing. The difference is when execution happens. async executes immediately when downloaded — it may interrupt parsing if the download finishes early. Scripts can execute out of order. defer always executes after parsing completes, in document order, before DOMContentLoaded. Use defer for scripts that depend on the DOM or each other.

1	async behavior:
2	HTML: ──────────────────[PARSE CONTINUES]───────── DOMContentLoaded
3	Script download: ────[downloaded]
4	Script execute: ^^^executes immediately (may interrupt parser)
5
6	defer behavior:
7	HTML: ──────────────────────────────────[DONE]──── DOMContentLoaded
8	Script download: ────────[downloaded]
9	Script execute: ^^^executes here (in order)
10
11	Rule of thumb:
12	- <script defer> for DOM-dependent scripts (use 99% of the time)
13	- <script async> for independent scripts (analytics, ads)
14	- neither only for tiny inline critical bootstraps

Production impact: real LCP numbers

Common mistake: CSS @import chains in production

Each @import is discovered only after the parent CSS is downloaded and parsed. Three levels of @import = three sequential waterfall hops before the browser has any styles at all. On a 50ms RTT connection, that's 150ms of avoidable delay before first paint — often the difference between a "good" and "needs improvement" LCP score.

1	/* ✗ Serialized — catastrophic for LCP */
2	/* main.css */
3	@import url('typography.css'); /* discovered at T=30ms */
4	/* typography.css */
5	@import url('variables.css'); /* discovered at T=60ms */
6	/* variables.css — finally usable at T=90ms */
7
8	/* ✓ Parallel — all start downloading immediately */
9	<link rel="stylesheet" href="main.css" />
10	<link rel="stylesheet" href="typography.css" />
11	<link rel="stylesheet" href="variables.css" />

Common mistake: animating layout-triggering properties

Animating top, left, width, or height triggers layout (reflow) on every frame — the browser must recalculate geometry for the entire document subtree. On complex pages this can drop from 60fps to 15fps. The fix: animate transform: translate() instead, which runs on the GPU compositor thread and never touches the main thread layout engine.

1	/* ✗ Forces Layout → Paint → Composite every frame */
2	.slide-in { transition: left 300ms ease; }
3
4	/* ✓ Compositor-only — no Layout, no Paint, no main-thread cost */
5	.slide-in { transition: transform 300ms ease; }
6	/* Then move it: transform: translateX(200px) */

🔬

The Deep Dive

— Spec refs, engine internals, the minutiae.

Browser preload scanner

When the HTML parser is blocked by a synchronous script, the browser's preload scanner (also called speculative parser) continues scanning the raw HTML bytes looking for resources to fetch. It finds src attributes on scripts, href on stylesheets, and src on images — and starts downloading them speculatively.

The preload scanner cannot execute JavaScript or apply CSS — it only fetches. But on a high-latency connection, discovering and downloading resources speculatively while a blocking script executes can save hundreds of milliseconds.

html

1	<!-- Preload scanner can discover these even while <script> blocks parser -->
2	<head>
3	<script src="blocker.js"></script> <!-- blocks parser -->
4	<link rel="stylesheet" href="main.css" /> <!-- preload scanner fetches this -->
5	<script src="app.js" defer></script> <!-- preload scanner fetches this -->
6	<img src="hero.jpg" /> <!-- preload scanner fetches this -->
7	</head>

Resource hints: preconnect, preload, prefetch

Opens the TCP/TLS connection to a third-party origin early — before the resource is actually needed. Saves 100-300ms when you know a resource will be fetched from an external CDN. Use for fonts, analytics, API endpoints.

html

1	<link rel="preconnect" href="https://fonts.googleapis.com" />
2	<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin />

Fetches a resource with high priority and stores it — but does NOT execute it. Useful for fonts (eliminate FOUT), critical CSS split from a bundle, or hero images referenced from CSS (which the preload scanner can't see).

html

1	<!-- Preload LCP image — browser fetches at highest priority -->
2	<link rel="preload" href="/hero.webp" as="image" />
3
4	<!-- Preload font — eliminates FOUT -->
5	<link rel="preload" href="/Inter.woff2" as="font" type="font/woff2" crossorigin />

Fetches a resource with low priority for likely future navigation — it doesn't help current page performance at all. The browser fetches it when idle. Used for next-page bundles in SPAs.

html

1	<!-- Prefetch chunk for the next route the user is likely to visit -->
2	<link rel="prefetch" href="/chunks/settings-page.js" />

HTTP/2 prioritization and the CRP

HTTP/1.1 limited browsers to 6 concurrent connections per origin — creating artificial queuing even for non-blocking resources. HTTP/2 multiplexes all requests over a single TCP connection with stream prioritization: the browser signals which resources it needs first, and the server sends them at higher bandwidth allocation.

Chrome's network stack uses a priority system: CSS and blocking scripts get Highest priority; preloads, fonts get High; async scripts Low; prefetch Lowest. On HTTP/2, this means critical-path resources arrive faster even when many resources are in flight simultaneously.

LCP and its relationship to the CRP

Largest Contentful Paint (LCP) — the Core Web Vital that measures when the largest above-the-fold element becomes visible — is directly gated by the CRP. Any render-blocking resource delays LCP. Common LCP killers:

Render-blocking stylesheets before the LCP image — the image can't paint until CSS is parsed.
LCP image in CSS background-image — the preload scanner can't see it; use <img> or <link rel="preload">.
Lazy-loading the LCP image — never add loading="lazy" to the LCP candidate. Use fetchpriority="high" instead.

html

1	<!-- ✗ Kills LCP — lazy-loaded LCP candidate -->
2	<img src="hero.webp" loading="lazy" alt="Hero" />
3
4	<!-- ✓ Optimal LCP setup -->
5	<link rel="preload" href="hero.webp" as="image" fetchpriority="high" />
6	<img src="hero.webp" fetchpriority="high" alt="Hero" />

will-change — promoting layers proactively

will-change: transform tells the browser to promote an element to its own compositor layer before any animation starts. This eliminates the one-time "layer promotion" cost at animation start — useful for elements that animate frequently (menus, modals, carousels).

Overusing will-change wastes GPU memory — each layer is a texture upload. Apply it only to elements that will definitely animate, and remove it after animation completes if possible.

1	/* ✓ Apply to elements that animate frequently */
2	.dropdown-menu {
3	will-change: transform, opacity;
4	}
5
6	/* ✓ Or apply dynamically in JS */
7	element.addEventListener('mouseenter', () => {
8	element.style.willChange = 'transform';
9	});
10	element.addEventListener('animationend', () => {
11	element.style.willChange = 'auto'; // release layer
12	});

Quick reference table

Change type	Triggers	Cost
width, height, margin, padding, top, left	Layout + Paint + Composite	🔴 Expensive
color, background, box-shadow, border-color	Paint + Composite	🟡 Moderate
transform, opacity	Composite only	🟢 GPU-free
display:none → block	Layout + Paint + Composite	🔴 Expensive
visibility:hidden → visible	Paint + Composite	🟡 Moderate

🎤

Interview Questions

— Real questions from real interviews — with answers.

HTML parse → CSSOM → render tree → layout → paint → composite. CSS and sync scripts are blocking.

Both download in parallel; async executes immediately on load, defer executes after parsing in order.

top/left triggers Layout+Paint+Composite on the main thread; transform goes straight to the compositor (GPU).

It speculatively scans HTML bytes for resources to fetch even while the parser is blocked.

It promotes the element to a GPU compositor layer before animation starts, eliminating one-time promotion cost — but wastes VRAM if overused.

LCP is the largest above-the-fold element to paint. Optimize by removing render-blocking resources from the critical path and preloading the LCP image.

🎮

Memory Game

— Quick quiz — lock the concept in long-term memory.

1/4

What is the Largest Contentful Paint (LCP) metric?