Critical Rendering Path
Definition
The Critical Rendering Path is the sequence of steps the browser goes through to convert the HTML, CSS, and JavaScript into pixels on the screen. Optimizing the critical render path improves render performance. The critical rendering path includes the Document Object Model (DOM), CSS Object Model (CSSOM), render tree and layout.

Steps of CRP:
The browser starts off by constructing the DOM by parsing all the relevant HTML.
It then proceeds to look at the CSS and JavaScript resources and requests them, which is happening usually in the head where we commonly put our external links.
The browser then parses the CSS and constructs the CSSOM followed by running the JavaScript.
Then the DOM and CSSOM are being merged together into the Render Tree.
We then run the Layout step.
Then run the Painting step to present the page to the user.
Compose the layers on the screen
Document Object Model (DOM)
DOM construction is incremental. The HTML response turns into tokens which turn into nodes which turn into the DOM Tree. A single DOM node starts with a start tag token and ends with an end tag token. Nodes contain all relevant information about the HTML element. The information is described using tokens. Nodes are connected into a DOM tree based on token hierarchy. If another set of start tag and end tag tokens come between a set of a start tag and end tags, you have a node inside a node, which is how we define the hierarchy of the DOM tree. The greater the number of nodes, the longer the following events in the critical rendering path will take.
CSS Object Model (CSSOM)
The DOM contains all the content of the page. The CSSOM contains all the styles of the page; information on how to style that DOM. CSSOM is similar to the DOM, but different. While the DOM construction is incremental, CSSOM is not. CSS is render-blocking: the browser blocks page rendering until it receives and processes all of the CSS. CSS is render-blocking because rules can be overwritten, so the content can't be rendered until the CSSOM is complete.
In terms of selector performance, less specific selectors are faster than more specific ones. The more specific tag requires more work from the browser, but this penalty is not likely worth optimizing. When it comes to CSS, selector performance optimization, improvements will only be in microseconds. There are other ways to optimize CSS, such as minification, and separating deferred CSS into non-blocking requests by using media queries.
Render Tree
The render tree captures both the content and the styles: the DOM and CSSOM trees are combined into the render tree. 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.
The render tree only captures visible content. The head section (generally) doesn't contain any visible information and is therefore not included in the render tree. If there's a display: none; set on an element, neither it nor any of its descendants, are in the render tree.
Layout
The layout is dependent on the size of the screen. The layout step determines where and how the elements are positioned on the page, determining the width and height of each element, and where they are in relation to each other.
The viewport meta tag defines the width of the layout viewport, impacting the layout. Without it, the browser uses the default viewport width, which on by-default full-screen browsers is generally 960px.
Layout performance is impacted by the DOM -- the greater the number of nodes, the longer layout takes. Layout can become a bottleneck, leading to jank if required during scrolling or other animations. While a 20ms delay on load or orientation change may be fine, it will lead to jank on animation or scroll. Any time the render tree is modified, such as by added nodes, altered content, or updated box model styles on a node, layout occurs.
To reduce the frequency and duration of layout events, batch updates and avoid animating box model properties.
Paint
The last step is painting the pixels to the screen. Once the render tree is created and the layout occurs, the pixels can be painted to the screen. Onload, the entire screen is painted. After that, only impacted areas of the screen will be repainted, as browsers are optimized to repaint the minimum area required. Paint time depends on what kind of updates are being applied to the render tree. While the painting is a very fast process, and therefore likely not the most impactful place to focus on in improving performance, it is important to remember to allow for both layout and re-paint times when measuring how long an animation frame may take. The styles applied to each node increase the paint time, but removing the style that increases the paint by 0.001ms may not give you the biggest bang for your optimization buck.
Compositing
Since the parts of the page were drawn into potentially multiple layers they need to be drawn to the screen in the correct order so that the page renders correctly. This is especially important for elements that overlap another, since a mistake could result in one element appearing over the top of another incorrectly.
Patterns to reduce CRP:
Minimize the number of bytes you send (Minifying, Compressing, and Caching)
Reduce the number of critical resources in the critical rendering path (analytics might not have to be loaded at the very start when the page is built, inlining some critical CSS and JS)
Shorten the critical rendering path length (meaning reducing the amount of roundtrips between your browser and the server that we need to render the page, defer the execution of our JavaScript and use async attributes for the script)
Last updated
Was this helpful?