Critical Render Path

The steps involved before the browser performs the initial render.

The critical render path is the sequence of steps the browser must complete before it can paint the first pixels of your page. It starts with the raw HTML response and ends with a fully rendered frame on screen.

The steps, in order

  1. Parse HTML — the browser reads the HTML response and builds the DOM (Document Object Model) as it goes.
  2. Fetch and parse CSS — CSS is treated as render-blocking by default. The browser must download and parse every stylesheet before it builds the CSSOM (CSS Object Model) and can paint anything.
  3. Build the render tree — the DOM and CSSOM are combined into a render tree, which contains only the nodes that will actually be visible (no display: none, no <head> content).
  4. Layout — the browser calculates the exact size and position of every element in the render tree.
  5. Paint — pixels are drawn to the screen based on the layout.

Any resource that must be downloaded and processed before this sequence can complete — render-blocking CSS, synchronous <script> tags in the <head>, web fonts used above the fold — extends the critical render path and delays your Largest Contentful Paint (LCP).

A shorter critical render path means the browser can paint sooner. Every extra network round-trip, every blocking script, and every unoptimized asset in this path pushes your first paint later.

Why it matters for Core Web Vitals

The critical render path directly determines how quickly your Largest Contentful Paint happens — one of the three Core Web Vitals Google uses to measure page experience. Slow LCP is most commonly caused by:

  • Render-blocking resources — CSS and synchronous JavaScript that must load before the page can paint
  • Slow server response times — every millisecond spent waiting on the server pushes the whole path back
  • Client-side rendering without a fast placeholder — if the largest visible element is an image or component that only appears after JavaScript runs, the browser has nothing to paint until that work finishes

How to shorten it

  • Minimize render-blocking CSS. Inline the small amount of CSS needed for above-the-fold content, and load the rest asynchronously.
  • Defer or async non-critical JavaScript. Scripts that don’t affect the initial render shouldn’t block it.
  • Preload key resources. Use <link rel="preload"> for fonts, hero images, or other assets the browser wouldn’t otherwise discover until late in the path.
  • Render a true-to-size placeholder immediately. For images specifically, this is where Blurhash URLs help — the placeholder’s dimensions and color data are encoded directly in the image URL, so the browser can paint a properly sized preview without waiting on a network round-trip or extra JavaScript.

Further reading