Making Sense of the Critical Rendering Path (CRP)

Hopefully, by the end of this article, the Critical Rendering Path will finally make sense.

Understanding CRP allows you to:

• Identify bottlenecks
• Reduce rendering delays
• Optimize perceived performance

When I began exploring web performance and optimization, I realized that no matter what framework or library you're using, true performance tuning requires going back to the fundamentals.

One of the most essential fundamentals is the Critical Rendering Path (CRP). It describes how a browser processes and renders a web page. Starting from the moment it receives the first byte until it paints pixels on the screen.

What We'll Ignore for Now

Let’s set aside the Time to First Byte (TTFB). It mostly depends on backend performance and network latency, not frontend rendering.

TTFB (Time To First Byte) measures the time it takes for a user's browser to receive the first byte of page content from the server. It is mostly affected by backend performance and network latency, rather than frontend optimizations.

Web works differently from a mobile application, as it requires downloading and installing resources and code before use. However, the web is good for incremental (progressive) loading/processing.

So, let's get to dive into these steps (pipeline) and what happens when the browser receives the first bytes:

The rendering path involves the following steps:

• Constructing the Document Object Model (DOM) from the HTML.
• Constructing the CSS Object Model (CSSOM) from the CSS.
• Applying any JavaScript that alters the DOM or CSSOM.
• Constructing the render tree from the DOM and CSSOM.
• Perform style and layout operations on the page to see what elements fit where.
• Paint the pixels of the elements in memory.
• Composite the pixels if any of them overlap.
• Physically draw all the resulting pixels to the screen.

But what happens for each step?

First, you have these stages for both DOM and CSSOM.

Bytes -> Characters -> Tokens -> Nodes -> DOM.

Convert the bytes received from the web to DOM.

Bytes -> Characters -> Tokens -> Nodes -> CSSOM.

Understanding these steps gives you an idea of where the bottlenecks and the blocking spots are.

But what are the resources that can be critical? Before that, you need to understand the tools in the browser's color code the resources, so you can understand the differences. Here are the color-coded resources:

Each resources consist of four parts:

1. Queuing and connecting.
2. Request sent and waiting.
3. Content downloading.
4. Waiting for the main thread.

Once you see a little red triangle on specific resources, it means that this resource is a blocking resource. Blocking means it will block the rendering, which is the important part to draw the pixels to the user.

The most important resource is the HTML, then the CSS that is used in the hero section, which should be a blocking resource. Because if critical CSS is not loaded in time for initial paint, this can lead to a Flash of Unstyled Content (FOUC).

FOUC (Flash of Unstyled Content)

• This happens because the browser starts rendering the page before CSS is fully applied.

For example, this is Wikipedia's landing page for the first ms in case the CSS is not blocking.

The experience here is worse than a blank page. So, we should be cautious about what to load for the first ms.

How can you see the CRP steps in a real example?

Let's go to www.wikipedia.org.

1. Right click > inspect or F12
2. Performance tab
3. Click on record and reload

Once you do that, the browser will record and listen to all events that are happening in the network and the main thread.

On top is the network resources (waterfall chart), and at the bottom is the main thread (flame chart).

Under each task, the browser engine or rendering engine inside the browser (e.g., V8 in Chrome) executes the callout functions, some of them part of the CRP.

Also, the main thread color codes them. Look at the simple illustration:

• HTML and document -> blue
• Layout related -> purple
• Javascript -> orangish
• Screen paint -> green

Once these are done, the metrics come into the place like First Content Paint (FCP) and other web vitals.

Now ...

• HTML is blocking
• CSS for the hero section should be blocking.
• What about JavaScript?

JS is the crucial resource that, once you know how to load and when to load, will affect the page speed.

Resources:

• https://web.dev/learn/performance/understanding-the-critical-path
• https://medium.com/@Knfrmd/javascript-async-and-defer-47350d314bc1
• https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/script
• https://calendar.perfplanet.com/2024/understanding-the-main-thread-in-the-browser/
• https://browser.engineering/
• https://web.dev/learn/performance/general-html-performance

📌 *If you like it, bookmark this site or follow me @green.dev Thanks for reading ... have a nice day!