Critical rendering path on 29 homepages: 329 resources before the first paint

FIELD TEST · 2026-10-04 · 29 homepages · single HTML fetch

Sample and method: 34 homepages attempted — the 30-site panel we have reused since 2026-08-15, plus our own four sites. Each was fetched once on 2026-10-04 with curl over HTTPS and a desktop browser user agent. Four returned 403 and reddit.com returned an 8 KB shell with no real head, leaving 29. From each raw HTML we counted blocking stylesheets and synchronous scripts in the <head>. One fetch per site, no rendering, no repeat.

The critical rendering path is everything the browser has to resolve before it can paint the first pixel: the connection, the HTML, the stylesheets and any scripts that stop parsing. Across 29 homepages fetched once each, the head carried 329 render-blocking resources — 307 stylesheets and 22 synchronous scripts — a median of 5 per page, with one page shipping 66.

How we measured it

A resource is render-blocking if the browser cannot paint before it is done. Two things in the head do that: a stylesheet, because layout cannot be computed without it, and a classic script with a src that has neither defer nor async, because parsing stops until it runs. We counted both from the raw HTML, and treated a script as non-blocking if it was defer, async, or type="module".

We also recorded whether any inline <style> block appeared before the first blocking stylesheet link, as a rough sign that critical CSS was inlined ahead of the blocking CSS. That is a proxy, not a proof: a page can inline a style block and still be blocked by something else. Everything below comes from one afternoon on one machine, and the numbers are counts from markup, not the wasted-milliseconds figure a Lighthouse run would give.

Critical rendering path: what 29 homepages put before the first paint

Add the panel up and the blocking work is almost entirely CSS. The 307 stylesheets are 93% of the 329 resources; the 22 synchronous scripts are the other 7%, spread over 13 of the 29 pages. The table is the eleven heaviest homepages, worst first, plus the panel totals.

Four homepages ship zero blocking resources: www.framer.com, www.shopify.com, www.wired.com and www.bbc.com. None of them ships an external stylesheet in the head at all — they inline their styling instead. At the other end, eleven of the 29 ship more than ten blocking resources. The gap between the two groups is roughly the entire cost of the first paint, which is why the count matters more than the byte total.

Stylesheets carry almost all of it

The scripts are not the problem here. Only 13 of 29 homepages had a synchronous script in the head, and they averaged under two each. The stylesheet count is where the range opens up: a median of 5, a maximum of 66. A page with 66 separate stylesheet links in the head is not one request; it is 66 chances to wait.

Nine of the 29 pages inline at least one <style> block before the first blocking stylesheet link, and the four zero-blocking pages are a subset of that pattern. Inlining is the only move in the panel that reliably removes the blocking link rather than deferring it. Whether it helps depends on how big the inline block gets, which is exactly the tradeoff the handbook chapter walks through.

What the numbers do not prove

First, a raw count is not a paint time. Two stylesheets fetched in parallel and one fetched from a cold host can cost the same or very different amounts of time; markup cannot tell us which. Second, this is one fetch per site on one afternoon, with no repeat, so a site that lazy-loads its CSS with JavaScript would be undercounted here and no spread was measured. Third, the 29 homepages are a convenience panel, not a sample of the web. The shares describe these sites; they are not an estimate of anyone else's.

We also cannot separate the sites that inline critical CSS on purpose from the ones whose build tool inlines everything by default. The count says an inline block precedes the first stylesheet link; it does not say anyone decided that.

Common questions

What is the critical rendering path?

It is the ordered set of steps the browser runs before it can paint the first pixel: fetch the HTML, build the document and render trees, resolve any CSS the layout needs, and run any script that stops parsing. Shortening it means removing steps from that sequence, not making later steps faster.

How do I find my own blocking resources?

Open dev tools, reload, and read the network waterfall: anything the first paint is waiting on shows up before the first contentful paint marker. For a crawl-level count that matches what a search crawler sees, fetch the raw HTML and count the stylesheet and synchronous-script elements in the head — the two categories we counted here.

Do more stylesheets always mean a slower page?

No, and this panel cannot settle it. Many stylesheets served from one connection can arrive almost together, and a single stylesheet from a slow third party can be worse. The count is a signal to look, not a verdict; the waterfall tells you the order and the wait.

Should I inline all my CSS?

No. An inline block travels inside every HTML document and cannot be cached across pages, so a large one makes every navigation heavier. Inline the first screen, keep the rest as a normal cached stylesheet, and re-measure rather than assuming.

The boundary worth keeping: this is a census of markup, and the home page is not the page most visitors use. The next step worth doing is to run the same count against the pages people land on and see whether the blocking list changes, rather than optimising the home page alone. Watching that difference across a site is part of what QueryWin measures; for the metric this feeds, the first contentful paint survey gives the paint-side reading of a similar panel, the earlier render blocking css survey counted only the stylesheet half of this same story, and render blocking resources is the chapter that turns the list into a fix order.