Critical Rendering Path

#browser #rendering #html

There are two important aspects to websites:

Speed
Look

Even for seasoned web developers, increasing a website's page rendering speed is easier said than done. To get there, we must comprehend what is meant by the term "Critical Rendering Path" in order to understand how we may reduce it and increase the speed at which pages are rendered.

What is the Critical Rendering Path?

Engineers refer to the code and resources needed to create the initial view of a web page as the "critical rendering path." We label it as "critical" because doing so results in a "white screen of death" until all the necessary page elements render and are made visible. A webpage's "initial view" is also known as its "above the fold" information. A pretty complex series of interactions could make up the crucial rendering path. We can decide how to organise the parts in the best way if we understand how they affect one another.

Why should I care?

Optimising the critical rendering path allows the browser to paint the page as quickly as possible: faster pages translate into higher engagement, more pages viewed, and improved conversion.
To minimise the amount of time a visitor spends viewing a blank screen, we need to optimise which resources are loaded and in what order.

Main components of the Critical Rendering Path

Network Overhead (Web Server Response Time): Keep in mind that cell networks ALWAYS have a longer "latency" (also known as round trip time) than other types of networks.
HTML code: Without the Document Object Model and completely downloaded HTML, we simply cannot render a web page. Outside Link. opens in a fresh tab. (DOM) tree that the browser is creating. Once those events take place, rendering can begin.
CSS: The DOM must also be created and applied to the CSSOM, the CSS language's own object model. The rendering process is halted by the CSSOM building phase.
Webfonts: These are fonts that must be downloaded in order to use them on a page.
JavaScript: JavaScript is maybe the most disruptive component in the code because it can interact with both HTML and CSS. Browsers halt rendering while JavaScript is downloading and running unless additional measures are done.

IMAGES EVEN THOUGH THEY ARE THE HEAVIEST PART OF THE WEBSITE, REQUIRE NO SPECIAL HANDING AS THEY ARE NOT PART OF THE DOM TREE.

Consider the following:
We are not taking into account the time to fetch resources from

cache or
the network.

Consider the following:

<!DOCTYPE html>
<html>
  <head>
    <meta name="viewport" content="width=device-width,initial-scale=1" />
    <title>Critical Path: No Style</title>
  </head>
  <body>
    <p>Hello <span>web performance</span> students!</p>
    <div><img src="awesome-photo.jpg" /></div>
  </body>
</html>

Check It Out

Without any CSS or JavaScript, we'll start with simple HTML code and a single image. Let's examine the generated resource waterfall by opening the Network timeline in Chrome DevTools:

The process:

The predicted download time for the HTML file was 340 milliseconds.
Note that the solid portion of the blue line indicates how long it takes to complete the download after the first response bytes have been received, while the transparent half of the line shows how long the browser waits on the network before receiving any response bytes.
Since the HTML download is so small (4K), retrieving the entire file only requires one roundtrip.
The HTML content must therefore be fetched, which takes about 340ms, of which half is spent waiting on the network and the other waiting on the server answer.
The browser parses the bytes, transforms them into tokens, and creates the DOM tree as soon as the HTML content is made available.
The DOMContentLoaded event's time is easily reported by DevTools at the bottom (595ms), which also matches to the blue vertical line. The time it takes the browser to assemble the DOM tree—in this case, just a few milliseconds—is shown by the space between the end of the HTML download and the blue vertical line (DOMContentLoaded).
As described earlier, the "awesome photo" does not block the domContentLoad event.

When talking about CRP we only talk about the loading mechanisms of HTML markup, CSS, and Javascript.

Now Adding Javascript and CSS to the Mix

<!DOCTYPE html>
<html>
  <head>
    <title>Critical Path: Measure Script</title>
    <meta name="viewport" content="width=device-width,initial-scale=1" />
    <link href="style.css" rel="stylesheet" />
  </head>
  <body onload="measureCRP()">
    <p>Hello <span>web performance</span> students!</p>
    <div><img src="awesome-photo.jpg" /></div>
    <script src="timing.js"></script>
  </body>
</html>

Check it out

External CSS and JavaScript files increase our waterfall by two requests, which the browser sends out all at around the same time. However, observe that the interval between the domContentLoaded and onload events is now considerably shorter.

Why is that?

In contrast to our example of plain HTML, we also need to fetch and parse the CSS file in order to create the CSSOM, and the DOM and CSSOM are both required in order to create the render tree.
The domContentLoaded event is delayed until the CSS file has downloaded and been parsed because the page also contains a parser-blocking JavaScript file. Because JavaScript may query the CSSOM, we must delay JavaScript execution until the CSS file has downloaded.

Lets discuss what happens if an inline script is used in place of our external script in the next article.