Skip to main content
Metrics type: Supporting MetricsCategory: Website Performance

At a glance

CSS bytes downloaded but not applied to the rendered page, ranked per stylesheet. Lighthouse’s Coverage analysis identifies which CSS rules never matched any element during the audit; the bytes those rules occupy are “unused CSS”. Brands routinely ship 30-60 percent of their CSS bundle on every page with only 40-70 percent actually applied. Smaller impact than psi_unused_js but easier to fix, tree-shaking unused CSS is largely automatic with modern build tools.

Calculation

Calculated automatically from your Website Performance (PageSpeed + CrUX) data. See the At a glance summary above for what the metric tracks and the worked example below for a typical reading.

Worked example

A UK-based BigCommerce fashion store homepage audit, mobile, Wednesday 15 May 26. What the ranked list is telling us:
  1. 63 percent of all CSS shipped is unused on this page-load. Smaller proportion than the typical 66 percent unused JS but still a meaningful 128KB of dead bytes downloaded and parsed.
  2. Stencil theme bundle at 82KB unused (rank 1) is the dominant fix. Stencil themes ship rules for many use cases (blog templates, multi-language layouts, alternate skins, demo content) that the merchant doesn’t use. PurgeCSS during build scans the actual theme templates, removes unmatched rules, typically cuts 40-60 percent of theme CSS bundle size.
  3. Klaviyo popup CSS at 24KB unused (rank 2) is loaded synchronously on every page even though the popup fires only on certain triggers. Defer the load to when the popup is about to mount; saves 24KB on most page-loads where the popup never shows.
  4. Tidio chat at 16KB unused (rank 3) has similar pattern, chat widget styles loaded site-wide but only ~27 percent of rules apply on a typical page. Defer to post-load; the chat is invisible until hovered anyway.
  5. Web fonts CSS at 4KB unused (rank 4) is mostly applied. Tightening this is polish; not worth significant effort.
  6. Cookie consent at 2KB unused (rank 5) is acceptable. Skip.
  7. Cumulative impact post-fixes: PurgeCSS theme work (-50KB) + Klaviyo defer (-24KB) + Tidio defer (-16KB) = roughly 90KB reduction. Total CSS bytes drop from 204KB to ~115KB, with most CSS deferred to post-load. Page-weight reduction is meaningful; render-blocking impact is the bigger win because deferred CSS no longer blocks first paint.
The diagnostic flow:
  1. Read top 3 entries. Theme bundle is almost always #1; third-party widget styles next.
  2. Verify in DevTools Coverage tab. Confirms unused-CSS estimates and shows exactly which rules never fired.
  3. Apply build-time tree-shaking (PurgeCSS, UnusedCSS) for first-party CSS.
  4. Defer third-party CSS loads that don’t need to render at first paint.
Rapid-response playbook:

Sibling cards merchants should reference together

Reconciling against the vendor’s own dashboard

Where to look:
  • PageSpeed Insights, “Reduce unused CSS” opportunity in the Diagnostics section.
  • Chrome DevTools → Coverage tab, line-level visibility of which CSS rules matched DOM elements; the most useful diagnostic tool.
  • PurgeCSS / UnusedCSS / CleanCSS, build-time tools that automate the cleanup.
Why the Vortex IQ unused-CSS may differ from PSI / DevTools: Cross-connector reconciliation: primarily internal (with psi_render_blocking, psi_total_weight, psi_third_party_cost). Quick rule for support tickets: if a merchant says “I removed unused rules from my CSS but Vortex IQ still shows the same unused bytes”, the most common cause is build/bundle caching, the published bundle still contains the old rules. Verify the deployed CSS file matches the source.

Known limitations / merchant FAQs

Why does my theme have so much unused CSS? Themes ship rules for many use cases. Stencil themes default to broad styling for blog support, multi-language layouts, alternate skins, demo content. Most merchants use a small subset; the rest is dead weight per page. Industry-typical: 30-60 percent unused CSS in untreated theme bundles. Will PurgeCSS break my dynamic content? If configured correctly, no. PurgeCSS scans your templates to identify which selectors are actually used. The risk comes from dynamic content: rules that only apply when JS adds classes at runtime can be incorrectly purged. Configure PurgeCSS’s “safelist” with your dynamic class patterns to prevent this. Should I optimise unused CSS or unused JS first? JS first, almost always. JS has higher byte impact AND higher execution cost on slow devices. Tackle the JS optimisation work mature before turning to CSS; CSS-only optimisation is usually a polish step, not a primary lever. My theme bundle has 130KB of CSS but Coverage tab shows 60KB used. Is the rest really safe to remove? Verify across multiple page types. The 60KB used on the homepage may not be the same 60KB used on PDPs or collections. Run Coverage tab on 5-7 representative pages and union the used rules, that’s the actual “in-use” set. Removing rules outside this set is safe. Will inline critical CSS hurt my performance? Slightly increases HTML size but saves a render-blocking CSS request. For most ecommerce sites the trade-off is positive: 15-25KB of inline critical CSS saves a 100-300ms render-blocking download. The inline cost is parsed before paint anyway, so no net cost. Can Vortex IQ remove unused CSS automatically? Read-only by design. The card identifies what’s unused; build pipeline tools (PurgeCSS, UnusedCSS) handle the actual removal. What about CSS-in-JS frameworks? Different optimisation pattern. CSS-in-JS frameworks (styled-components, Emotion, Tailwind JIT) generate CSS at runtime or build time only for components actually rendered. Unused-CSS is structurally lower for these frameworks; the optimisation work shifts to bundle splitting and tree-shaking the JS that generates the styles.

Tracked live in Vortex IQ Nerve Centre

Unused CSS is one of hundreds of KPI pulses Vortex IQ tracks across Website Performance (PageSpeed + CrUX) and 70+ other ecommerce connectors. Nerve Centre runs the detection layer; Vortex Mind investigates the cause when something moves; Ask Viq lets you interrogate any number in plain English. Start for free or book a demo to see this metric running on your own data.