How to Fix Unused CSS and Speed Up Your Pages
Your audit flagged unused CSS: your pages download stylesheet rules the current page never applies. That wastes bandwidth, adds render-blocking weight, and delays Largest Contentful Paint. The fix is to remove or defer CSS the page doesn't need, inline the critical above-the-fold styles, and stop shipping full framework stylesheets when you only use a fraction of their rules.
What this means
"Unused CSS" means the browser downloads and parses CSS rules that don't match any element on the page being rendered. Lighthouse measures this by comparing the CSS delivered against the rules actually used during load, then reports the wasted bytes under "Reduce unused CSS."
It usually traces to one of a few sources: a framework like Bootstrap loaded in full when the page uses a handful of classes; a page builder or theme (Elementor, Divi, WooCommerce) that enqueues its entire stylesheet on every page, including ones that don't use its components; third-party widgets (chat, sliders, cookie banners) shipping their own CSS; or stale rules left behind after a redesign.
It's a low-severity notice because it rarely breaks anything visually. The page works; it just carries dead weight in every request.
Why it matters
CSS is render-blocking by default. The browser won't paint the page until it has downloaded and parsed the stylesheets in the <head>. Every extra kilobyte of unused CSS pushes back First Contentful Paint and Largest Contentful Paint (LCP), and Google's "good" LCP threshold is under 2.5 seconds. Bigger stylesheets also mean more bytes to transfer on slow mobile connections and more CSS for low-end devices to parse.
Page speed is a real, if lightweight, ranking input through the Core Web Vitals side of page experience. The larger payoff is the field data Google collects from real Chrome users (CrUX), which feeds the Core Web Vitals report in Search Console. Faster rendering improves those numbers directly.
On the AI-crawler side, engines behind Google's AI Overviews, Perplexity, and ChatGPT's browsing fetch your HTML and generally don't render your full CSS the way a browser does, so unused stylesheet rules don't confuse them. Treat this as performance hygiene for human visitors and Core Web Vitals, not an AI-visibility task.
How to fix it
- 1
Measure which CSS is actually unused
Open Chrome DevTools, press Ctrl+Shift+P (Cmd+Shift+P on Mac), and run "Show Coverage." Reload the page; the Coverage tab shows each CSS and JS file with a red/green bar and the percentage of bytes never used. That tells you which stylesheets are the worst offenders so you don't optimize files that are already lean. Run it on each key template (homepage, blog post, product page), since unused CSS differs per page type.
- 2
Scope or split large framework stylesheets
If one global stylesheet loads everywhere, break it up so pages load only what they need. Tailwind handles this at build time when its content paths cover every template, since it only generates classes it finds in your markup. With Bootstrap, import only the SCSS partials you use instead of the full dist bundle. For hand-written CSS, move component styles (a carousel, a pricing table) into separate files and load them only on the templates that render those components.
- 3
Inline critical CSS and defer the rest
Extract the CSS needed to render above-the-fold content and inline it in a
<style>block in the<head>, then load the full stylesheet without blocking the first paint. Tools like the critical npm package, Penthouse, or beasties (the maintained successor to Critters) automate the extraction. This is the highest-impact change for LCP, because the page can paint immediately instead of waiting on the full CSS download. - 4
On WordPress, stop loading CSS where it isn't used
Most WordPress CSS bloat comes from plugins enqueuing styles site-wide. Use WP Rocket's "Remove Unused CSS," Perfmatters, or Asset CleanUp to unload specific stylesheets per page, for example dropping WooCommerce block CSS on non-shop pages or Contact Form 7 CSS on pages with no form. Disable the core block library CSS if your theme doesn't use Gutenberg blocks. Test each template after unloading, since removing a stylesheet a page actually needs will break its layout.
- 5
On closed platforms, cut what you inject
On Shopify, Wix, and Squarespace you can't run a build-time purge, but you can reduce added weight. On Shopify, audit installed apps (each often injects its own CSS on every page), remove ones you no longer use, and pick a lean, well-coded theme. Avoid pasting large third-party CSS libraries into custom code. On Wix and Squarespace you have little control over the platform's own CSS, so focus on not adding heavy custom styles, embeds, or unused widgets.
- 6
Re-audit and confirm the gain
After removing or deferring CSS, re-run the Coverage tool and a fresh Lighthouse or PageSpeed Insights test, and compare LCP and total CSS transfer size before and after. Check for visual regressions across breakpoints and templates, since aggressive removal is the most common cause of broken layouts. If a tool auto-generated critical CSS, spot-check pages with dynamic or personalized content where the critical path may differ.
Example
<head>
<!-- 1. Critical above-the-fold CSS, inlined so the page paints immediately -->
<style>
body { margin: 0; font-family: system-ui, sans-serif; }
.hero { min-height: 60vh; display: flex; align-items: center; }
/* ...only the rules needed for the first viewport... */
</style>
<!-- 2. Full stylesheet, loaded without blocking render -->
<link rel="preload" href="/css/main.css" as="style"
onload="this.onload=null;this.rel='stylesheet'">
<noscript><link rel="stylesheet" href="/css/main.css"></noscript>
</head>Inline the critical above-the-fold CSS, then load the full stylesheet without blocking render. The rel="preload" with onload fetches the CSS at a low priority and swaps it to a stylesheet once it arrives; the <noscript> fallback covers users with JavaScript disabled.
Platform-specific steps
Enable "Remove Unused CSS" in WP Rocket, or use Perfmatters or Asset CleanUp to unload specific plugin and theme stylesheets on pages that don't use them (e.g. WooCommerce block CSS off non-shop pages, Contact Form 7 CSS off pages with no form). Disable the core block library CSS if your theme doesn't use Gutenberg blocks. Test each template after unloading, since removing a needed stylesheet breaks layout.
With Tailwind, make sure its content paths cover every template so only the classes you actually use get generated. With Bootstrap, import only the SCSS partials you use rather than the full dist bundle. Add a critical-CSS step (critical, Penthouse, or beasties) to your build to inline above-the-fold styles and defer the rest.
You can't run a build-time purge, so reduce injected CSS instead: remove apps you no longer use (each often adds its own stylesheet site-wide), pick a lean, well-coded theme, and avoid pasting large third-party CSS libraries into theme.liquid or custom sections. Keep custom CSS in the theme's asset files rather than many scattered inline blocks.
You have limited control over the platform's own CSS, so focus on what you can change: avoid heavy custom CSS, third-party embeds, and unused widgets, and remove any custom code blocks you no longer need. Lean on the platform's built-in performance rather than layering in extra stylesheets.
Use CSS Modules or another component-scoped approach so each route ships only its own CSS, and code-split styles by route. Next.js can inline critical CSS via its experimental optimizeCss option (which uses beasties under the hood). If you're behind Cloudflare, note that its minification shrinks file size but won't remove unused rules, so still purge at the build level.
Frequently asked
It won't get your page penalized, which is why it's a low-severity notice. But it inflates render-blocking weight and slows LCP, and Core Web Vitals are a real (if minor) ranking signal. If your PageSpeed score is already strong and LCP is under 2.5s, this is low priority. If you're fighting slow load times, cutting unused CSS is one of the easier wins.
Use the Coverage tab in Chrome DevTools: press Ctrl+Shift+P, run "Show Coverage," then reload. It reports the exact percentage and byte count of unused CSS per file. Lighthouse and PageSpeed Insights also list "Reduce unused CSS" under Opportunities with estimated potential savings in kilobytes.
It can, if you remove rules used by states you didn't test: hover, focus, mobile breakpoints, or elements injected by JavaScript. Coverage tools only mark what was used during that one page load, so they miss conditional styles. Test across breakpoints and interactions after purging, and prefer per-page unloading over deleting global rules outright.
No. Inline only the critical, above-the-fold CSS, then load the rest as an external, deferred stylesheet. Inlining everything bloats your HTML, stops the browser from caching CSS across pages, and makes every page heavier. The goal is a fast first paint, not zero external stylesheets.
Not directly. AI crawlers parse your HTML and text rather than fully rendering CSS, so extra stylesheet rules don't confuse them. The benefit of fixing unused CSS is faster loads for human visitors and better Core Web Vitals. For AI engines, focus on clean semantic HTML and structured data instead.
Does your site have this issue?
Run a free, AI-powered audit and we’ll flag this and 150+ other checks in about a minute. No signup.