Skip to content

Critical-Rendering-Path.md

Latest commit

 

History

History
174 lines (135 loc) · 14.4 KB

Critical-Rendering-Path.md

File metadata and controls

174 lines (135 loc) · 14.4 KB

Critical Rendering Path

The Critical Rendering Path (CRP) refers to the sequence of steps the browser goes through to convert HTML, CSS, and JavaScript into pixels on the screen. Optimizing the CRP is crucial for improving perceived page load speed and user experience. Understanding and optimizing this path means ensuring that the browser can render the initial view of a page as quickly as possible.

Think of it like building a house. The browser rendering a page is like a construction crew building a house from blueprints. First, they read the architectural plans (parse HTML to build the DOM). Then they check the interior design specs (parse CSS to build the CSSOM). Next, they combine both to figure out what goes where (the Render Tree). Then they measure and mark the lot (Layout). Finally, they paint the walls and install everything (Paint). Anything that blocks the blueprints or design specs — like waiting for a special material to arrive — delays the entire build.

Core Concepts

The browser's rendering process involves several key stages:

  1. Document Object Model (DOM) Construction:

    • The browser parses the HTML markup and builds the DOM tree. The HTML is processed byte by byte, converting tokens into nodes, and ultimately forming a tree-like structure representing the document's content and hierarchy.
    • This process can be interrupted by <script> tags that are not async or defer.

  2. CSS Object Model (CSSOM) Construction:

    • Similarly, the browser parses the CSS (from external stylesheets, embedded styles, and inline styles) and builds the CSSOM tree. The CSSOM represents how styles are applied to DOM elements.
    • CSS is render-blocking by default. The browser needs the complete CSSOM to proceed with rendering, as styles can affect the layout and appearance of elements.

  3. JavaScript Execution:

    • While HTML parsing is ongoing, if the parser encounters a <script> tag (that is not async or defer), parsing is paused, and the script is fetched and executed.
    • JavaScript can query and modify both the DOM and CSSOM. This is a powerful feature but can also be a source of performance bottlenecks if not managed carefully. For example, a script might force a synchronous layout if it reads a geometric property after modifying the DOM.
    • The browser builds an Abstract Syntax Tree (AST) from the JavaScript code, which is then often compiled into bytecode and executed by the JavaScript engine.

  4. Render Tree Construction:

    • The browser combines the DOM and CSSOM trees to create the Render Tree. The Render Tree contains only the nodes required to render the page.
    • Elements that are not visually displayed (e.g., elements with display: none;, <head>, script tags) are not included in the Render Tree.

  5. Layout (Reflow):

    • Once the Render Tree is constructed, the browser calculates the geometric information (size and position) for each visible node in the tree. This stage is called Layout or Reflow.
    • The layout process determines the exact coordinates and dimensions of each element on the page. Any change that affects an element's geometry (e.g., changing width, height, position, or even content that changes its size) will trigger a reflow.

  6. Paint (Rasterization):

    • After the layout is determined, the browser "paints" or "rasters" the pixels for each node onto the screen. This involves filling in pixels based on the visual properties (colors, borders, shadows, etc.) defined in the CSSOM.
    • Painting can happen on multiple layers.

  7. Compositing:

    • If the page content is separated into different layers (e.g., due to CSS properties like transform, opacity, will-change), the browser needs to composite these layers together in the correct order to display the final image on the screen.
    • Moving elements between layers or animating properties that can be handled by the compositor (like transform and opacity) is generally more performant as it doesn't necessarily trigger layout or paint for the entire page.

Optimizing the Critical Rendering Path

Optimizing the CRP involves minimizing the time spent in each of these stages.

1. Minimize Render-Blocking Resources:

  • HTML:
    • Keep HTML simple and well-structured.
    • Avoid deeply nested elements where possible.
  • CSS:
    • Minify CSS: Remove unnecessary characters (whitespace, comments) from CSS files.
    • Reduce CSS File Count: Combine multiple CSS files into fewer files to reduce HTTP requests.
    • Inline Critical CSS: Identify the CSS rules necessary for rendering the above-the-fold content (the part of the page visible without scrolling) and inline them directly in the <head> of the HTML document. This allows the browser to start rendering the initial view without waiting for external CSS files to download.
    • Load Non-Critical CSS Asynchronously: Use techniques like media="print" onload this.media='all' or JavaScript-based loaders for CSS that is not needed for the initial render. 
      <link rel="stylesheet" href="styles.css" media="print" onload="this.media='all'">
