Speed Up Websites Like a Pro: Master Critical Rendering Path

MasterApril 20, 2025

5 7 minutes read

Forget everything you’ve heard about website speed optimization. Compressing images and minifying CSS are table stakes. The real game-changer? Mastering the Critical Rendering Path.

The Critical Rendering Path is the steps browsers take to convert HTML, CSS, and JavaScript into pixels on the screen. Optimizing this path means making your website load faster.

How the Critical rendering path works

DOM Construction → Parsing HTML to build the Document Object Model
CSSOM Construction → Processing CSS to create the CSS Object Model
JavaScript Execution → Running scripts that might modify the DOM or CSSOM
Render Tree Formation → Combining DOM and CSSOM
Layout → Calculating the geometry and position of elements
Paint → Filling in actual pixels

Step 1: DOM Construction

The browser reads your HTML, much like an architect reads a blueprint. It creates a structured framework known as the DOM tree. This is like a building’s skeleton.

❌ Bad Code:

<!DOCTYPE html>
<html>
  <head>
    <title>Slow Site</title>
    <!-- Bad: Multiple render-blocking stylesheets -->
    <link rel="stylesheet" href="reset.css">
    <link rel="stylesheet" href="framework.css">
    <link rel="stylesheet" href="styles.css">
    <!-- Unnecessary tags & scripts -->
    <script src="unused.js"></script>
    <!-- Bad: Render-blocking JavaScript in the head -->
    <script src="jquery.js"></script>
    <script src="analytics.js"></script>
    <script src="app.js"></script>
  </head>
  <body>
    <h1>Welcome!</h1>
    <p>This is my website.</p>
    <!-- Excessive nesting slows parsing -->
    <div><div><div><h1>Why so slow?</h1></div></div></div>
  </body>
</html>

🐢 Why it’s slow: Bloated HTML → DOM takes longer to construct.

✅ Good Code:

<!DOCTYPE html>
<html>
  <head>
    <title>My Website</title>
    <link rel="stylesheet" href="styles.css">
  </head>
  <body>
    <h1>Welcome!</h1>
    <p>This is my website.</p>
    <!-- JavaScript at the bottom -->
    <script src="app.js"></script>
  </body>
</html>

🚀 Why it’s fast: Clean, minimal HTML → DOM builds instantly.

Why is good code better?

Because it allows the browser to start rendering content faster, you have to apply these tips:

Puts JavaScript at the bottom so HTML parsing isn’t blocked.
Avoid excessive nesting (flatten your structure as much as possible).
Minimizes render-blocking resources in the <head>.

Step 2: CSSOM Construction

Similar to the DOM, but for CSS, the browser processes CSS and builds the CSS Object Model (CSSOM), takes all your CSS rules, and creates another tree.

❌ Bad Code:

/* Giant external stylesheet */
@import url("bloated-styles.css");

/* Unused styles */
.unused-class { 
  background: red; 
  /* Hundreds more lines... */
}

/* Overly specific and complex selectors slow down CSSOM construction */
body div.container article section.content div.article-body p { color: gray; }

/* Unnecessary nesting creates more work */
nav {
  background: #fff;
  ul {
    margin: 0;
    li {
      display: inline-block;
      a {
        padding: 10px;
        &:hover {
          text-decoration: underline;
        }
      }
    }
  }
}

🐢 Why is it bad?

Large CSS blocks render until fully loaded.

✅ Good Code:

/* Simplified and focused CSS */
h1 { color: blue; }
p { font-size: 16px; }

🚀 Why is good code better?

Uses simple and flat selectors that are faster to parse.
Minify & remove unused CSS (tools like PurgeCSS help).
Avoids deep nesting that slows down CSSOM construction.

There is another important thing could affect your website performance which is related to fonts:

❌ Bad Code:

<head>
  <!-- Third-party fonts with many weights -->
  <link href="https://fonts.googleapis.com/css2?family=Roboto:wght@300;400;500;700&family=Playfair+Display:ital@0;1&display=swap" rel="stylesheet">
  
  <style>
    @font-face {
      font-family: 'CustomFont';
      /* No font-display property - text invisible while loading */
      src: url('/fonts/custom-font.ttf') format('truetype');
    }
    
    body { font-family: 'Roboto', sans-serif; }
    h1 { font-family: 'Playfair Display', serif; }
    .special { font-family: 'CustomFont', sans-serif; }
  </style>
