DEV Community

Mitchell
Mitchell

Posted on

The Rendering Machine: Understanding the Critical Rendering Path

#webdev #learning #beginners #frontend

The Rendering Machine: Understanding the Critical Rendering Path

This post delves into the Critical Rendering Path (CRP).

Table of Contents

The Critical Rendering Path (CRP)

What is the Critical Rendering Path?

Short Answer: The sequence of steps the browser takes to convert HTML, CSS, and JavaScript into pixels on the screen, using the minimum necessary resources to display initial content.

Long Answer (Abstraction Levels): The process spans multiple levels of abstraction:

  • Bits
  • Bytes
  • Characters
  • Tokens
  • Nodes
  • DOM / CSSOM
  • Render Tree
  • Layout
  • Paint
  • Composite
  • Web Page (Pixels on Screen)

Longer Answer (The Steps): The rendering path typically involves these steps:

  1. Constructing the Document Object Model (DOM) from the HTML source code.
  2. Constructing the CSS Object Model (CSSOM) from the CSS rules.
  3. Executing JavaScript that might modify the DOM or CSSOM.
  4. Combining the DOM and CSSOM into the Render Tree.
  5. Performing Layout (or "Reflow") to calculate the exact size and position of each object in the render tree.
  6. Painting the pixels for each element onto layers (often in memory).
  7. Compositing the various layers together and displaying them on the screen.

Why is the CRP Critical? / Why Optimize It?

Optimizing the CRP is crucial because it helps to:

  • Improve rendering performance metrics like First Contentful Paint (FCP) and Largest Contentful Paint (LCP), leading to a faster perceived load time.
  • Ensure smooth animations and scrolling (aiming for 60 frames per second).
  • Improve responsiveness to user interactions (reducing input delay).
  • Avoid jank (stuttering or lag during rendering or interaction).

What is the Rendering Strategy?

Progressive Rendering

Browsers employ progressive rendering, meaning they typically start rendering the page as soon as they have enough resources, rather than waiting for everything to download.

Why is it Progressive?

Unlike native software, which is often fully installed before running (loading all necessary resources like images, audio, code upfront), browsers operate differently. The web is inherently distributed; a browser doesn't know all the resources a page needs until it starts parsing the HTML. Downloading everything beforehand isn't feasible. Therefore, browsers render content progressively as resources arrive and are processed.

When is it Too Early or Too Late to Render?

  • Too early: If the browser renders HTML immediately, before essential CSS or JavaScript has been processed, the page might initially look broken or unstyled (a "Flash of Unstyled Content" or FOUC). It might then change significantly as styles and scripts are applied, creating a jarring experience.
  • Too late: If the browser waits for absolutely all resources (including non-critical ones like images far down the page) before rendering anything, users face a blank screen for an extended period, leading to a poor user experience and potentially high bounce rates.

What Can Block Rendering and Hurt Performance?

To understand potential bottlenecks, we must identify the resources involved in the CRP and how they can block progress.

Resources on the Critical Path

The browser prioritizes critical resources, waiting for them before completing the initial render. Non-critical resources are often deferred or loaded asynchronously.

Critical resources typically include:

  • The HTML document itself (at least the initial part).
  • Render-blocking CSS (usually stylesheets linked in the <head> without specific attributes to defer them).
  • Render-blocking JavaScript (usually scripts in the <head> that are not marked async or defer).

Note: The browser processes HTML in a streaming fashion. It starts parsing and potentially requesting linked resources as soon as it receives chunks of the HTML.

