Open Chrome DevTools on your WordPress site. Network tab. Filter by CSS. Reload. If you’re seeing 400KB+ across 8 to 15 stylesheet requests, you’re not unusual — you’re average. You’re also shipping 60% to 85% of CSS that no page on your site actually uses.
This is the silent tax on every WordPress site running a page builder, a theme, and a handful of plugins. Each one ships its own stylesheet covering every possible widget that could exist anywhere on the site. The browser downloads all of it, parses all of it, and uses a tiny fraction.
How to actually audit your CSS bundle
Chrome DevTools has a built-in tool that nobody uses. Open DevTools, hit Ctrl+Shift+P (Cmd+Shift+P on Mac), type “Coverage”, select “Show Coverage.” A new tab appears. Hit the reload icon inside it. Wait for the page to load. You’ll see every CSS and JS file on the page with a red/green bar showing exactly how much of each file is actually used by the rendered page.
Numbers you’ll typically see on a stock WordPress + Elementor + WooCommerce build:
- Elementor frontend.css — around 150KB, ~80% unused on any given page
- Theme style.css — 80 to 200KB, ~70% unused
- WooCommerce styles — 90KB across 3 files, 100% unused on non-shop pages
- Plugin stylesheets — 5 to 12 separate files, each 5 to 40KB, mostly unused per page
- Google Fonts — 30 to 60KB, often loading weights the site never uses
Add it up and you’re routinely north of 400KB of CSS for a page that needs roughly 60KB to render correctly.
Why this matters for PageSpeed
CSS is render-blocking by default. The browser won’t paint until every stylesheet in the head is downloaded and parsed. On a 4G connection in suburban New Jersey, 400KB of CSS adds 600 to 900ms to First Contentful Paint — enough to drop mobile PageSpeed from 92 to 71. LCP suffers because the hero waits behind CSS. CLS worsens because half-loaded stylesheets cause repaints. Google uses Core Web Vitals as a ranking signal, so a 30-point PageSpeed drop on your money pages is a revenue issue, not a cosmetic one.
The critical CSS + lazy CSS pattern
The fix is conceptually simple and has been the right answer for about eight years now: extract the CSS needed for above-the-fold rendering, inline it in the <head>, and defer everything else. Two phases:
- Critical CSS — usually 8 to 14KB of inline styles in the <head> covering the header, hero, and immediate viewport. Browser paints instantly, no network wait.
- Lazy CSS — everything else loaded with rel=”preload” + onload swap, or simply moved to the bottom of the page. Browser fetches it without blocking render.
FlyingPress, WP Rocket, and Perfmatters automate this. But the harder problem is the lazy half — 400KB of mostly-unused CSS still sitting there. The real win is removing CSS that no page actually uses.
How to actually remove unused CSS
Three approaches that work, ranked by effort and payoff:
- Per-page unused CSS removal (FlyingPress, WP Rocket): scans each URL and serves a slimmed stylesheet per template. 30-50% reduction without code changes.
- Dequeue plugin stylesheets on pages that don’t use them: a 20-line snippet that dequeues WooCommerce CSS on non-shop pages alone routinely saves 90KB. Same pattern for Contact Form 7, Elementor on FSE-rendered pages, etc.
- Drop the page builder where it isn’t needed: blog posts and basic content pages rarely need Elementor’s full payload. Native Gutenberg blocks ship a fraction of the CSS. Often the highest-impact change, and the hardest one to convince a site owner to make.
Real PageSpeed lifts
On a recent Bergen County professional services site we audited, the CSS bundle was 487KB across 11 files. After per-page unused CSS removal plus dequeuing stranded WooCommerce styles (the site didn’t even sell anything), CSS dropped to 71KB. Mobile PageSpeed went from 68 to 94. LCP from 3.1s to 1.4s. No design changes. Just unshipping what was never used.
How AJD handles this
Every site we audit gets the DevTools Coverage scan as the first step. We chart the CSS bundle by file, flag the heavy unused stylesheets, and choose the right tool for the job — usually FlyingPress for the automation layer plus a custom snippet to dequeue strays plugin by plugin. We don’t recommend WP Rocket + Perfmatters + Asset CleanUp stacked together; that’s three plugins doing the same job and they fight each other. Whether you work with us or not, run the Coverage scan on your own site this week. If you see a stylesheet showing 90%+ red, that’s $0 of value shipping at the cost of a slower site and a worse search ranking.
Want us to audit your CSS bundle and quote a fix? Book Free Discovery Call →
