Critical rendering path

Slap yourself if

You think the critical rendering path is just 'HTML + CSS + JS loading' or believe async scripts automatically fix it.

Why this exists

Because most frontend performance work fails by optimizing the wrong phase. The page is slow not because of JavaScript, but because rendering was blocked before it even began.

Mental model

The critical rendering path is the minimum sequence of steps the browser must complete before it can paint anything meaningful — and every blocking dependency extends that path.

  • HTML is parsed into the DOM incrementally.
  • CSS is parsed into the CSSOM and blocks rendering.
  • DOM and CSSOM are combined into the render tree.
  • Layout and paint cannot start until required CSS is ready.
  • Shipping non-critical CSS as render-blocking.
  • Assuming async or defer eliminates all blocking.
  • Inlining too much CSS and inflating parse time.
  • Optimizing JavaScript while CSS dominates the path.

The critical rendering path is the sequence of steps required to turn HTML, CSS, and JS into pixels, where render-blocking resources delay first paint.

  • Mentions JavaScript before CSS.
  • Equates load time with render time.
  • Cannot explain why CSS blocks rendering.
  • Says 'just use async scripts'.

Deep dive

Requires Pro

Premium deep dives include more internals, more scars.

The browser’s dependency graph, not a pipeline

Why first paint is delayed longer than expected

Every CRP optimization has a hidden cost

How to reason about CRP issues in real apps

Where CRP explanations fall apart