What is the critical rendering path?

What is the Critical Rendering Path?

The critical rendering path is the browser work between receiving HTML and painting useful pixels on screen. It is the part of performance that happens after the first byte arrives. A site can have a fast server response and still feel slow if the browser then waits on CSS, JavaScript, fonts, images, or layout work before it can show the page.

For a site team, the critical rendering path is a way to ask a practical question: what must the browser download, parse, calculate, and paint before the visitor sees the first useful view?

How the Browser Builds the Page

The browser starts with the HTML document. As it reads the markup, it builds the Document Object Model, or DOM. The DOM is the browser's working structure for the page: headings, links, images, forms, navigation, product cards, and every other element it has discovered so far.

When the browser finds CSS, it has to download and parse it into the CSS Object Model, or CSSOM. The CSSOM tells the browser which styles apply to which elements. CSS is usually render-blocking because the browser should not paint a page before it knows how that page is meant to look. Painting unstyled content and then replacing it a moment later would be jarring.

JavaScript complicates the sequence. A normal synchronous script can stop HTML parsing while it downloads and runs. That matters when scripts sit high in the <head>, call third-party domains, or depend on large libraries. The browser may be ready to keep reading the HTML, but it is forced to wait while the script executes. defer and async change that loading behaviour, but they need to be used with care because script order and dependencies still matter.

Once the DOM and CSSOM have enough information, the browser creates a render tree for visible content. It then performs layout, where it works out the size and position of each box on the page. Finally, it paints pixels and composites layers so the user can see and interact with the result.

Where Rendering Gets Delayed

The common failure mode is not that one concept is misunderstood. It is that ordinary site choices add too much work before the first useful paint. CMS themes can ship large CSS and JavaScript bundles where only a fraction is used on the current page. A live chat widget can sit in the document head even though it could appear after the main content. A font from a third-party domain can add connection setup and delay text rendering. A large hero image can arrive late, even after the HTML and CSS are ready.

Third-party resources are especially easy to miss because they create their own DNS, TCP, and TLS work. Peakhour's blocking-resources guidance recommends self-hosting critical CSS, JavaScript, and fonts where possible. After browser cache partitioning, a shared third-party CDN no longer gives the old cross-site cache advantage for common libraries. If a critical third-party resource cannot be self-hosted, preconnect may help by opening the connection earlier, but it should be reserved for resources that really affect the first view.

How This Connects to Web Vitals

Metric	What the rendering path often explains
FCP	Whether HTML, CSS, and blocking scripts let any content appear quickly.
LCP	Whether the main content, often a hero image or large text block, can be discovered and delivered early enough.
CLS	Whether images, ads, banners, fonts, or injected content move the layout after painting starts.
INP	Whether JavaScript and layout work leave the main thread free to respond after a click, tap, or key press.

These metrics are connected, but they are not interchangeable. Improving Time to First Byte may give the browser an earlier start. It will not fix unused CSS, blocking JavaScript, missing image dimensions, or a third-party tag that monopolises the main thread. Likewise, deferring a script may improve first paint but break a carousel if the dependency order is wrong. The evidence needs to come from the page being tested.

What to Change First

Start with the resources needed for the first viewport. The main HTML document should arrive quickly enough for the browser to discover critical resources. The CSS needed for visible content should be small and early. Non-critical CSS can be deferred. JavaScript should not block parsing unless the first view genuinely depends on it. Scripts that can wait should be deferred, moved later, split by route, or removed.

Images need two separate checks. File weight affects how long the image takes to download, while missing width and height can hurt layout stability. Responsive AVIF or WebP variants help LCP only when the browser receives an appropriately sized image for the viewport and the rendered slot is stable.

Measure changes with Lighthouse and WebPageTest. Lighthouse is useful for render-blocking opportunities and main-thread diagnostics. WebPageTest shows the waterfall, filmstrip, and when the visual milestones happen. The useful result is not a perfect score; it is a shorter path from HTML to useful pixels, with LCP, CLS, and INP moving in the expected direction.

What is the critical rendering path?