What is the Critical Rendering Path?

What is the critical rendering path?

The critical rendering path (CRP) is the sequence of steps a browser takes to turn HTML, CSS and JavaScript into pixels on screen: build the DOM, build the CSSOM, combine them into a render tree, work out the layout, then paint. Everything the browser must download and process before that first paint sits on the path, so shortening it is how you get content in front of visitors sooner.

How the browser walks the path

• DOM. The browser parses the HTML into tokens, then nodes, then the Document Object Model. This is incremental, so it can start before the whole file has arrived. MDN notes that the more nodes there are, the longer the later steps take.
• CSSOM. The CSS is parsed into the CSS Object Model. Unlike the DOM, this is not incremental, because later rules may override earlier ones.
• Render tree. The DOM and CSSOM are combined. The tree holds only visible content: elements with display: none and their descendants are left out, and so is the head.
• Layout. The browser works out the size and position of every element. It depends on the viewport width, so it runs again whenever the window is resized or the device is rotated.
• Paint. The browser draws the pixels. The whole screen is painted on load; afterwards only the areas that changed are repainted.

The metrics in a speed report sit on this path. First Contentful Paint is the first time any content is painted, so every millisecond the path spends waiting adds directly to it.

What blocks the path

CSS is render-blocking. MDN explains that the browser holds back rendering until it has received and processed all the CSS, because rules can be overwritten and the content cannot be drawn before the CSSOM is complete.

Classic scripts block parsing. A script without async, defer or type="module" is fetched and executed immediately, before the browser carries on parsing the page (MDN). Lighthouse flags a script in the head without defer or async, and a stylesheet link whose media matches the device, as render-blocking. The two attributes behave differently: defer runs the script after parsing, in document order, before DOMContentLoaded; async runs it as soon as it has downloaded, with no order guaranteed. See asynchronous loading for when to pick which.

Example

A marketing page ships one large stylesheet for the whole site, a tag-manager script in the head and a slider library. The first paint waits for the stylesheet and for the script to be fetched and run, even though the visitor only needs the headline and the hero image. The fix has three parts: inline the small set of above-the-fold rules in a <style> block, add defer to scripts the first view does not need, and use a resource hint so the hero image is requested early.

<style>/* only the rules the first screen needs */</style>
<link rel="preload" href="/hero.webp" as="image" fetchpriority="high">
<script src="/app.js" defer></script>

How to shorten the path

• Fewer critical resources. Remove anything the first screen does not need. The Coverage tab in Chrome DevTools shows unused CSS and JavaScript.
• Smaller critical resources. Minify and compress CSS and JavaScript, and keep the DOM from growing needlessly.
• Inline critical CSS and load the rest without blocking. Splitting stylesheets by media attribute means the browser blocks only on those that match the device.
• Defer or async the scripts that are not needed for the first paint.
• Better order. Make late-discovered files, such as a CSS background image or a font, start early with a hint.

Common mistakes

• Inlining all the CSS. That makes every page heavier and removes caching for the stylesheet; inline only what the first screen needs.
• Putting async on scripts that depend on each other. Order is not guaranteed, so use defer there.
• Deferring a script that builds visible content, which can leave a blank area or make the layout jump later.
• Tuning CSS selectors for speed. MDN points out the gain is only microseconds, so spend the time on blocking files instead.
• Checking only on a fast desktop connection. A slow phone makes every blocking request cost more.

How it relates to testing and monitoring

Lab audits list the render-blocking requests on a page, and the waterfall shows what the first paint waited for. To track this over time, LoadFocus page speed monitoring runs Google Lighthouse audits on a schedule, from hourly to weekly, from 25 cloud regions, with alerts to email, Slack or Microsoft Teams. The free Core Web Vitals checker shows real-user LCP, INP and CLS from Google's CrUX data, so you can see whether a fix reached actual visitors. More frontend fixes are in the 10-step guide to improving website speed. For the exact definitions, read the MDN guide to the critical rendering path.

FAQ: critical rendering path

What are the steps of the critical rendering path?

Build the DOM from the HTML, build the CSSOM from the CSS, combine them into a render tree of visible content, calculate the layout, and paint the pixels.

Is JavaScript render-blocking?

A classic script without async, defer or type module blocks HTML parsing while it is fetched and run, and Lighthouse reports one in the head as render-blocking. Adding defer or async removes that block.

Why is CSS render-blocking?

Later CSS rules can override earlier ones, so the browser waits until the CSSOM is complete before it draws anything.

What is critical CSS?

It is the small set of rules needed to draw the first screen. It is placed inline in the head, and the remaining CSS is loaded without blocking the first paint.

How do I measure the critical rendering path?

Run a Lighthouse audit to see the render-blocking requests, and read a network waterfall to see what the first paint waited for. Repeat from several regions and on a throttled connection.