How to Identify and Reduce Unused CSS

How do you identify and reduce unused CSS?

You identify unused CSS with the Chrome DevTools Coverage tab and Lighthouse, then reduce it by removing dead rules, splitting stylesheets, and inlining only the critical CSS a page needs. Unused CSS matters because stylesheets are render-blocking by default: the browser has to download and parse your CSS before it can paint anything on screen (Chrome). Every kilobyte of rules a page never uses is weight the browser carries for nothing.

Key Takeaways

• CSS is render-blocking, so the browser can’t paint the page until it has downloaded and parsed your stylesheets, which delays Largest Contentful Paint (good is 2.5 seconds or less) (web.dev).
• The Chrome DevTools Coverage tab shows exactly how many bytes of CSS go unused on a page (Chrome for Developers).
• Lighthouse flags the problem with its “Reduce unused CSS” audit (Chrome).
• Tools like PurgeCSS strip selectors your markup never references, often cutting file size sharply (PurgeCSS).
• Critical CSS inlines the styles needed for the first view and defers the rest, so the page paints sooner (web.dev).

This guide walks through where unused CSS comes from, how to measure it, and the practical techniques for cutting it without breaking your design. It sits alongside our companion guide to reducing unused JavaScript, since the two are the most common sources of front-end bloat.

What is unused CSS and why does it exist?

Unused CSS is any rule in your stylesheets that no element on the page actually matches, so the browser downloads and parses it for no benefit. It builds up naturally over time, and most sites accumulate it without anyone noticing (Chrome). The common causes are predictable once you know to look for them.

CSS frameworks are the biggest culprit: pulling in all of Bootstrap or a large utility library ships thousands of rules when a page uses a handful. Old code is the next: styles for features and components that were removed but whose CSS was never cleaned up. Add to that single global stylesheets shared across every page, where each page loads the styles for all the others, and the dead weight grows quietly with every release.

How does unused CSS hurt performance?

Unused CSS hurts performance mainly by delaying the first paint, because CSS is render-blocking and the browser must process all of it before showing content (Chrome). Larger files take longer to download, and a bigger stylesheet also takes longer for the browser to parse and build into the style rules it applies.

The effect shows up in Core Web Vitals, particularly Largest Contentful Paint, where good is 2.5 seconds or less at the 75th percentile (web.dev). A bloated stylesheet sitting in the critical path pushes that moment later. On slower connections and mid-range mobile devices the gap widens, because both the download and the parse cost more there. Trimming unused CSS is one of the cleaner wins available, covered more broadly in our Core Web Vitals guide.

How do you find unused CSS with Chrome DevTools?

Open the Coverage tab in Chrome DevTools, which records how much of each CSS (and JavaScript) file the page actually uses and reports the unused bytes in red (Chrome for Developers). It’s the fastest way to see the scale of the problem on a real page rather than guessing.

To use it, open DevTools, press the Command or Control plus Shift plus P shortcut to open the command menu, type “Coverage,” and choose “Show Coverage.” Click the reload button in the Coverage panel to record, then interact with the page. Each file gets a usage bar: the red portion is CSS that didn’t apply to anything during your session. One caveat worth remembering is that coverage is per session, so a rule marked unused on the homepage may be used elsewhere, which is why you measure across the pages and interactions that matter before deleting anything.

What tools and audits help measure it?

Beyond DevTools, Lighthouse includes a “Reduce unused CSS” audit that estimates the wasted bytes and the load-time saving from removing them (Chrome). Lighthouse is built into Chrome DevTools and also runs in PageSpeed Insights, so you can get the figure as part of a wider performance report rather than a one-off check.

For automated removal, a small set of tools does the heavy lifting:

Modern utility frameworks like Tailwind CSS build this in: their tooling scans your templates and generates only the classes you actually use, so the shipped file is a fraction of the full set. If you’re on a framework, check whether its purge or content-scanning step is configured before reaching for a separate tool.

How do you reduce unused CSS?

You reduce unused CSS by combining automated purging with a few structural habits, rather than relying on any single fix. The biggest lever is removing dead rules at build time, but how you write and load CSS matters just as much for keeping it lean. The techniques below work together.