<noscript><link rel="stylesheet" href="styles.css"></noscript>
  • JavaScript:
    • Use async and defer attributes for <script> tags:
      • async: Downloads the script asynchronously without blocking HTML parsing and executes it as soon as it's downloaded (can interrupt parsing if it finishes downloading before parsing is complete). Order of execution is not guaranteed.
      • defer: Downloads the script asynchronously without blocking HTML parsing and executes it only after the HTML parsing is complete, but before the DOMContentLoaded event. Scripts with defer are executed in the order they appear in the document.
      <script async src="analytics.js"></script>
<script defer src="main-functionality.js"></script>
    • Minimize JavaScript: Remove unused code and minify JavaScript files.
    • Avoid Long-Running JavaScript: Break down long tasks into smaller chunks using techniques like requestIdleCallback or setTimeout to prevent blocking the main thread.

2. Optimize DOM and CSSOM Construction:

  • Reduce DOM Size: A smaller DOM tree is faster to process. Remove unnecessary elements.
  • Efficient CSS Selectors: While modern browsers are highly optimized, overly complex CSS selectors can still take longer to match. Prefer class-based selectors over deeply nested or tag-qualifier selectors where performance is critical.

3. Optimize Render Tree, Layout, and Paint:

  • Avoid Forced Synchronous Layouts (Layout Thrashing):
    • Reading a layout-dependent property (e.g., offsetHeight, offsetTop) immediately after making a DOM change that invalidates layout (e.g., changing element.style.width) forces the browser to perform a synchronous layout.
    • Batch DOM reads and writes to avoid this. Read all necessary layout properties first, then perform all DOM writes.
    • Example of Layout Thrashing (Bad): 
      function resizeElements(elements) {
  elements.forEach(element => {
    // Write: Changes style, invalidates layout
    element.style.width = (element.offsetWidth / 2) + 'px'; // Read: offsetWidth forces layout
    // This read-write cycle in a loop causes layout thrashing
  });
}
    • Example of Avoiding Layout Thrashing (Good): 
      function resizeElementsOptimized(elements) {
  const widths = [];
  // Read all widths first
  elements.forEach(element => {
    widths.push(element.offsetWidth);
  });

  // Then write all changes
  elements.forEach((element, index) => {
    element.style.width = (widths[index] / 2) + 'px';
  });
}
  • Promote Elements to Layers (Carefully):
    • Use CSS properties like transform: translateZ(0); or will-change to promote elements to their own compositor layer. This can improve paint and compositing performance for animations and transitions, as changes to these layers often don't require repainting or re-laying out the rest of the page.
    • However, creating too many layers can consume excessive memory and even degrade performance, so use this technique judiciously.
  • Debounce and Throttle Expensive Event Handlers: For events that fire frequently (e.g., scroll, resize, mousemove), use debouncing or throttling to limit the rate at which event handlers are executed, preventing excessive layout and paint operations.

4. Prioritize Above-the-Fold Content:

  • Ensure that all resources (HTML, CSS, JavaScript, images) required to render the initial visible portion of the page are loaded and processed as quickly as possible.
  • Lazy load images and other non-critical resources that are below the fold.

Benefits of Optimizing CRP

  • Faster Perceived Load Times: Users feel the page loads faster, even if the total load time is the same.
  • Improved User Experience: Reduces frustration and bounce rates.
  • Better SEO: Page speed is a ranking factor for search engines like Google.
  • Increased Conversion Rates: Faster pages often lead to higher engagement and conversion.