Non-critical resources often include:

  • Images (though they can cause layout shifts if space isn't reserved).
  • Fonts (can cause Flash of Invisible Text (FOIT) or Flash of Unstyled Text (FOUT), and layout shifts).
  • JavaScript marked async or defer, or placed just before the closing </body> tag.
  • CSS with a media attribute that doesn't match the current device (e.g., media="print" or media="(max-width: 480px)" on a desktop).

Note: Late-loading resources like fonts and images can cause content to shift after initially rendering. The Cumulative Layout Shift (CLS) metric measures this visual instability.

Types of Blocking Resources

Short Answer:

There are two main types:

  • Render-blocking resources: Critical resources (like CSS by default) that pause the browser's rendering process (specifically, render tree construction and painting) until they are downloaded and processed.
  • Parser-blocking resources: Resources (like synchronous JavaScript by default) that stop the browser's HTML parser from continuing to process the rest of the document.

Parser-blocking resources are inherently also render-blocking, since content must be parsed before it can be rendered. Blocking the parser is often more detrimental to performance than blocking rendering alone.

Long Answer:

  • Render-blocking resources (e.g., standard CSS linked in <head>) block the construction of the render tree and subsequent painting. However, the HTML parser might continue processing the document while the CSS is being downloaded and parsed (using the preload scanner). CSS linked in the <head> typically blocks rendering of the entire page until the CSSOM is constructed.

CSS is render-blocking by default. It can be made non-blocking for specific conditions using the media attribute (e.g., <link rel="stylesheet" href="..." media="print">). Developers can also explicitly mark resources using blocking="render".

  • Parser-blocking resources (e.g., synchronous JavaScript) halt the main HTML parser. This prevents the browser from discovering other resources further down the HTML until the script is downloaded, parsed, and executed. Consequently, rendering is also blocked. > Synchronous JavaScript is parser-blocking by default. Use the async or defer attributes on <script> tags to make it non-blocking.

The browser often employs a secondary HTML parser, the preload scanner, which scans ahead while the main parser is blocked (e.g., by a script). This allows the browser to discover resources like images, CSS, and other scripts further down the page and start downloading them speculatively, potentially saving time.

Identifying Blocking Resources

Tools like WebPageTest, Lighthouse (in Chrome DevTools), and the Performance tab in browser developer tools can help identify render-blocking resources in the network waterfall chart.

Is Resource Blocking Necessary?

Yes, to some extent.

If the browser rendered HTML without waiting for essential CSS for styling or critical JavaScript that might alter structure or content, it would likely display a broken or unstyled page (FOUC). This leads to a poor user experience as the page reflows and restyles significantly once those critical resources load. The blocking mechanism ensures a more stable initial render, albeit at the cost of waiting for those resources.

General Tips for Optimizing the CRP

  • Minimize Critical Resources: Reduce the number of resources marked as critical. Defer the download of non-essential resources, mark scripts with async or defer, inline critical CSS for above-the-fold content, or eliminate unused resources entirely.
  • Optimize Resource Size and Request Count: Reduce the total number of network requests for critical resources (e.g., via bundling) and minimize the file size of each resource (e.g., through minification, compression, removing unused code, using efficient formats).
  • Optimize Loading Order: Prioritize the loading of critical assets needed for the initial viewport (above-the-fold content). Ensure they are discovered, downloaded, and processed as early as possible to shorten the CRP length (e.g., using <link rel="preload">).

Key Components of the CRP

DOM (Document Object Model)

What:

  • A tree-like data structure representing the hierarchy of HTML elements/tags in a document.
  • It's built incrementally as the browser parses the HTML: Bytes -> Characters -> Tokens -> Nodes -> DOM Tree.

Performance Implications:

  • Deeply nested HTML or an excessive number of elements can slow down DOM construction. A large DOM tree also makes subsequent steps like style calculation and layout more computationally expensive, potentially contributing to jank or sluggishness.

CSSOM (CSS Object Model)

What:

  • Similar to the DOM, it's a tree-like data structure, but it represents the styles associated with the DOM elements. It includes styles from browser defaults, user-defined stylesheets, and inline styles.
  • Unlike the DOM, the final CSSOM is often considered non-incremental in its application. Because CSS rules can override each other based on specificity and order (the "Cascade"), the browser typically needs to process all applicable CSS rules to determine the final computed style for each node before proceeding to layout.
  • This requirement is why CSS is considered render-blocking by default.

CSS Selectors

Browsers typically match CSS selectors efficiently, often starting from the rightmost component (the "key selector") and working leftwards, checking against the DOM tree. While selector complexity can impact performance:

  • The performance difference between simple and complex selectors is usually minimal (microseconds). Optimizing selectors rarely yields significant gains.
  • Highly specific selectors might require slightly more DOM traversal.
  • Measure first, optimize only if profiling shows a bottleneck. Focus on broader CSS optimizations like reducing file size and removing unused rules.
  • See MDN's CSS Performance Optimization Guide for more details.

Render Tree

What: A tree-like structure formed by combining the DOM and CSSOM. It represents only the elements that will be visually rendered on the page.

When: Constructed after both the DOM and CSSOM are available.

How: The browser traverses the DOM tree. For each visible node, it finds the matching CSSOM rules and calculates the computed styles.

Note:

  • The Render Tree excludes non-visual elements, such as tags within <head>, elements hidden with display: none, and their descendants. (Elements hidden with visibility: hidden are included as they still take up space).

Layout (Reflow)

What: The process of calculating the exact size and position of each element in the render tree within the viewport.

When: Occurs after the Render Tree is constructed. It also happens whenever the geometry of elements might change.

Determining Size and Position:

  • The viewport size is crucial. Without specific meta tags, mobile browsers often use a default layout viewport width (e.g., 960px). Using <meta name="viewport" content="width=device-width"> sets the layout viewport width to the device's screen width.
  • Layout (or Reflow) recalculates element positions and dimensions. This is triggered by: changes to the viewport size (resizing the browser window, changing device orientation), changes to the DOM (adding/removing elements), changes to CSS properties affecting geometry (width, height, margin, padding, font-size, position), or requesting certain geometric properties in JavaScript (offsetTop, clientWidth).

Impacting Factors:

  • The number of nodes in the render tree: More nodes mean more calculations.
  • Complexity of styles affecting layout.
  • Frequent triggers (e.g., animating layout properties like width or top in JavaScript).

Performance: Layout can be a significant performance bottleneck, especially with large DOMs or frequent updates. Forcing layout repeatedly in JavaScript ("Layout Thrashing") can cause severe jank, particularly during scrolling or animations.

Optimization Strategy: Minimize and batch layout operations.

  • Avoid querying layout-triggering properties repeatedly in loops. Read values first, then write changes.
  • Use CSS transform and opacity for animations whenever possible, as they often don't trigger layout and can be handled more efficiently by the compositor.

Paint (Repaint)

What: The process of filling in the actual pixels for each element based on the calculated layout and styles (color, background, borders, text, shadows, etc.). Painting occurs onto layers.

When: After Layout. It also happens when visual styles change without affecting layout (e.g., changing background-color, color, box-shadow).

Stages:

  • Initial paint: The entire visible screen area is painted.
  • Repaint: Subsequent updates ideally only repaint the specific areas (layers) that changed.

Impacting Factors:

  • Complexity of visual styles (e.g., complex gradients, shadows).
  • The size of the area that needs to be repainted.

Performance: While painting takes time, it's often less likely to be the primary bottleneck compared to frequent or complex Layout operations. However, very complex paint operations (like intricate shadows or gradients on large areas) can still impact performance, especially on low-powered devices.

Optimization Strategy: Simplify paint complexity and reduce painted areas where possible.

  • Promote elements that animate frequently to their own compositor layer using will-change or transform: translateZ(0) (use judiciously).
  • Simplify complex styles if profiling indicates a paint bottleneck.
  • Measure first using browser developer tools (Performance tab) to identify paint costs before optimizing.

Alternative Perspectives: The Key Path

As user-centric performance metrics like LCP (Largest Contentful Paint) and FCP (First Contentful Paint) have emerged, an alternative view sometimes discussed is the Key Path (or Contentful Rendering Path).

This perspective emphasizes that even resources not strictly render-blocking according to the CRP definition (like the main image needed for LCP) should be prioritized if they are essential for rendering meaningful content quickly. Optimizing the Key Path involves ensuring these crucial content elements are loaded and rendered promptly.

Tools for Analysis

Tools for measuring webpage performance and diagnosing CRP issues:

  • WebPageTest.org
  • Lighthouse (available in Chrome DevTools and as a standalone tool/API)
  • Chrome DevTools (Performance tab, Network tab)
  • Firefox Developer Tools (Performance tab, Network tab)

Related Questions

  • What happens step-by-step when a user navigates to a URL? (Covers DNS, TCP, HTTP, and CRP)
  • What is the Critical Rendering Path?
  • How does the browser parse CSS selectors (e.g., .bar .foo {})?
  • What is jank and what causes it?
  • How can CSS loading and parsing performance be optimized?
  • What are reflow (layout) and repaint? What triggers them?
  • What is the difference between <script>, <script async>, and <script defer>?
  • What tools are available to measure web performance?
  • What are common web performance metrics (e.g., FCP, LCP, TTI, CLS, FID/INP)?
  • ...

References

Top comments (0)