Open In App

Critical Rendering Path Flow

Last Updated : 07 Jun, 2022
Improve
Improve
Like Article
Like
Save
Share
Report

Have you ever wondered what occurs behind the scenes when webpage loads or how your browser processes these pages? Then you’ve come to the right place to discover more about it. The flow that a browser follows to transform a file into a webpage is known as the Critical Rending Path.

The below diagram shows the flow of the Critical Rendering Path(CRP).

Critical Rendering Path Flow fig 1.1

Example: Now let’s consider an example of a simple webpage to understand this flow, here we have an HTML document with style content. 

index.html




<html lang="en">
<head>
  <link rel="stylesheet" href="style.css">
</head>
<body>
    <p>Critical Rendering Path</p>
  
    <label>Hello World</label>
</body>
</html>


 

style.css




p {
    text-align: center;
    padding: 5%;
    font-size: 2vw;
    border: 2px solid #000;
    color: #308D46;
    font-weight: bold;
}
label {
    display: none;
}


Now let’s go through each block of CRP, for the above example, and understand the concept thoroughly.

1. Network: When a user visits a webpage, a DNS lookup is performed to determine the IP address of the server hosting the webpage files. After obtaining the IP, a request to retrieve those files is sent to the server. These files are split into several packets and then transferred across the network, rather than being delivered all at once. In our example, index.html & style.css are sent in form of packets.

2.Document Object Model (DOM): DOM is a crucial part of any webpage. HTML is the first file that will be sent from the server when a webpage is loaded. Once the browser starts getting these packets(which contain bytes of code), it will start the parsing instead of waiting for all packets to be received. The browser follows an incremental DOM update approach. In parsing, first, it converts bytes to characters & then into tokens & then into nodes & then finally into the DOM tree. This cycle repeats whenever a new packet is received. fig1.2 shows the conversion of bytes into the DOM tree.

In the example above, index.html will be divided into multiple packets & sent. After receiving these packets, the browser follows the same cycle as above. fig 1.3 depicts the DOM tree of index.html. 

Bytes to DOM conversion flow fig 1.2

DOM Tree fig 1.3

3. Cascading Style Sheet Object Model (CSSOM): This object model focuses on the style part of a webpage. CSSOM tree construction is render-blocking, unlike DOM tree construction. Here browser will be waiting for all the packets to be received & starts parsing once all the packets of the file are received because the style properties can be replaced or overwritten in upcoming lines. The browser follows the same approach of converting Bytes to CSSOM tree. fig 1.4 shows the conversion of bytes into the CSSOM tree.

In the example above, after receiving all the packets of style.css, the browser will process these packets into the CSSOM tree. fig 1.5 depicts the CSSOM tree of style.css. 

Bytes to CSSOM Conversion Flow fig 1.4

CSSOM fig 1.5

4. Render Tree: Render tree combines both the DOM & CSSOM tree into one. It takes each node from the DOM tree & maps the respective CSS object to it. Each node in the render tree has style properties assigned to it if there is any style content defined for a particular node. One thing to notice in the render tree construction is, it only catches the visible content & adds it to the tree. Since the head segment doesn’t have any visibility to it, it won’t be there in the render tree.

For our example, the head segment won’t be added for the same reason as mentioned above & also, since the label tag is having the property of display: none hence this too won’t be added. fig 1.6 displays the render tree.

Render Tree fig 1.6

5.Layout(Visual Formatting Model):After building the render tree, the layout comes into the picture. The layout concentrates on the placement of elements on the screen based on the size of the screen. The element having a height and width of 100% captures the whole screen. The execution of the layout depends on the nodes of the DOM tree. The more the number, the more time browser takes to build the layout. It works on the algorithm which calculates and uses a bunch of stuff like the box model, floats, and positioning. In order to actually render the page, the browser uses something called Visual Formatting Model .

In our example, the ‘p’ is block-level element hence it covers 100% width. fig 1.7 shows the layout.

Layout fig 1.7

6. Paint: This is the final step, after having render-tree & layout, the browser paints the pixels on the screen. fig 1.8 shows the webpage after the painting is completed. Here we can see, since ‘Hello World’ label had a display property of none, this label is not visible.

Page after Paint fig 1.8



Like Article
Suggest improvement
Share your thoughts in the comments

Similar Reads