Critical Rendering Path
The Critical Rendering Path is the sequence the browser follows to turn HTML, CSS, and JavaScript into pixels on the screen. The interview-safe version is: HTML parsing builds the DOM, CSS builds the CSSOM, both combine into the Render Tree, followed by Layout (geometry), Paint (pixels), and Composite (GPU layers).
The browser is a factory. Raw materials (HTML bytes) enter → get shaped into parts (DOM & CSSOM) → assembled into a blueprint (Render Tree) → positioned (Layout) → painted (Paint) → finally put together on the screen by the GPU (Composite).
1Step 1 — HTML Parsing & DOM Construction
The browser starts parsing HTML incrementally as soon as bytes arrive. A preload scanner runs in parallel to discover CSS, JS, fonts, and images early.
<script src="app.js"></script> <!-- parser-blocking --> <script async src="app.js"></script> <!-- loads parallel, executes ASAP (unordered) --> <script defer src="app.js"></script> <!-- loads parallel, executes after parse -->
2Step 2 — CSS Parsing & CSSOM Construction
CSS is render-blocking by default. The browser needs the CSSOM before first paint.
3Step 3 — Render Tree Construction
Combines DOM + CSSOM. Excludes non-visual nodes and adds pseudo-elements (::before, ::after).
4Step 4 — Layout (Reflow)
Calculates geometry. Expensive. Avoid layout thrashing (e.g. reading offsetHeight after style changes).
5Step 5 — Paint
Fills pixels (text, backgrounds, borders, images).
6Step 6 — Composite
GPU combines layers. Cheap for transform & opacity.
| Property | display: none | visibility: hidden |
|---|---|---|
| Behavior | Removes element from Render Tree entirely | Keeps element in Render Tree but invisible |
| Use Case | Hiding elements that should not occupy space | Hiding while preserving layout |
| Impact On Layout | No space reserved, flow is broken | Full layout space is reserved |
display: none
Behavior
Removes element from Render Tree entirely
Use Case
Hiding elements that should not occupy space
Impact On Layout
No space reserved, flow is broken
visibility: hidden
Behavior
Keeps element in Render Tree but invisible
Use Case
Hiding while preserving layout
Impact On Layout
Full layout space is reserved
Common questions
- ›“Walk me through the Critical Rendering Path.”
- ›“What blocks First Contentful Paint and how do you optimize it?”
- ›“Explain parser-blocking vs render-blocking.”
- ›“How do defer and async scripts affect the CRP?”
What interviewers look for
- Clear distinction between parser-blocking and render-blocking
- Knowledge of preload scanner and Render Tree synchronization
- Mapping optimizations to pipeline stages
- Understanding async vs defer behavior
Short answer (60 sec)
HTML → DOM + CSSOM → Render Tree → Layout → Paint → Composite. CSS is render-blocking, synchronous JS is parser-blocking.
Detailed answer (senior level)
The full pipeline includes preload scanning, style recalculation, rasterization, and GPU compositing. Render Tree is the key sync point. Use defer for scripts and inline critical CSS to improve FCP.
- Thinking CSS blocks parsing (it blocks rendering)
- Confusing async and defer
- Believing Layout happens before Render Tree
- Treating Paint and Composite as identical
- ✓Simplified CRP (interview answer): DOM + CSSOM → Render Tree → Layout → Paint → Composite
- ✓CSS blocks rendering. Synchronous JS blocks parsing.
- ✓async = parallel + immediate execution (unordered). defer = parallel + after parsing.
- ✓Animate transform/opacity → stays in Composite stage.
- ✓Batch reads/writes to avoid layout thrashing.
Related web fundamentals topics
Continue with closely related browser and frontend engineering concepts.