Critical Rendering Path: Understanding Browser Rendering

Best Answer for Interviews

B) HTML parsing → DOM → CSSOM → Render Tree → Layout → Paint → Composite

This is the best high-level answer among the choices.

Important Nuance

The real browser pipeline is more incremental than the option suggests:

So B is the best conceptual choice, even though real rendering is not a single rigid linear pipeline.

HTML Parsing → DOM

When the browser receives HTML:

1. Bytes are decoded into characters

2. Characters are tokenized

3. Tokens are parsed into nodes

4. Nodes are attached to the DOM tree

This produces a DOM structure representing the document.

Key Point

HTML parsing is incremental. The browser does not wait for the full document before starting to parse.

JavaScript Interaction

A normal script like this can pause parsing:

The parser stops, the script is fetched/executed, and only then does HTML parsing continue.

That is why defer is so important for non-critical scripts.

CSS Parsing → CSSOM

When the browser discovers CSS:

it fetches and parses the stylesheet into the CSSOM (CSS Object Model).

The CSSOM contains style rules after resolving:

Why CSS Matters for Rendering

The browser generally needs CSS before first render because it must know how visible DOM nodes should be styled.

Examples:

So although HTML parsing may continue while CSS is loading, CSS is effectively render-blocking for first paint by default.

DOM + CSSOM → Render Tree

The browser combines DOM structure with computed style information to build the Render Tree.

The render tree includes only nodes relevant to visual rendering.

Included

Excluded

Important Distinction

visibility: hidden is different from display: none:

Why Render Tree Comes Before Layout

The browser must know what boxes exist before it can calculate where they go and how big they are.

Layout (Reflow)

Once the render tree exists, the browser performs layout.

Layout computes geometry for render tree nodes:

This is where the browser figures out the exact placement of content on the page.

Why Layout Can Be Expensive

Layout work can grow with DOM size and complexity. It may be triggered by:

This kind of read-after-write pattern is a common performance problem.

Paint

After layout, the browser paints visual parts of each box:

Paint is about turning layout results into drawing instructions or pixels.

Important Distinction

Layout answers:

Paint answers:

A change like color may trigger paint without requiring full layout.

A change like width often requires layout first, then paint.

Composite

Modern browsers often split content into layers. During compositing, those layers are combined into the final frame shown on screen.

Properties that often help isolate work to compositing include:

These are often cheaper to animate because they can avoid layout and sometimes avoid repainting large areas.

But Be Careful

Creating too many layers also has memory and management costs. Compositing is powerful, not free.

Applying the Pipeline to the Example

Given:

A simplified timeline looks like this:

1. Browser starts parsing HTML

2. <link rel="stylesheet"> is discovered

3. CSS request begins

4. DOM continues building as HTML is parsed

5. Browser reaches <script src="app.js">

6. HTML parsing pauses while script is fetched/executed unless deferred/async

7. Once relevant DOM and CSSOM information are ready, browser builds the render tree

8. Layout runs

9. Paint runs

10. Layers are composited to the screen

Interview Takeaway

The best mental model is not “everything finishes, then next step starts forever.”

It is:

Misconception 1: CSSOM always finishes before DOM

Not necessarily.

DOM construction often starts first because HTML parsing starts immediately. CSSOM starts when CSS is discovered. They may overlap in time.

Misconception 2: Layout happens before Render Tree

Wrong.

The browser must know which renderable boxes exist before it can compute their geometry.

Misconception 3: Paint and Composite are the same

They are related but different:

Misconception 4: CSS blocks HTML parsing

Usually not directly.

CSS blocks rendering, not raw HTML tokenization itself. However, interaction with scripts can make the overall pipeline feel blocked because scripts may need up-to-date style information.

Misconception 5: The DOM is the same as what gets painted

Also wrong.

The render tree is derived from DOM + style information and excludes non-rendered nodes.

How to Speed Up the Critical Rendering Path

1. Reduce render-blocking CSS

2. Avoid parser-blocking JavaScript

Use defer for scripts that do not need to run immediately:

defer lets HTML parsing continue and runs the script after parsing, before DOMContentLoaded.

3. Reduce layout work

4. Prefer compositor-friendly animations

Animate transform and opacity when possible.

Real Interview Framing

When interviewers ask about rendering performance, they often want you to connect optimizations to pipeline stages:

Q: Why is B correct if DOM and CSSOM can happen in parallel?

Because B is the best conceptual ordering among the choices. DOM construction begins first, CSSOM is built when CSS is discovered, and the render tree depends on both.

Q: What does a normal `<script>` do during parsing?

It pauses HTML parsing at that point, fetches and executes the script, then resumes parsing.

Q: What changes trigger layout?

Examples include:

Q: What is the difference between `display: none` and `visibility: hidden`?

Q: How do you improve First Contentful Paint?