Episode 1 — Fundamentals / 1.5 — Semantic HTML and Browser Rendering
1.5.a — The Browser Rendering Pipeline
In one sentence: The browser turns network bytes into structured trees, resolves styles, computes geometry, paints pixels, and composites layers — and your HTML/CSS/JS choices determine how often and how expensively that happens.
Navigation: ← 1.5 Overview · 1.5.b — Reflow & Repaint →
1. Why this mental model matters
When a page feels slow, janky, or “broken,” the fix almost always maps to a stage of the pipeline:
- Wrong or huge HTML → more parsing and DOM work
- Expensive selectors or layout thrashing → extra layout
- Huge paint areas or frequent style changes → extra paint
- Animations that fight the compositor → dropped frames
You do not need to memorize engine internals — you need a reliable story you can draw on a whiteboard.
2. End-to-end: from response body to pixels
Step A — Download & decode
The browser receives HTML (often streamed). It can start parsing before the full document arrives. CSS and JavaScript files referenced in the document are discovered and fetched (subject to parser blocking rules for classic scripts).
Step B — Parse HTML → DOM
The HTML parser builds the Document Object Model (DOM): a tree of element nodes, text nodes, and attributes. Invalid HTML is repaired per the spec — do not rely on “the browser will fix it” as a strategy; it creates surprises.
Step C — Parse CSS → CSSOM
CSS rules become the CSS Object Model (CSSOM): which selectors apply to which properties, including cascade and inheritance. The CSSOM plus DOM feeds the next step.
Step D — Render tree (styled tree)
The engine combines DOM + computed styles into a render tree (roughly: what needs to be drawn, including boxes generated for pseudo-elements). Non-visual elements (e.g. head, display: none) are omitted from painting.
Step E — Layout (reflow)
For each visible node, the engine computes geometry: position, size, line breaks, scrollable overflow. This step answers: “Where on the viewport does every box live?”
Step F — Paint
Paint fills pixels: text, colors, borders, shadows, images (bitmap work). Some effects are cheap; some (large shadows, expensive filters) are not.
Step G — Composite
Modern browsers often promotes parts of the page to layers (GPU textures) and composites them. Compositing is how many animations stay smooth: transform/opacity changes can often skip layout and paint.
3. ASCII: the happy path
HTML bytes CSS bytes JS (can mutate DOM/CSSOM)
│ │ │
▼ ▼ ▼
[ DOM ] + [ CSSOM ] ─────────► [ Render tree ]
│
▼
[ Layout ]
│
▼
[ Paint ]
│
▼
[ Composite ]
│
▼
Pixels on screen
4. Critical rendering path (CRP)
The critical rendering path is the minimum sequence needed to show first meaningful pixels — typically: HTML → CSS needed for above-the-fold → layout → paint → composite.
Practical levers (preview):
- Inline or prioritize critical CSS for first paint (advanced pattern)
- Avoid synchronous JS in
<head>that blocks HTML parsing withoutdefer/module - Ship right-sized images (see 1.5.h)
- Reserve space for media to reduce CLS (see 1.5.b and 1.5.h)
5. JavaScript’s special role
JavaScript can invalidate every downstream stage:
- DOM API calls change structure → may require layout and paint
- Style reads after writes (or vice versa) in tight loops can force synchronous layout (classic performance bug)
requestAnimationFramealigns visual work with the display refresh — prefer it over randomsetTimeoutfor animation
6. Key takeaways
- DOM + CSSOM → render tree → layout → paint → composite is the default story.
- Layout is geometry; paint is pixels; composite is layered assembly.
- Semantics (
<main>, headings, lists) do not replace this pipeline — they make the DOM meaningful for users and tools (see 1.5.c). - Performance tuning starts with identifying which stage you are accidentally repeating.
Explain-It Challenge
Explain without notes:
- The difference between the DOM and what you see on screen (what sits in between?).
- Why “only change
transformandopacity” is common animation advice (which stages might be skipped?). - One way parser-blocking JavaScript can delay first paint.
Navigation: ← 1.5 Overview · 1.5.b — Reflow & Repaint →