The critical rendering path

The minimum work before the first paint

Asha opens the Mint tea page at Leaf and Kettle again. In lesson 5.3, one slow stylesheet kept her screen blank for most of a second. This time nothing is held back on purpose. The page has one small stylesheet. But the network is slow: every request takes a 150 ms round trip, a message to the server and its reply back.

Here are three times Chrome wrote down on that visit:

1// The Mint tea page with one small stylesheet, loaded in Chrome.2// Every time is in milliseconds (ms) after the visit started.3const visit = { htmlDone: 162, cssDone: 330, firstPaint: 352 };4 5console.log(`All the HTML had arrived at ${visit.htmlDone} ms.`);6console.log(`The stylesheet arrived at ${visit.cssDone} ms.`);7console.log(`The first words appeared at ${visit.firstPaint} ms.`);

• Lines 1 and 2 are comments. Every time is counted in milliseconds (ms) from the start of the visit.
• Line 3 holds three recorded times: when the last byte of the HTML arrived, when the stylesheet arrived, and when the first words appeared on the screen.
• Lines 5 to 7 print them: All the HTML had arrived at 162 ms., The stylesheet arrived at 330 ms. and The first words appeared at 352 ms.

Every word of the page was on Asha's phone at 162 ms. The words reached her screen 190 ms later. What was the browser doing all that time? Was it busy building the page, or was it waiting for something?

To answer that, you need to know what the browser has to do before it can paint anything at all. It goes through five steps. To render a page is to draw it on the screen, so these steps are called the critical rendering path. They're critical because none of them can be skipped: the first paint comes only after all five.

1. HTML to DOM. The browser reads the HTML and builds the DOM, a tree of the page's elements.
2. CSS to CSSOM. It reads the CSS and builds the CSSOM, a tree of the style rules.
3. The render tree. It puts the two together. The render tree holds every element that will be drawn, each with its styles.
4. Layout. It works out where each element goes on the screen, and how big it is.
5. Paint. It turns each element into pixels.

Here is the whole path in one picture:

The rest of the lesson answers the question about Asha's 190 ms, one part at a time:

• how the five steps work, and how long each one took on her page;
• how to measure the path, by its files, its round trips and its bytes;
• when exactly the first paint happens;
• how to make the path shorter.

For the same story in brief, see the system design lesson The critical rendering path. For how the browser reads the HTML as it arrives, see HTML parsing and the preload scanner.

DOM, CSSOM, and the render tree

HTML becomes the DOM

The browser starts with the HTML. Here is the body of the Mint tea page, the part a visitor sees:

1<body>2  <header>Leaf and Kettle</header>3  <main>4    <h1>Mint tea</h1>5    <p>Fresh mint leaves, picked this week, dried in the shade and packed by hand. Steep a spoonful for four minutes.</p>6    <p class="note">Shown only to staff.</p>7  </main>8</body>

• Line 2 is the header, with the shop's name.
• Lines 3 to 7 are the main part: a heading on line 4, and two paragraphs on lines 5 and 6.
• Line 6 has the class note. It's a message for staff only. The CSS will hide it.

The browser reads these tags and turns each one into an object called an element. Then it links the elements into a tree. The body holds the header and the main part, and the main part holds the heading and the two paragraphs. That tree is the DOM, short for Document Object Model.

Ilya Grigorik's web.dev article sums up how the DOM is built in one line: "Bytes → characters → tokens → nodes → object model." In plain words:

• the bytes from the network become characters;
• the characters become tags, which the article calls tokens;
• each tag becomes an object, a node;
• the nodes are linked into a tree, the DOM.

The browser doesn't wait for the last byte to start. It builds the DOM bit by bit as the HTML arrives, as lesson 5.1 showed.

CSS becomes the CSSOM

Next comes the CSS. Here is the page's whole stylesheet, styles.css:

1body { margin: 0; font-family: system-ui, sans-serif; color: #2b2a27; background: #fbf8f1; }2header { padding: 16px; font-weight: 700; background: #3f6f31; color: #fff; }3main { padding: 16px; max-width: 36em; }4.note { display: none; }

• Line 1 sets the font and the colors for the body.
• Line 2 makes the header green, with white text.
• Line 3 adds some space around the main part.
• Line 4 hides every element with the class note.

The browser turns the CSS into a tree too. It's called the CSSOM, short for CSS Object Model. Why a tree? Because styles flow downwards. The font on line 1 is set on the body, so everything inside the body gets it too, unless a more specific rule says otherwise. web.dev says the rules "cascade down".

There's one big difference from the DOM. The browser can't use half a stylesheet. A rule near the end can change a rule near the top. So the CSSOM can only be used once the whole stylesheet has arrived and been read. That's why a stylesheet holds back the first paint, as lesson 5.3 showed.

The render tree holds only what will be drawn

Now the browser has both trees. It combines them into the render tree, in three steps:

1. It walks the DOM from the top, one element at a time.
2. For each element, it finds the CSS rules that match, and works out its final styles.
3. It keeps the elements that will be drawn, and leaves out the rest.

Here is that last step for the Mint tea page's body:

1// The elements in the Mint tea page's body.2const elements = ["body", "header", "main", "h1", "p", "p.note"];3// The stylesheet's rule .note { display: none; } hides one of them.4const hidden = ["p.note"];5 6const renderTree = elements.filter((element) => !hidden.includes(element));7console.log(`The body has ${elements.length} elements in the DOM.`);8console.log(`Only ${renderTree.length} go into the render tree: ${renderTree.join(", ")}.`);

• Line 2 lists the body's elements.
• Lines 3 and 4 say which one is hidden. Line 4 of the stylesheet gives p.note display: none.
• Line 6 keeps every element that isn't hidden. Those make the render tree.
• Line 7 prints The body has 6 elements in the DOM.
• Line 8 prints Only 5 go into the render tree: body, header, main, h1, p.

The staff note is still in the DOM, so JavaScript can find it. But it won't be drawn, so it isn't in the render tree.

And the head? Every browser starts with a few default styles, which the HTML standard lists. One of them gives the head display: none, along with tags that live in it, like title and link. So nothing in the head is drawn either. Here are both trees side by side:

display: none isn't the only way to hide something. visibility: hidden hides it too, but in a different way.

web.dev puts it this way. An element with visibility: hidden is invisible, but "still occupies space in the layout", as an empty box. display: none removes it from the render tree completely. So pick display: none when the space should close up, and visibility: hidden when it should stay.

Layout and paint

The render tree says what to draw, and how it should look. It doesn't yet say where. Layout works that out: the exact size and position of every element on this screen. A width of 50% becomes a real number of pixels. So the same page gets a different layout on a narrow phone than on a wide laptop.

Last comes paint. The browser turns each element's box into pixels. web.dev calls this step "painting" or "rasterizing".

Busy, or waiting?

Back to Asha's question. Each of the five steps runs on the browser's main thread. That's the part of the browser that runs the page's JavaScript, and does its layout and paint, one job at a time. Chrome's trace records the jobs it runs, with when each one started and how long it took. Here is the work on her page:

1// The browser's own work on the page with a stylesheet, from Chrome's trace.2// Each step: its name, and how long it took in ms.3const steps = [4  ["Parse HTML", 0.2],5  ["Parse stylesheet", 0],6  ["Recalculate style", 0.2],7  ["Layout", 4.8],8  ["Paint", 0.1],9];10 11const work = steps.reduce((total, step) => total + step[1], 0);12console.log(`All five steps took ${work.toFixed(1)} ms.`);

• Lines 1 and 2 are comments. They say where the numbers come from.
• Lines 3 to 9 list the five steps, each with how long it took, in milliseconds.
• Line 11 adds up those times.
• Line 12 prints All five steps took 5.3 ms.

Each name is how Chrome's trace labels one step of the path:

• Parse HTML built the DOM, and Parse stylesheet built the CSSOM. The stylesheet was so small that reading it rounds to 0 ms.
• Recalculate style worked out every element's final styles for the render tree.
• Layout and Paint came last. Layout was the biggest step, at 4.8 ms.

So the browser was busy for about 5 ms of Asha's 190. What happened in the rest? Look at when it started reading each file:

1// The same page: when the browser started reading each file, in ms.2const readHtml = 168.7;3const readStylesheet = 331.7;4 5console.log(`The browser waited ${(readStylesheet - readHtml).toFixed(1)} ms for the stylesheet.`);

• Line 2 is when the browser started reading the HTML. Line 3 is when it started reading the stylesheet.
• Line 5 subtracts one from the other. It prints The browser waited 163.0 ms for the stylesheet.

Between those two moments, the browser couldn't go on with the path. The stylesheet was still on its way over the network. That wait was more than 30 times as long as all five steps put together. In the shop, dressing the window takes a few minutes. Waiting for the labels to arrive takes all morning.

Why it matters: making the browser's work faster would save Asha almost nothing. To paint sooner, the page has to make the browser wait less. The next section shows how to measure that wait.

Critical resources, bytes, and path length

If waiting makes the first paint late, you need a way to measure the waiting. A cook planning the first plate of the day has the same problem.

Grigorik's article on analyzing the critical path measures it with three numbers:

• Critical resources are the files that "could block initial rendering of the page". On Asha's page, that's the HTML and the stylesheet.
• Critical path length is the "number of roundtrips" it takes to fetch them all.
• Critical bytes are the total size of those files, as they travel over the network.

Pictures aren't on the list. In Grigorik's words, "Images don't block the initial render of the page."

To see what each number does, the course loaded the Mint tea page four ways, changing one thing at a time. The network stayed the same: a 150 ms round trip, at 5 megabits a second. A megabit is a million bits, the 0s and 1s that all data is made of. At that speed, every kilobyte takes about 1.6 ms to arrive.

A second file means a second trip

First, two versions. One has its CSS inside the HTML, in a <style> tag. The other links the CSS as its own file, like Asha's page:

1// The same page twice: CSS inside the HTML, then CSS in its own file.2const inline = { criticalFiles: 1, firstPaint: 196 };3const linked = { criticalFiles: 2, firstPaint: 352 };4 5console.log(`CSS inside the HTML: ${inline.criticalFiles} critical file, first paint at ${inline.firstPaint} ms.`);6console.log(`CSS in its own file: ${linked.criticalFiles} critical files, first paint at ${linked.firstPaint} ms.`);7console.log(`The second file pushed the first paint back ${linked.firstPaint - inline.firstPaint} ms.`);

• Lines 2 and 3 hold, for each version, how many critical files it had, and when its first paint came.
• Lines 5 and 6 print CSS inside the HTML: 1 critical file, first paint at 196 ms. and CSS in its own file: 2 critical files, first paint at 352 ms.
• Line 7 subtracts. It prints The second file pushed the first paint back 156 ms.

Why 156 ms? The browser can't ask for styles.css until it has read the link to it in the HTML. So the stylesheet needs a trip of its own, after the trip that brought the HTML. One round trip on this network is 150 ms. So this page's critical path length is two round trips. With the CSS inside the HTML, it's one.

Files found together share a trip

Next, the page with a stylesheet, and then the same page with a script in its head as well:

1// The page with a stylesheet, then with a script in the head as well.2const stylesheet = { criticalFiles: 2, firstPaint: 352 };3const withScript = { criticalFiles: 3, firstPaint: 364 };4 5console.log(`With a stylesheet: ${stylesheet.criticalFiles} critical files, first paint at ${stylesheet.firstPaint} ms.`);6console.log(`With a script too: ${withScript.criticalFiles} critical files, first paint at ${withScript.firstPaint} ms.`);7console.log(`The third file pushed the first paint back ${withScript.firstPaint - stylesheet.firstPaint} ms.`);

• Lines 2 and 3 hold each page's critical files and first paint.
• Lines 5 and 6 print With a stylesheet: 2 critical files, first paint at 352 ms. and With a script too: 3 critical files, first paint at 364 ms.
• Line 7 prints The third file pushed the first paint back 12 ms.

One more critical file, but only 12 ms later, not another 150. The browser found the link tag and the script tag in the same HTML, so it asked for both at once. They traveled on the same round trip, the way two things on one shopping list come home on one trip. Grigorik's article found the same: three critical resources, but still two round trips, "because we can transfer the CSS and JavaScript in parallel."

Bytes take time too

Last, the stylesheet gets heavier. The course added 120 KB of rules the page never uses, like a big framework's utility classes:

1// The page with a small stylesheet, then with 120 KB of unused rules added to it.2const small = { criticalBytes: 1324, firstPaint: 352 };3const heavy = { criticalBytes: 121214, firstPaint: 544 };4 5console.log(`Small stylesheet: ${small.criticalBytes} critical bytes, first paint at ${small.firstPaint} ms.`);6console.log(`Heavy stylesheet: ${heavy.criticalBytes} critical bytes, first paint at ${heavy.firstPaint} ms.`);7console.log(`The extra bytes pushed the first paint back ${heavy.firstPaint - small.firstPaint} ms.`);

• Lines 2 and 3 hold each page's critical bytes, the HTML and the stylesheet together, and its first paint.
• Lines 5 and 6 print Small stylesheet: 1324 critical bytes, first paint at 352 ms. and Heavy stylesheet: 121214 critical bytes, first paint at 544 ms.
• Line 7 prints The extra bytes pushed the first paint back 192 ms.

The heavy page has the same two critical files and the same two round trips. Only the bytes changed. About 120,000 extra bytes, at 1.6 ms a kilobyte, take about 192 ms to arrive. And reading all those rules? It took the browser 0.8 ms. The unused CSS cost almost nothing to read, and a lot to download.

Why it matters: each of the three numbers can make the first paint late on its own. So check all three when a page paints late.

Now try all four pages yourself. Pick one, and compare how long the faint bars wait with how short the solid steps are:

First paint and first contentful paint

So far, this lesson has called it "the first paint", as if it were one moment. The Paint Timing standard defines two:

• First paint is the first time the browser draws anything for the page, apart from its plain default background. A colored background counts.
• First contentful paint, or FCP, is the first time it draws text or an image from the page.

In the shop window, first paint is the lights coming on. First contentful paint is the first item you can see. When the very first frame already has text in it, both are reported for that same frame, with the same time. The browser hands both to JavaScript as paint entries, which you read with performance.getEntriesByType("paint"). Every first-paint time in this lesson's examples is the first contentful paint.

The Paint step comes before the paint

There's one more detail. The time in the paint entry isn't when the Paint step ran. After that step, the browser still has to get the finished frame onto the screen. So the standard uses the moment the frame was shown, when the browser knows it. When it doesn't, it uses the end of the rendering work.

Here are the two times for Asha's page:

1// The page with a stylesheet: the Paint step from Chrome's trace, and its paint entry.2const paintStep = { start: 337.5, duration: 0.1 };3const firstContentfulPaint = 352;4 5const paintStepEnd = paintStep.start + paintStep.duration;6console.log(`The Paint step ended at ${paintStepEnd} ms.`);7console.log(`The first contentful paint came ${(firstContentfulPaint - paintStepEnd).toFixed(1)} ms later.`);

• Line 2 holds the recorded Paint step: when it started, and how long it took.
• Line 3 holds the first contentful paint, from the page's paint entry.
• Line 5 adds the start and the length, to find when the step ended. Line 6 prints The Paint step ended at 337.6 ms.
• Line 7 prints The first contentful paint came 14.4 ms later.

On all four recorded pages, the first contentful paint came after the Paint step. Why it matters: when you line up a trace with a paint entry, expect the paint entry to be a little later. It's the plate reaching the table.

Shortening the path

Now you can answer Asha's question. Of the 190 ms between the HTML arriving and the first words, the browser worked for about 5. Most of the rest, 163 ms, went on waiting for the stylesheet. So to paint sooner, cut the waiting. Each way to do that shrinks one of the three numbers. Read the table across: each row is one number, how to shrink it, and why that helps.

Putting CSS inside the HTML is called inlining it. It saved the Mint tea page a whole round trip: its first paint came at 196 ms instead of 352. So why not inline every stylesheet on every page?

web.dev's article on critical CSS says the same thing. Inlining "prevents the browser from caching the CSS for reuse on subsequent page loads, so it's best to use it sparingly." So inline only the small part of the CSS that the first screen needs. The rest can stay in its own file, which the browser can keep in its cache.

Try it. Choose what the page has, and watch the three numbers and the estimate change:

1function criticalPath(files, rttMs, kbps) {2  const roundTrips = files.some((file) => file.critical && file.name !== "page") ? 2 : 1;3  const bytes = files.filter((file) => file.critical).reduce((sum, file) => sum + file.bytes, 0);4  return { roundTrips, bytes, ms: roundTrips * rttMs + (bytes * 8) / kbps };5}6 7console.log(criticalPath([{ name: "page", critical: true, bytes: 800 }], 150, 5000));

In the panel's code, line 2 counts the round trips, line 3 adds up the critical bytes, and line 4 turns both into time.

On the path, or off it?

Here are eight things a real page might load. For each one, ask a single question: does the first paint have to wait for it? Sort them:

Common mix-ups

• "Parsing and layout are the slow part." No. On the Mint tea page, all five steps took 5.3 ms. Waiting for the stylesheet took 163 ms.
• "Every critical file adds a round trip." No. Files the browser finds together travel together. The script added 12 ms, not 150.
• "Pictures hold back the first paint." No. They aren't critical. The page paints, and the pictures fill in later.
• "display: none and visibility: hidden do the same thing." No. display: none leaves an element out of the render tree. visibility: hidden keeps it, as an empty box that takes up space.
• "Inline all the CSS." No. Inlined CSS comes again with every page, and the browser can't cache it on its own. Inline only what the first screen needs.
• "The Paint step's time is the first contentful paint." No. The paint entry marks when the frame was shown, where the browser knows that moment. On Asha's page, it came 14.4 ms after the Paint step.

Practice exercises

Answer first, then use the hints.

// The elements in the Mint tea page's body.
const elements = ["body", "header", "main", "h1", "p", "p.note", "aside.promo"];
// The rules for .note and .promo both say display: none.
const hidden = ["p.note", "aside.promo"];

const renderTree = elements.filter((element) => !hidden.includes(element));
console.log(`The body has ${elements.length} elements in the DOM.`);
console.log(`Only ${renderTree.length} go into the render tree: ${renderTree.join(", ")}.`);

// The same page: when the browser started reading each file, in ms.
const readHtml = 168.7;
const readStylesheet = 531.7;

console.log(`The browser waited ${(readStylesheet - readHtml).toFixed(1)} ms for the stylesheet.`);

Check your understanding

For each question, ask yourself: is this about the five steps, or about the path's files, round trips and bytes?

Key takeaways

• The first paint needs the DOM and the CSSOM. The browser combines them into the render tree, then runs layout and paint.
• display: none leaves an element out of the render tree. visibility: hidden keeps it, as an empty box.
• On the Mint tea page, the five steps took about 5 ms. Waiting for the stylesheet took more than 30 times as long.
• Measure the critical path with three numbers: its critical files, its round trips, and its critical bytes.
• Files the browser finds together share a round trip. Their bytes still take time.
• The paint entry's time comes a little after the Paint step. It's when the frame was shown, where the browser knows it.

Sources

The facts on this page come from these docs and standards:

• Critical rendering path, MDN.
• Constructing the Object Model, Ilya Grigorik, web.dev.
• Render-tree construction, layout, and paint, Ilya Grigorik, web.dev.
• HTML Standard: hidden elements, WHATWG.
• Main thread, MDN.
• Analyzing critical rendering path performance, Ilya Grigorik, web.dev.
• Paint Timing, W3C.
• PerformancePaintTiming, MDN.
• Extract critical CSS, Milica Mihajlija, web.dev.
• Coverage: Find unused JavaScript and CSS, Chrome for Developers.

Coming next: Reading a waterfall. The bars in this lesson's playground are a small waterfall. Next, you'll read every bar, color and gap of a real one, and spot the five most common problems.