Tags: web-dev concept

The Critical Rendering Path

Date: 2026-08-16

---

Everything that must happen between the first byte and the first useful paint. Optimising it means removing things from the path, not making them faster — a resource you don’t need is infinitely quicker than one you’ve compressed.

---

What it is

The critical rendering path is the minimum sequence of work required before the browser can show meaningful content: fetch HTML, parse it, fetch and parse blocking CSS, run blocking JavaScript, build the render tree, lay it out, paint it.

HTML request ──▶ HTML arrives ──▶ parse
                                    │
                    ┌───────────────┴──────────────┐
                    ▼                              ▼
              CSS (blocks render)         JS (blocks parse)
                    │                              │
                    └───────────────┬──────────────┘
                                    ▼
                            render tree ──▶ layout ──▶ FIRST PAINT

Anything on that diagram delays pixels. Anything not on it doesn’t.

The three blockers

1. Blocking CSS. The browser won’t paint until it has all stylesheets that apply, because painting first would show unstyled content and then rearrange it. Every <link rel="stylesheet"> in <head> is a round trip before first paint.

2. Blocking JavaScript. A plain <script src> in <head> stops parsing entirely — the browser hasn’t even discovered the body content yet. See Document Parsing.

3. Round trips. Each is a full network latency. Three chained requests on a 150ms connection is 450ms before anything can start, regardless of file sizes. Latency dominates bandwidth on the critical path — see Latency and Bandwidth.

In plain terms: the page can’t paint until the browser has everything it needs to paint correctly. Every extra thing you make it wait for is time the user spends looking at nothing.

Shortening it

In order of effect:

• Inline critical CSS, load the rest asynchronously. The above-the-fold styles arrive in the HTML with no extra round trip; everything else stops blocking

  <style>/* above-the-fold rules only */</style>
  <link rel="stylesheet" href="rest.css" media="print" onload="this.media='all'">

• defer all scripts. Nothing in <head> should block parsing. See Document Parsing
• Prioritise the LCP element. Its image should be in the markup — discoverable by the preload scanner — never lazy-loaded, and ideally fetchpriority="high". See Largest Contentful Paint
• preconnect to origins you’ll definitely use, so DNS, TCP and TLS happen in parallel with parsing rather than after it — Resource Hints
• Self-host fonts and preload them. A font on a third-party origin adds a whole connection setup to the path — Font Loading
• Reduce redirects. Each is a full round trip before the HTML has even started arriving

What isn’t on the path

Equally important, and often where the effort goes wrongly:

• Below-the-fold images
• Analytics, tag managers, chat widgets, review scripts — none of them need to run before paint. See Third-Party Scripts
• Anything the user hasn’t scrolled to
• Fonts for content further down

Moving something off the critical path beats optimising it. A 40KB script that runs after paint costs nothing visible; the same script blocking parse costs its entire download and execution time.

The one that undoes all of it

An anti-flicker snippet from a client-side testing tool hides the page until the tool loads, putting a third-party script squarely on the critical path — for every visitor, whether or not a test is running. It’s usually the single largest self-inflicted addition to the path on a retail site. See Flicker and Flash of Original Content.

Measuring

• Time to First Byte — server and network, the floor the rest sits on
• First Contentful Paint — the first thing painted
• Largest Contentful Paint — the main content, and the metric that gets reported
• DevTools → Performance → the “Timings” track, or the Network panel’s waterfall read left to right. Anything on the waterfall before first paint is on the path, by definition

Field data first, then lab — see Field vs Lab Data and Guide - Diagnosing and Fixing Performance.