If PageSpeed Insights flags your site with “Reduce unused CSS” (or “Remove unused CSS”), you’re not alone — it’s one of the most common warnings for WordPress sites, and one of the most misunderstood. Themes and page builders routinely load hundreds of kilobytes of CSS on every page, while a typical page actually uses only 20–30% of it. In this guide you’ll learn what the warning really means, how to fix it with plugins (WP Rocket, Perfmatters, FlyingPress, Asset CleanUp), how to do it manually with code, and — critically — how to avoid breaking your layout in the process.
What “Remove Unused CSS” Actually Means
When Chrome (and therefore PageSpeed Insights) analyzes your page, it compares every CSS rule that was loaded against the rules actually applied to elements on that specific page. Everything loaded but unused gets reported — usually with a breakdown per stylesheet:
| Typical offender | Typical size | Why it loads everywhere |
|---|---|---|
| Page builder CSS (Elementor, Divi, WPBakery) | 100–400 KB | One giant stylesheet for every possible widget |
| Theme styles (style.css + framework files) | 50–200 KB | Styles for page templates you’re not using |
| WooCommerce styles | 50–150 KB | Loaded on blog posts that have no shop elements |
| Slider/form/gallery plugins | 20–100 KB each | Enqueued sitewide “just in case” |
| Icon fonts (Font Awesome, Dashicons) | 30–100 KB | Full icon sets for a handful of icons |
Unused CSS hurts you three ways: it blocks rendering (the browser must download and parse CSS before painting), it increases Total Blocking Time on low-end phones, and it inflates your page weight. Fixing it directly improves FCP and LCP — two of the three Core Web Vitals.
Important nuance: “unused on this page” does not mean “unused on the site.” Your contact form styles are unused on blog posts but essential on the contact page. Every removal method below revolves around managing this tension.
Method 1: WP Rocket “Remove Unused CSS” (Easiest)
WP Rocket’s Remove Unused CSS feature is the safest one-click approach, because it doesn’t delete anything — it generates a new, used-only stylesheet per page and serves that instead:
- Go to Settings → WP Rocket → File Optimization
- Enable Remove Unused CSS (note: it’s mutually exclusive with “Load CSS asynchronously” — choose one)
- WP Rocket’s external service crawls your pages and generates optimized “used CSS” files in the background
- Clear cache and retest in PageSpeed Insights after a few minutes
When things break (they sometimes will): if some element loses its styling — an accordion, a popup, a hover effect — the used-CSS generator missed a dynamically-injected selector. Fix it by adding the missing selectors to the CSS safelist box in the same settings panel. Common candidates: classes added by JavaScript on interaction, cookie banner styles, and anything inside iframes. We compare WP Rocket against edge-caching alternatives in our Cloudflare APO vs WP Rocket comparison.
Method 2: Perfmatters Script Manager (Most Precise)
Perfmatters takes the opposite approach: instead of generating used CSS, it lets you disable entire stylesheets on pages where they’re not needed:
- Install Perfmatters, then enable Script Manager (Settings → Perfmatters → Assets)
- Visit any page while logged in and click Script Manager in the admin bar
- You’ll see every CSS/JS file loading on that page, grouped by plugin/theme
- For each stylesheet, choose: disable on this page, disable everywhere except…, or disable by post type / URL pattern / regex
Killer use case: disable WooCommerce styles (and scripts!) on all non-shop content — most blogs load 100+ KB of store CSS on articles that never show a product. Set WooCommerce assets to load only on shop, product, cart, and checkout templates. If your checkout itself is slow, see our guide on WooCommerce checkout speed and AJAX optimization.
Method 3: FlyingPress (Best of Both Worlds)
FlyingPress offers both approaches in one plugin: per-asset unloading and a “Remove Unused CSS” generator similar to WP Rocket’s, but processed faster and with a useful option to lazy-load the removed CSS instead of deleting it outright — a safety net that preserves styles for below-the-fold interactions while still unblocking the critical path.
Method 4: Asset CleanUp / Asset CleanUp Pro (Free Option)
The free Asset CleanUp plugin gives you Perfmatters-style per-page asset unloading at no cost: enable “Test Mode,” browse your pages as admin, and unload stylesheets where they’re unnecessary. The interface is less polished, and the Pro version is needed for some bulk/regex rules — but for budget-conscious sites it’s the best free path. For a broader look at caching/optimization plugins, check our tested roundup of the best WordPress cache plugins.
Method 5: Manual Removal with Code (For Developers)
If you want zero extra plugins, dequeue styles directly in your child theme’s functions.php. The key hooks: styles are registered with wp_enqueue_style(), and you remove them with wp_dequeue_style() + wp_deregister_style():
// Disable WooCommerce styles on non-shop pages
add_action( 'wp_enqueue_scripts', 'cvs_dequeue_unused_css', 99 );
function cvs_dequeue_unused_css() {
if ( function_exists( 'is_woocommerce' ) && ! is_woocommerce()
&& ! is_cart() && ! is_checkout() && ! is_account_page() ) {
wp_dequeue_style( 'woocommerce-general' );
wp_dequeue_style( 'woocommerce-layout' );
wp_dequeue_style( 'woocommerce-smallscreen' );
wp_dequeue_style( 'wc-blocks-style' );
}
}
// Remove Dashicons for logged-out visitors
add_action( 'wp_enqueue_scripts', 'cvs_remove_dashicons' );
function cvs_remove_dashicons() {
if ( ! is_user_logged_in() ) {
wp_deregister_style( 'dashicons' );
}
}
// Kill the block-library CSS on a classic-theme site
add_action( 'wp_enqueue_scripts', 'cvs_remove_gutenberg_css', 100 );
function cvs_remove_gutenberg_css() {
wp_dequeue_style( 'wp-block-library' );
wp_dequeue_style( 'wp-block-library-theme' );
wp_dequeue_style( 'global-styles' );
}To find the correct style handles, view your page source and look at stylesheet IDs — <link id='woocommerce-general-css'> means the handle is woocommerce-general (strip the -css suffix). The same dequeue technique works for JavaScript — see our companion guide on removing unused JavaScript in WordPress.
Finding what’s actually unused: Chrome DevTools Coverage
- Open DevTools (F12) → press
Ctrl+Shift+P→ type “Show Coverage” - Click the reload button in the Coverage panel
- Each CSS/JS file shows a red/green bar — red = unused bytes on this page
- Click a file to see exactly which rules are unused
⚠️ Interact with the page first (open menus, scroll, trigger popups) before reading the results — otherwise you’ll flag interactive styles as “unused” and break them later.
Comparison: Which Method Should You Choose?
| Method | Effort | Breaking risk | Best for |
|---|---|---|---|
| WP Rocket Remove Unused CSS | Minimal | Low–medium (fixable via safelist) | Most site owners; fastest result |
| Perfmatters Script Manager | Medium (per-page review) | Low (you choose exactly what loads) | WooCommerce + heavy plugin stacks |
| FlyingPress | Minimal–medium | Low (lazy-load safety net) | Those wanting both approaches |
| Asset CleanUp (free) | Medium | Low | Budget sites |
| Manual dequeue code | High | Depends on your care | Developers; plugin-minimal setups |
| PurgeCSS at build time | High (dev workflow) | Medium | Custom themes with a build pipeline |
The Golden Rules (So You Don’t Break Anything)
- Never delete — generate or conditionally unload. Used-CSS generators keep the original file intact; unloading is per-page and reversible.
- Test in incognito. Logged-in admins see extra styles (admin bar, editor) that visitors don’t get.
- Test interactions, not just the initial render: mobile menu, dropdowns, popups, forms, sliders, cookie banners, “load more” buttons.
- Safelist dynamically-added classes. Anything JavaScript injects (e.g.,
.active,.open,.is-visible) is invisible to static analysis. - Change one thing at a time and re-run PageSpeed — when something breaks, you’ll know what caused it.
- Don’t chase 100/100. Getting “unused CSS” under ~20–30 KB transferred is an excellent real-world result; the last kilobytes cost more than they’re worth.
Beyond Removal: Reduce CSS Weight at the Source
- Inline critical CSS for above-the-fold content and load the rest asynchronously (WP Rocket, FlyingPress, and Autoptimize can automate this).
- Replace icon fonts with inline SVGs — loading 90 KB of Font Awesome for five icons is pure waste.
- Audit your page builder widgets — Elementor/Divi let you disable unused widget styles; regenerate their CSS after changes.
- Fix images and fonts too — CSS is only one part of the LCP/CLS puzzle; see our guides on WordPress image optimization and eliminating CLS from web fonts and images.
Frequently Asked Questions
Does removing unused CSS improve Core Web Vitals?
Yes — primarily FCP and LCP, because large stylesheets are render-blocking. Reducing CSS payload by 100–300 KB typically improves LCP by several hundred milliseconds on mobile connections. It has little direct effect on INP (that’s a JavaScript metric) or CLS (that’s layout stability).
Will removing unused CSS break my site?
It can if done carelessly — typically dynamic elements (menus, popups, sliders) lose their styles because automated tools can’t see classes added by JavaScript. Use plugins with safelist options (WP Rocket), test all interactive elements after enabling, and roll back or safelist whatever breaks.
How do I remove unused CSS in WordPress without a plugin?
Use Chrome DevTools’ Coverage panel to identify unused files, then conditionally dequeue them in your child theme’s functions.php with wp_dequeue_style() (code examples above). For build-level optimization, PurgeCSS or UnCSS can strip unused selectors — but they require a development workflow and careful safelisting.
Is WP Rocket’s “Remove Unused CSS” better than “Load CSS asynchronously”?
They solve the same problem differently: Remove Unused CSS generates a minimal stylesheet per page (bigger payload reduction, occasional missing-selector issues), while asynchronous loading keeps full CSS but makes it non-render-blocking with critical CSS inlined. You can’t enable both — Remove Unused CSS usually yields better PageSpeed scores; async loading is the safer fallback if safelisting becomes whack-a-mole.
Why does PageSpeed still show the warning after I removed unused CSS?
Three common reasons: the cache wasn’t cleared (purge everything and retest), the warning now refers to different files (e.g., third-party CSS from fonts or embeds you can’t control), or the remaining unused portion is from your own inlined critical CSS — which is normal and acceptable.
Should I remove unused CSS on every page or just the homepage?
Every page template that matters for SEO. Google evaluates Core Web Vitals per-page (grouped by similar pages in CrUX data), so an optimized homepage with bloated blog posts still hurts your field data. Per-page used CSS (WP Rocket) handles this automatically; with Script Manager tools, review your top templates: home, single post, page, product, category.
What’s the difference between “Remove unused CSS” and “Minify CSS”?
Minification only removes whitespace and comments (maybe 10–20% savings) — every rule still loads. Removing unused CSS eliminates entire rules that the page never applies (often 60–80% savings). They’re complementary: remove first, minify what remains.
Tested on WordPress 6.x with current plugin versions as of August 2026. Always back up your site and test changes on staging before deploying to production.