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 than mobile application as in the mobile requires you to download and install the resources and code before you use it. However, in the web is good for increamental (progressive) loading/processing.

So, let's get to dive into these steps (pipeline) and what happen 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 screen.

But, what happen for each step?

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

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

convert the bytes that recived from the web to dom.

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

Understanding these step, they give you the idea where are the bottlenecks and the blocking spots.

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

Each resources, consist in four parts:

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

Once, you see a little red triangle on specific resources, it means that this resources 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 resouece is the html, then the CSS that be used in the hero section, it should be a blocking resources 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 Wikipidia landing page for the first ms in case the css is not blocking.

which is worse experience than blank page. so, we sould 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 brawser will record and listen all events that happening in the network and the main thread.

On top is the network resources (waterfall chart), and in 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 call out functions some of them part of the CRP.

Also, the main thread color coded them look at the simple illustration:

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

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

Now ...

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

JS is the crucial resource that once you know how to load and when to load, it will effect on the page spead load.

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 ... I'll be sharing more content in the coming days.

Thanks for reading ... have a nice day!