Render blocking css: 228 stylesheets in 26 heads, and none of them opts out
Render blocking css is the default, and on 26 heavily optimised homepages nobody opts out. All 285 external stylesheets carry either no media attribute or media=all; not one uses the media=print pattern every performance guide recommends.
FIELD TEST · 2026-08-27 · 26 homepages · 285 stylesheets · single crawl · raw HTML only
Sample and method: the same 30-site panel in use since 2026-08-15, each homepage fetched once on 2026-08-27 with a browser user agent, no rendering. We read every <link> whose rel contained stylesheet, plus every rel="preload" as="style" and every inline <style> block, and recorded the media attribute, the position relative to </head>, and the byte size of the inline blocks.
Render blocking css is the default, and on 26 of the most heavily optimised homepages on the web, nobody opts out of it. All 285 external stylesheets carry either no media attribute or media="all". Not one uses media="print", the deferred-loading pattern that every performance guide recommends. Instead, five sites skip the external stylesheet entirely and inline everything.
How we measured it
One HTTP request per site, no rendering, no retries. Inclusion was fixed before the run: final status 200, decoded body at least 10,000 bytes, body containing <body. Four of the 30 failed — www.canva.com returned 429, stackoverflow.com and medium.com returned 403, www.reddit.com returned an 8,393-byte shell — leaving 26.
Head versus body was decided by the parser's own position tracking, not by a byte offset, so a stylesheet counts as being in the head only if the parser had not yet seen </head>. That distinction carries the whole report, because MDN's link reference, read on 2026-08-27, says: "Only link elements in the document's <head> can possibly block rendering. By default, a link element with rel="stylesheet" in the <head> blocks rendering when the browser discovers it during parsing."
# Count the blocking ones on your own page
curl -sL --compressed -A 'Mozilla/5.0' https://example.com/ \
| sed -n '1,/<\/head>/p' \
| grep -o '<link[^>]*stylesheet[^>]*>' \
| grep -cv 'media="print"'We did not measure how long any of this took. No timing, no waterfall, no rendering. A blocking stylesheet on a fast CDN with a warm cache costs almost nothing, and this crawl cannot tell that case apart from the expensive one.
Render blocking css: 228 head stylesheets, and no media attribute anywhere that would let them through
Of 285 external stylesheets, 228 sit in the head. Every one of the 285 declares either nothing at all or all, which are the same thing.
| What we counted | Total | Sites |
|---|---|---|
| External stylesheets | 285 | 21 of 26 |
— in <head> | 228 | 21 |
— in <body> | 57 | 4 |
media absent | 226 | — |
media="all" | 59 | — |
media="print" | 0 | 0 |
blocking="render" | 0 | 0 |
rel="preload" as="style" | 40 | 5 |
The spread is wide. The median site ships four stylesheets; The New York Times ships 69, Linear 54, GitHub 41. At the other end, Figma and Hacker News ship one each. Linear is the extreme case for blocking specifically: all 54 of its stylesheets sit in the head, and it also inlines 250,218 characters of CSS on top of them.
The trick everyone recommends is used by zero of 26 sites
The standard advice for a stylesheet you do not need immediately is to give it media="print" and an onload handler that flips the media back to all once it has arrived. The browser still fetches it, at low priority, and never waits for it.
Our first pass found eight stylesheets with an onload attribute, all on slack.com, and the draft of this article said one site in 26 defers its CSS. Then we went back to the saved bytes. Slack's handler reads window._cdn ? _cdn.ok(this, arguments) : null — a CDN success callback with an error twin next to it. It never touches media. Those eight sheets block like all the others, and the true count is zero.
Every site in this sample either waits for its CSS or ships it inside the document. Nobody in this sample splits the difference.
Five sites take the second route. They send no external stylesheet at all and put every rule in <style> blocks, which cannot block on a network request because there is no request.
| Site | Inline chars | Blocks |
|---|---|---|
www.framer.com | 511,770 | 7 |
www.wired.com | 398,543 | 5 |
www.shopify.com | 245,133 | 2 |
www.bbc.com | 88,350 | 3 |
www.wikipedia.org | 60,382 | 3 |
That is a trade, not a free win: those bytes are in the HTML on every single page load, and they cannot be cached separately. Across the whole sample, 155 inline blocks hold 2,075,948 characters, with a per-site median of 13,517. Five sites go the other way and inline nothing at all: nextjs.org, stripe.com, slack.com, supabase.com and news.ycombinator.com.
57 stylesheets sit in the body, and 43 belong to one video player
A stylesheet in the body is legal. MDN: "the stylesheet link type is body-ok, and therefore <link rel="stylesheet"> is permitted in the body." By the same reference it is also outside the set that can block rendering, since only head links can do that.
Four sites put stylesheets there. The New York Times has 43, and they are not scattered — every one we sampled from the saved bytes belongs to the same video player bundle, betamax, with filenames like player-0.3.28-gTxBzUvg.css. GitHub has 11, Webflow 2, Railway 1. The New York Times body begins 202,375 characters into the document, so those 43 requests are discovered late by definition.
What we cannot tell you is whether that placement was a performance decision or just where the component happened to render. Both produce identical markup, and we did not ask anyone.
What this means for you
The number worth acting on is not 285. It is however many stylesheets sit in your own head, because each one is a network round trip that happens before the first pixel.
- Count them first. One command, above, and the answer is usually smaller than you feared or much larger than you expected
- If a sheet is genuinely not needed for the first screen, give it
media="print"plus an onload that restoresall. Zero sites here do it, which means it is either harder than it looks or less useful than it sounds - Do not inline your whole stylesheet because five large sites do. Framer's 511,770 characters ride along on every page load and never hit a browser cache
- Do not assume
rel="preload" as="style"removes the block. It changes fetch priority; the stylesheet link still waits
Whether any of this is worth your afternoon depends on what Google actually says it does with speed, which we worked through in does page speed affect seo. The script half of the same head was counted in async vs defer on 27 homepages, and the connection-level hints in 650 resource hints across 27 homepages. To see what an engine receives from your page before any stylesheet is applied, see how QueryWin works.
Common questions
How did you measure this?
One request per homepage on 2026-08-27 with a browser user agent, bodies written to disk, link and style elements read by an HTML parser that tracked head-versus-body position, and every published number recomputed from the saved files.
What counts as render blocking css?
A <link rel="stylesheet"> in the head, discovered during parsing, with a media attribute that matches the current device. MDN states it as the default behaviour, and adds that a link inserted later by script needs blocking="render" to block at all.
Does media="print" really stop the block?
It stops the wait, not the download. The browser fetches the file at a lower priority and does not hold rendering for it, and the onload handler then switches the media value so the rules apply. No site in this sample uses it, so we have 26 data points and no working example.
Is inlining CSS better than linking it?
For the first paint on a first visit, yes, because there is no second request. For every visit after that, no, because the bytes cannot be cached on their own and arrive again with the HTML. Five sites here picked the first trade-off and five picked the opposite.
Do stylesheets in the body slow anything down?
Not by the definition MDN gives, since only head links can block rendering. They are still 57 requests that are found late in the document, and in this sample 43 of them belong to a single video player.