• Run a purge tool. PurgeCSS, or your framework’s built-in purging, strips selectors your templates never use, which often cuts framework CSS dramatically (PurgeCSS).
• Write modular CSS. Scope styles to components so it’s obvious what each rule belongs to, which makes dead code easier to spot and remove.
• Load CSS conditionally. Split non-critical styles into separate files and load them only on the pages or interactions that need them, rather than shipping one global stylesheet everywhere.
• Minify and compress. Minification removes whitespace and comments, and serving CSS with compression (such as Brotli or gzip) shrinks the transfer further.
• Avoid pulling in whole libraries. Import only the parts you use instead of an entire framework when you need a few components.

What is critical CSS and how does it help?

Critical CSS is the minimal set of styles needed to render the content visible in the first screenful, which you inline directly in the HTML so the page can paint without waiting for an external stylesheet (web.dev). The rest of your CSS then loads without blocking that first paint.

The pattern is to extract the above-the-fold rules, inline them in a <style> block in the <head>, and load the full stylesheet asynchronously so it doesn’t hold up rendering:

<head>
  <style>/* critical above-the-fold CSS inlined here */</style>
  <link rel="preload" href="/styles.css" as="style" onload="this.rel='stylesheet'">
</head>

This gives the browser what it needs to draw the first view immediately, while the complete stylesheet arrives in the background. Tools can extract critical CSS automatically as part of a build, and it pairs well with the other render-blocking fixes in our guide to eliminating render-blocking resources.

How does CSS @layer help manage specificity?

CSS cascade layers, declared with the @layer rule, let you group styles into explicitly ordered layers so the cascade follows your layer order instead of selector specificity (MDN). This matters for unused CSS because specificity battles are a hidden source of bloat: when a later rule won’t override an earlier one, developers pile on ever more specific selectors and !important flags, and that defensive code rarely gets cleaned up.

With layers, you declare the order once and a rule in a later layer always wins over an earlier one, regardless of how specific each selector is. A typical setup separates resets, base styles, components, and utilities:

@layer reset, base, components, utilities;
@layer base {
  a { color: #0b5; }
}
@layer utilities {
  .link-muted { color: #888; }
}

Because utilities is declared after base, .link-muted wins even though it is no more specific than the element selector. Organising CSS this way keeps overrides predictable, which means fewer redundant rules accumulate and the ones that are genuinely dead are easier to spot and remove.

Should you use CSS Modules or BEM for component-scoped styles?

Both CSS Modules and BEM scope styles to a component so rules don’t leak across the page, but they work differently: BEM is a manual naming convention, while CSS Modules generate unique class names automatically at build time (CSS Modules). Scoping matters for unused CSS because when every rule clearly belongs to one component, dead styles become obvious the moment that component is removed.

BEM (Block, Element, Modifier) structures class names like .card, .card__title, and .card--featured, making the relationship between markup and styles explicit without any tooling (BEM). It works anywhere, but it relies on discipline. CSS Modules instead rewrite your class names to be locally unique during the build, so two components can both use .title without colliding, and a styling file that no component imports is straightforward to identify and delete. If you already use a build step or a component framework, CSS Modules remove the naming guesswork; if you don’t, BEM gives you most of the benefit with nothing to install.

How does PostCSS automate CSS processing and purging?

PostCSS is a tool that transforms your CSS with JavaScript plugins, letting you chain steps like autoprefixing, minification, and unused-rule removal into a single automated build (PostCSS). It is the practical way to make the techniques in this guide run on every deploy instead of by hand.

The most relevant plugin here is the PostCSS build of PurgeCSS, which scans your templates and strips selectors your markup never references as part of the pipeline (PurgeCSS). A common chain runs Autoprefixer for vendor prefixes, @fullhuman/postcss-purgecss to remove unused rules, and cssnano to minify what’s left, so the stylesheet that ships is both lean and optimised without a separate manual step. Wiring this into your build is what stops unused CSS creeping back after you’ve cleaned it once, and it pairs naturally with the purge tools covered above.

How do you keep CSS clean over time?

Keeping CSS clean is mostly about process, because unused rules accumulate fastest when no one owns the stylesheet. Treating CSS as something to maintain, not just add to, is what stops the bloat returning after you’ve cleaned it once. A few habits do most of the work:

Review your CSS on a regular schedule, running the Coverage tab and Lighthouse so dead rules don’t pile up unnoticed. Write modular, component-scoped styles so each rule has an obvious home and removing a feature means removing its CSS too. Be deliberate about libraries, pulling in only what you use. Document non-obvious styles so a teammate doesn’t leave an “is this still needed?” rule in place out of caution. On a team, agree on naming and structure conventions so everyone adds CSS the same way. None of this is dramatic, but together it keeps the problem from coming back.