</head>

🐢 Why is it bad?

No preloading strategy.
Missing font-display property (causes invisible text).
Uses older TTF format (larger file size).
Downloads multiple font families and weights.
No fallback strategy for smooth rendering.

✅ Good Code:

<head>
  <!-- Preload critical font -->
  <link rel="preload" href="/fonts/roboto.woff2" as="font" type="font/woff2" crossorigin>
  
  <style>
    @font-face {
      font-family: 'Roboto';
      font-weight: 400;
      font-display: swap; /* Show text immediately with system font */
      src: local('Roboto'), url('/fonts/roboto.woff2') format('woff2');
    }
    
    body {
      font-family: 'Roboto', system-ui, sans-serif; /* Good fallback stack */
    }
  </style>
</head>

🚀 Why is good code better?

Preloads the font to start downloading early.
Uses font-display: swap so text is visible immediately.
Checks for locally installed fonts first
Uses WOFF2 format (smaller file size)
Provides system font fallbacks

Step 3: JavaScript Execution

JavaScript is parser-blocking by default, meaning HTML parsing pauses when the browser hits a script tag. It waits until the system fetches and runs the script.

❌ Bad Code:

<head>
  <!-- Blocks HTML parsing -->
  <script src="large-library.js"></script>
  
  <!-- Long-running inline script blocks everything -->
  <script>
    // Heavy computation that blocks rendering
    for (let i = 0; i < 100000; i++) {
      const element = document.createElement('div');
      element.textContent = `Element ${i}`;
      // Forcing layout recalculations within a loop
      document.body.appendChild(element);
      console.log(element.offsetHeight);
    }
  </script>
</head>

🐢 Why it’s bad:

The first script is in the <head> without async or defer, completely blocking HTML parsing until it downloads and executes.
Contains a long-running inline script that blocks the main thread for an extended period.
Mixes DOM reads (offsetHeight) and writes (appendChild) in a loop, causing layout thrashing
Performs excessive DOM manipulations, adding 100,000 elements to the document.
Located in the <head>, meaning it will delay the initial render of the page.

✅ Good Code:

<!-- Async loading for non-critical scripts -->
<script src="analytics.js" async></script>

<!-- Defer for scripts that need the DOM but can wait -->
<script src="features.js" defer></script>

<!-- Use module type for automatic deferred loading -->
<script type="module" src="app.js"></script>

<!-- Place non-critical scripts at the end of body -->
<body>
  <!-- Content here -->
  <script src="enhancements.js"></script>
</body>

Why is good code better?

Use async for scripts that run on their own.
Use defer for scripts that need the full DOM
Move non-critical scripts to the end of the <body>
Consider using ES modules with type=”module”
Break up long-running JavaScript operations
Avoid synchronous network requests

Step 4: Render Tree Formation

The browser merges DOM + CSSOM to create the Render Tree, which only includes elements that will be displayed on screen.

This only includes visible elements, and anything in <head> or with elements with display: none won’t be in the Render Tree.

Warning: hidden element which has display: none is still processed but not rendered, which affects the performance.

❌ Bad Code:

<html>

<body>
  <!-- Hidden element (still processed but not rendered) -->
  <div style="display: none">Secret Message</div>
  
  <!-- CSS loaded late → delays rendering -->
  <p class="late-style">This text is unstyled at first</p>
  
  <!-- Script in the middle → blocks DOM & Render Tree -->
  <script>
    alert("This pauses everything!");
  </script>
  
  <!-- External CSS loaded late → delays rendering more -->
  <link rel="stylesheet" href="styles.css">
  
  <!-- Complex CSS → harder to calculate -->
  <div style="width: calc(100% - 20px + 15%)">Complex Layout</div>
  
  <!-- CSS appears after the element it styles! -->
  <style>
    .late-style { color: red; }
  </style>
</body>
</html>

🐢 Why is it bad?

display: none elements still take time to process
CSS loaded late → displays HTML content before the CSS has loaded, which is known as Flash of Unstyled Content – FOUC
Script in the middle → stops the DOM & Render Tree until it runs
Complex CSS (calc()) → takes longer to compute positions
CSS after HTML → browser has to re-process styles

