Our public site ships two stylesheets on every page: a 4,114 byte file with four font rules, and a 103,484 byte Tailwind build with 1,250 rules, of which the median page matches 213.

Today I blocked both and reloaded. DevTools, Network tab, right click a request, Block request URL. You can do the same on any page of ours in about ten seconds, which is the point of this post: it is the cheapest structural review of a site that exists.

What survives 

/features with CSS without elements in body 261 261 visible elements 236 236 document height 5,478 px 4,227 px innerText lines 120 98 document.styleSheets.length 2 2 rules in them 100 + 1250 0 + 0

The stylesheets are still there. A blocked request leaves an empty CSSStyleSheet object attached to the document, which is a detail worth knowing if you ever test for "did my CSS load" by counting sheets rather than rules.

Everything else is intact in the way that matters: one h1, the section headings in order, the breadcrumb rendered as a numbered list, the links as links, the buttons as buttons. The page is 23 per cent shorter because padding, gaps and line heights are gone, not because anything is missing.

The innerText line count drops from 120 to 98 because inline runs stop being separated. The header navigation reads:

PubTrivia FeaturesSolutionsPricingResources Sign inGet started

That is not a bug in the markup, it is what flex gaps were doing. But it is a good reminder that whitespace between links is a visual property and a screen reader never had it either.

What changes

  • Type. The h1 computes to 32 px, weight 700, in Times. All 13 @font-face rules live in the small blocked file, so the family never resolves and the UA default serif takes over. The two woff2 files are downloaded anyway, 23,108 and 29,288 bytes of them, because the preload hints for them are <link> tags in the HTML rather than CSS. Chrome then logs the complaint you would hope for: 
The resource .../797e433ab948586e-s.p...woff2 was preloaded using link preload but not used within a few seconds from the window's load event.

52 KB of fonts fetched and dropped on the floor is a neat illustration of how independent preloading is from the thing that would have used it.

  • Icons and the logo keep their size. The 5 inline SVGs on the page still render at 24x24 and the header logo at 26x26, because both carry width and height attributes rather than relying on utility classes. Images and icons that are sized only in CSS are the ones that explode to their intrinsic size in this test, and ours do not.
  • The decorative wordmark becomes content. The footer carries a large "PubTrivia" wordmark that normally sits at 5 per cent opacity as a background flourish. Without CSS it computes to opacity: 1 and renders as ordinary 18 px text at the bottom of the page. It is aria-hidden="true", so a screen reader was always skipping it, but a CSS-less browser is not.
  • <html class="dark"> stops meaning anything. The class is still applied, because a blocking script applies it before paint, but the 607 byte rule that defines the dark palette is in the file that did not load.

That last one is the pair to something I wrote last week: with JavaScript off, our dark site renders light, because the class never gets added. With CSS off, the class is added and there is nothing for it to select. The design lives in exactly one file and one class name, and either half of that is a single point of failure.

I cannot tell you what colours you will see, because the browser profile I measure with has forced dark mode on, which repainted the page in its own greys no matter what I emulated. That is itself the honest finding: with our stylesheet gone, the colours are whatever the user agent decides, and different readers will get different answers.

The tool still works

The round planner with both stylesheets blocked: the selects and number inputs render as native controls, the page is 3,249 px instead of 3,815, and pressing "Add a round" still recomputes the running order from 1 hr 51 min to 2 hr 04 min. None of the arithmetic was ever in the CSS, and the controls are real <select> and <input type="number"> elements rather than divs with click handlers.

That is the test I actually wanted to run. A tool built out of styled divs is unusable without its stylesheet. A tool built out of form controls degrades to something ugly that works.

The one page whose reading order depends on CSS

A CSS-less render is also a cheap way to check whether your visual order and your DOM order agree, because without CSS there is only one order left.

Across all 79 pages in our sitemap, the markup contains exactly one order-first and exactly one flex-row-reverse, and both are on the homepage:

order-first col-span-2 ... @3xl:order-none @3xl:col-span-1 flex flex-col gap-8 md:gap-12 items-center md:flex-row-reverse

So on 78 of 79 pages, what a keyboard user tabs through and what a screen reader reads is exactly what the eye sees. On the homepage, two elements swap position above a breakpoint, which is worth knowing about rather than worth fixing.

Also visible in this census: 277 absolutely positioned elements across the site and 155 fixed ones, two per page, being the sticky header wrapper and the toast region that no public page ever uses.

Check it yourself

  1. Open any page, for example /features or /tools/round-planner.
  2. DevTools, Network tab, filter by CSS, right click each of the two files, Block request URL.
  3. Reload.

Then read the page top to bottom. If the order still makes sense, your headings are headings and your buttons are buttons, the markup is doing its job. If something important vanishes, or a decorative element suddenly becomes the loudest thing on the page, that is a thing a screen reader or a text-only client may already be seeing.