How does the browser parse HTML and build the page (critical rendering path)?

Question

Accepted Answer

The **critical rendering path** is the sequence of steps the browser takes to turn HTML, CSS, and JS into pixels. Understanding it explains what blocks rendering and how to make pages paint faster. ## The steps ```text 1. Parse HTML → DOM tree (the document structure) 2. Parse CSS → CSSOM tree (the style rules) 3. DOM + CSSOM → Render tree (visible nodes + their styles) 4. Layout (reflow) → compute each node's geometry (position/size) 5. Paint → fill in pixels (colors, text, images) 6. Composite → combine layers onto the screen ``` ## What blocks rendering **CSS is render-blocking.** The browser won't paint until the CSSOM is ready (to avoid a flash of unstyled content). So large/slow CSS delays first paint — keep critical CSS small and inline it when possible. **Synchronous scripts are parser-blocking.** A plain ` ``` Worse, a synchronous script that needs the CSSOM (e.g. reads computed styles) waits for CSS too — so a CSS file can indirectly block a script, which blocks the parser. ## How to optimize it - Put CSS in `` (load it early); inline critical CSS. - Add `defer` (or `type="module"`) to scripts, or place them before ``. - Minimize and compress CSS/JS; remove unused rules. - Use `preload` for critical fonts/assets, `preconnect` for key origins. - Avoid layout thrashing (repeated read/write of layout in JS) — it forces extra reflows. ## Why it matters The critical rendering path determines metrics like First Contentful Paint and Largest Contentful Paint. Knowing that CSS blocks rendering and synchronous JS blocks parsing tells you exactly why `defer`/`async`, inlined critical CSS, and resource hints speed up a page — they shorten or unblock this path.