✅ Good Code:

<!DOCTYPE html>
<html>
<head>
  <!-- CSS loaded early -->
  <style>
    .title { color: blue; }
  </style>
</head>
<body>
  <!-- Only visible content -->
  <h1 class="title">Hello World</h1>
  
  <!-- Script at the bottom, doesn't block rendering -->
  <script src="app.js" defer></script>
</body>
</html>

🚀 Why is good code better?

Small and simple DOM → Faster to process
CSS in <head> → Styles ready early
Script at the bottom with defer → Doesn’t block rendering

Step 5: Layout

During the layout or reflow phase, the browser calculates each visible element’s exact position and size in the render tree.

❌ Bad Code:

/* Complex calculations that slow layout */
.complex-element {
  width: calc(100% - 20px + 2em - 3vw);
  margin: 1.5vw calc(2% + 10px);
  padding: calc(1rem + 2px);
}

/* Multiple layout models nested */
.layout-chaos {
  display: flex;
}
.layout-chaos > div {
  display: grid;
}
.layout-chaos > div > div {
  float: left; /* Mixing layout models increases complexity */
}

🐢 Why is it bad?

Uses complex calc() expressions that require more CPU processing to compute
Mixes different units (px, em, vw, %), which increases calculation complexity
Nests different layout models (flex → grid → float), forcing the browser to handle multiple layout algorithms
Each calculation must be recalculated during window resizing, increasing the layout cost
Mixing old (float) and new (flex, grid) layout models is less optimized

✅ Good Code:

/* Predictable layout models */
.container {
  display: grid;
  grid-template-columns: repeat(12, 1fr);
  gap: 16px;
}

/* Fixed sizes where possible */
.sidebar {
  width: 300px;
}

/* Avoid forced synchronous layouts */
.content {
  will-change: transform; /* For elements that will animate */
}

🚀 Why is good code better?

Uses modern layout systems (Grid) that are optimized for performance
Has an explicit grid layout with predefined columns, making layout calculations more predictable
Sets fixed dimensions where appropriate, reducing calculation complexity
Uses will-change to inform the browser about properties that will animate, allowing for optimization
Keeps the layout model consistent, which is easier for browsers to process

Step 6: Paint

The browser fills in pixels for each element in the render tree.

❌ Bad Code:

/* Pretty but bad for performance */
.header {
  background-image: url('complex-pattern.png');
  box-shadow: 0 2px 10px rgba(0,0,0,0.3);
  border-radius: 10px;
  color: rgba(255,255,255,0.8);
  text-shadow: 0 1px 2px #000;
}

/* Properties that trigger layout + paint */
.inefficient-animation {
  top: 0;
  left: 0;
  width: 100px;
  height: 100px;
  animation: move-and-resize 2s infinite;
}

@keyframes move-and-resize {
  50% {
    top: 100px;
    left: 100px;
    width: 150px; /* Changes dimensions, forcing layout recalculations */
    height: 150px;
  }
}

🐢 Why is it bad?

Complex background image and Multiple visual effects (shadow, transparency).
Animates position properties (top and left) instead of transform: translate().
Changes dimensions (width and height) during animation, forcing layout recalculation on every frame.
Triggers the entire rendering pipeline (layout → paint → composite) on every animation frame.

✅ Good Code:

/* Properties that only affect paint, not layout */
.button {
  color: blue;
  background-color: white;
  box-shadow: 0 2px 4px rgba(0,0,0,.1);
}

/* GPU-accelerated properties for animations */
.animated-element {
  transform: translateZ(0); /* Promotes to GPU layer */
  opacity: 0.8;
  transition: transform 0.3s ease, opacity 0.3s ease;
}

.animated-element:hover {
  transform: scale(1.05) translateZ(0);
  opacity: 1;
}

🚀 Why is good code better?

Focuses on animating only transform and opacity, which are GPU-accelerated properties.
Uses translateZ(0) to promote the element to its composite layer (GPU acceleration).
Avoids animating layout properties that would trigger reflow.

Conclusion

Understanding the Critical Rendering Path is essential for building fast, responsive websites. Making each step better, from HTML parsing to the final painting, can speed up your site and improve user experience.

To optimize the Critical Rendering Path, you need to make smart choices at each rendering stage: