CRITICAL RENDERING PATH
Tags: webperf, javascript, html, css
Published: 2020-05-28 16:03:38

### What Is The Critical Rendering Path?

The Critical Rendering Path is the sequence of steps the web browser goes through to convert the HTML, CSS, and JavaScript files into pixels to render on the screen. The critical rendering path is made up of the Document Object Model (DOM), CSS Object Model (CSSOM), Render Tree, Layout and Paint. And, optimising the critical rendering path helps to improves render performance. 

### How Does It Work?

- The Document Object Model (DOM) is created as the HTML is parsed. 
- The HTML may request JavaScript, which may, in turn, alter the DOM. 
- The HTML includes or makes requests for styles, which in turn builds the CSS Object Model (CSSOM). 
- The browser engine combines the two to create the Render Tree. 
- Layout determines the size and location of everything on the page. 
- Once layout is determined, pixels are painted to the screen.

![How CRP Works](https://dev-to-uploads.s3.amazonaws.com/i/r4fdx3wmz4ywozhn4337.png)
How Critical Rendering Path Works

#### Document Object Model (DOM)

**A Web page is a document.** This document can either be displayed in the browser window or as the HTML source.

The DOM is an object-oriented representation of the web page, which can be modified with a scripting language such as JavaScript.

The DOM represents the document as nodes and objects. That way, programming languages can connect to the page. How are these nodes generated? Let's look into that next.

##### Construction Of The DOM

The browser requests the HTML Document from the server or local file system which is read as a sequence of **bytes** and converts them into recognisable **characters**. These characters go through a process of **tokenisation** in the browser to produce **tokens** (startTag tokens and endTag tokens) which are the final input to generate the DOM Nodes. A lexical analyser of some sort in the browser is responsible for converting said tokens into **nodes**. A node starts with a startTag token and ends with an endTag token and contains all relevant information about the HTML element described by the tokens.

The final DOM Tree is constructed(incrementally) by connecting the nodes based on token hierarchy.

![DOM Construction](https://dev-to-uploads.s3.amazonaws.com/i/qhujifkilhsjhaytw7n4.png)
DOM Construction Process

#### CSS Object Model (CSSOM)

The CSS Object Model (CSSOM) is a map of all CSS selectors and relevant properties for each selector in the form of a tree, with a root node, sibling, descendant, child, and other relationships and is similar to the DOM. But it is also different.

While the DOM is constructed incrementally, the CSSOM is not and is **render-blocking** because CSS rules can be overwritten, so the content can't be rendered until the CSSOM is complete.

Due to the **Cascading** nature of CSS, the CSSOM can not be constructed incrementally because subsequent rules may be overwritten and as a result, the CSS Object Model gets built as the CSS is parsed, but can not be used to build the render tree until it is completely parsed by the web browser.

#### Render Tree

The Render Tree is the combination of both the DOM and CSSOM trees. To construct the render tree, the browser checks every node, starting from the root of the DOM tree and determines which CSS rules are attached to each DOM Node. Through this process, the render tree only contains nodes and styles required by the page (visible content).

The `<header>` is in most cases not included in the render tree as it does not usually contain any visible content. Also, any HTMLElement with it's `display` set to `none`, is not included in the render tree as well as all it's children elements.

#### Layout/Reflow Stage 

Once the render tree is built, laying out a web page becomes possible and the process is dependent on the size of the screen. This stage calculates the exact position and size(height & width) of DOM Nodes in the viewport.

__To find out about how some of the CSS units affect how a web page is laid out, read this [post](https://dev.to/ibn_abubakre/em-vs-rem-5b33) by [Abdulqudus Abubakre ](https://dev.to/ibn_abubakre).__

The viewport meta tag defines the width of the layout viewport, which impacts the layout. Without it, the browser uses the default viewport width to lay out the web page, which is generally 960px for full-screen browsers. By setting `<meta name="viewport" content="width=device-width">`, the width will be the width of the device instead of the default viewport width of the browser (such as your phone browser). The `device-width` changes when a user rotates their phone between landscape and portrait mode. Layout happens every time a device is rotated or browser is otherwise resized.

Performance of the layout stage is affected by the DOM as the more the number of nodes in the DOM tree, the longer it takes to layout a web page.

It is also known as the **Reflow Stage** because layout is also done when the browser re-calculates the positions and dimensions of elements in the document, for the purpose of re-rendering part or all of the document. This process of re-calculation and re-rendering by the browser is known as **'Browser Reflow'** and is a **user-blocking** operation i.e it prevents the user from interacting with the web page while the browser is re-calculating and re-rendering the document. Hence, minimising the number of browser reflows needed by a web page improves performance also.

#### Paint

The last step to rendering a web page is to paint the pixels onto the viewport according to the box model (yeah, the nifty diagram in our DevTools). After painting, only impacted areas of the screen will be repainted, as browsers are optimised to repaint the minimum area required. But paint times differ from scenario to scenario so, it is advised to account for it (and layout time) when improving performance on the web (and deciding how long those animations should take 😏).

![CSS Box Model](https://dev-to-uploads.s3.amazonaws.com/i/7oq9ef17nxquccjrpoqd.png)
Box Model In Chrome DevTools

### **Optimising the Critical Rendering Path (CRP)**

We can improve rendering performance and in extension page load by prioritising which resources get loaded, controlling the order in which they are loaded, and reducing the file sizes of those resources. Performance tips include:
- Minimising the number of critical resources by deferring their download, marking them as async, or eliminating them altogether ([know more](https://dev.to/codesensei/render-blocking-resources-510i)),
- Optimising the number of requests required along with the file size of each request ([know more](https://dev.to/codesensei/minifying-text-based-resources-30dn)), and 
- Optimising the order in which critical resources are loaded by prioritising the downloading critical assets, shorten the critical path length.

### A Recap Of CRP,

- There is a request from a client/user,

- The web browser Parses HTML document and builds the DOM Tree,

- It checks for and Parses CSS documents and builds the CSSOM Tree,

- It Combines DOM and CSSOM Tress into a Render Tree,

- Builds a Layout from the Render Tree by computing the position and size of each node,

- Paint nodes on the screen based on box model.

### Summary

In summary, the browser goes through some processes to display a website page, to make this process efficient, it is important to go through the points mentioned above which will have a positive impact on user experience and maximise web performance. 

Until next time, keep building great web applications. 🙋

### Sources  
- [Critical Rendering Path](https://developer.mozilla.org/en-US/docs/Web/Performance/Critical_rendering_path)
- [Introduction To The DOM](https://developer.mozilla.org/en-US/docs/Web/API/Document_Object_Model/Introduction)
- [CSS Object Model (CSSOM)](https://developer.mozilla.org/en-US/docs/Glossary/CSSOM)
- [Minimising Browser Reflow](https://developers.google.com/speed/docs/insights/browser-reflowhttps://developers.google.com/speed/docs/insights/browser-reflow)
- [Optimising The Critical Rendering Path](https://developers.google.com/web/fundamentals/performance/critical-rendering-path/optimizing-critical-rendering-path)