Drawbacks/Challenges

  • Complexity: Understanding and debugging the CRP can be complex.
  • Tooling: Requires familiarity with browser developer tools (e.g., Performance panel in Chrome DevTools).
  • Trade-offs: Some optimizations might involve trade-offs (e.g., inlining CSS increases HTML size but speeds up initial render).
  • Maintenance: As the application evolves, CRP optimizations need to be maintained and re-evaluated.

Use Cases

  • All Web Pages: Every web page benefits from CRP optimization.
  • Content-Heavy Sites: News websites, blogs, e-commerce sites where initial content visibility is key.
  • Single Page Applications (SPAs): Crucial for fast initial load and smooth transitions.
  • Mobile Web: Especially important on mobile devices with slower networks and less powerful CPUs.

Best Practices Summary

  1. Minimize the number of critical resources: Reduce files, minify, compress.
  2. Minimize the size of critical resources: Only include what's necessary for the initial render.
  3. Optimize the order in which critical resources are loaded: Load critical CSS early, defer/async JavaScript.
  4. Inline critical CSS for above-the-fold content.
  5. Use async or defer for non-critical scripts.
  6. Avoid CSS @import as it can introduce additional round trips.
  7. Optimize images and lazy-load offscreen images.
  8. Leverage browser caching.
  9. Profile and measure: Use browser developer tools to identify bottlenecks in the CRP.

Common Beginner Doubts

  1. What's the difference between DOMContentLoaded and load event?

    • DOMContentLoaded: Fires when the initial HTML document has been completely loaded and parsed, without waiting for stylesheets, images, and subframes to finish loading. This is when the DOM is ready.
    • load: Fires when the whole page has loaded, including all dependent resources such as stylesheets, images, and iframes.

  2. Why is CSS render-blocking?

    • CSS is render-blocking because the browser needs to know how to style elements before it can paint them. If it tried to render before CSSOM construction is complete, the page might initially appear unstyled and then "flash" as styles are applied (Flash of Unstyled Content - FOUC). To avoid this, browsers wait for CSS to be parsed.

  3. Does async or defer make JavaScript load faster?

    • Not directly. async and defer primarily affect when the script is executed relative to HTML parsing, and whether parsing is blocked during download. The download speed itself depends on network conditions and server response times. Their main benefit is unblocking HTML parsing.

  4. Is it always better to inline all CSS?

    • No. Inlining all CSS can make the HTML file very large, potentially slowing down the initial HTML download. It's best to inline only the critical CSS needed for the above-the-fold content. The rest can be loaded asynchronously. This balances fast initial render with efficient caching of larger CSS files.

  5. How do I identify "critical CSS"?

    • Identifying critical CSS can be done manually by inspecting which styles apply to above-the-fold elements, or by using automated tools. Several online tools and npm packages (e.g., critical, penthouse) can analyze your page and extract the critical CSS.

  6. What is "layout thrashing" and why is it bad?

    • Layout thrashing occurs when JavaScript repeatedly and synchronously reads layout-dependent properties (like offsetHeight or getComputedStyle()) immediately after making DOM changes that invalidate the layout (like changing an element's style). Each read forces the browser to recalculate the layout for the entire document. Doing this in a loop can cause significant performance degradation, making animations janky and the UI unresponsive.

  7. How exactly does JavaScript fit into the Critical Rendering Path?

    • JavaScript execution is a crucial part of the CRP. When the HTML parser encounters a <script> tag (unless marked async or defer), it must pause parsing, download the script (if external), and execute it. This is because JavaScript can modify the DOM and CSSOM.
    • Parser-blocking: Standard scripts block the DOM construction. The browser doesn't know what the script will do, so it waits.
    • DOM/CSSOM Access: JavaScript can query and manipulate the DOM (e.g., add/remove elements) and CSSOM (e.g., change styles). If a script queries a style or layout property shortly after modifying the DOM, it can force a synchronous reflow/layout, which can be expensive.
    • Optimization: Using async allows the script to download without blocking the HTML parser and execute as soon as it's ready (potentially interrupting parsing). defer also allows non-blocking download but guarantees execution after HTML parsing is complete and in the order the scripts appear. Minimizing and optimizing JavaScript code itself is also vital.

By understanding and applying these principles, developers can significantly improve the performance and user experience of their web applications.