Short answer: Unused CSS is style code that a page downloads but never applies. Because stylesheets block rendering, large unused CSS delays the first paint and Largest Contentful Paint, especially on phones. Find it with the Coverage panel in Chrome DevTools across several page types, then remove it by loading plugin and component styles only where they are needed, purging unused rules at build time with a safelist, and inlining critical CSS. Always test interactive states before shipping.
Why unused CSS slows pages down
Browsers will not draw a page until they have downloaded and processed the stylesheets linked in the head. That is sensible, because showing unstyled content and then restyling it would look broken. The downside is that every kilobyte of CSS in those files delays the first paint, whether it is used on that page or not.
Three costs add up:
- Download time. On a slow mobile connection, a few hundred kilobytes of CSS take noticeable time even when compressed.
- Parsing and style calculation. The browser has to parse every rule and match selectors against the page, which costs CPU time on slower phones.
- Render blocking. Nothing appears until the blocking stylesheets are ready, which pushes back First Contentful Paint and Largest Contentful Paint.
Lighthouse and PageSpeed Insights report this as “Reduce unused CSS”, with the estimated savings per stylesheet. It usually sits next to “Eliminate render-blocking resources”, because both describe the same bottleneck. Our guide on eliminating render-blocking resources covers the loading side; this article focuses on the size side.
Where unused CSS comes from
Very few developers write CSS that is never used. It accumulates:
- Themes built for every possible site. Multipurpose themes include styles for sliders, portfolios, shops and dozens of layouts, and load them all on every page.
- Plugins that load styles everywhere. A contact form, gallery or booking plugin adds its stylesheet to every page, although it is used on one.
- Page builders. Builders ship large shared stylesheets for all their widgets, plus per-page styles. See whether page builders slow down WordPress.
- CSS frameworks. Including a full framework build for a handful of classes brings in thousands of unused rules.
- Old code. Styles for removed sections, retired campaigns and previous designs stay because nobody is sure they are safe to delete.
The cause matters because it decides the fix. Removing unused rules from a theme file helps a little; stopping a plugin from loading its whole stylesheet on every page may help much more.
How to measure unused CSS
Start with evidence rather than guesses. The Coverage panel in Chrome DevTools shows exactly how much of each CSS and JavaScript file was used during a page load:
- Open the page in Chrome, open DevTools, press Ctrl+Shift+P (Cmd+Shift+P on Mac) and run “Show Coverage”.
- Click the reload button in the Coverage panel to record the page load.
- Sort by “Unused bytes”. Each CSS file shows its total size and the share that was not applied.
- Click a file to see used lines marked in one colour and unused lines in another.
- Interact with the page: open menus, hover over buttons, submit a form with errors. Coverage updates as more rules are used.
Then repeat on other templates: home page, a blog post, a product page, the contact page and the checkout. A rule unused on the home page may be essential on the checkout. The goal is a picture of which files are needed where, not a list of rules to delete blindly.
Safe ways to reduce unused CSS
These approaches are listed roughly from safest to riskiest.
1. Load styles only on pages that need them
If a plugin’s stylesheet is used only on the contact page, it should load only there. Many plugins offer a setting for this. On WordPress, asset management plugins and some performance plugins let you disable specific stylesheets per page or per post type. This removes whole files, carries little risk when tested, and often gives the biggest win.
2. Remove what you no longer use
Deactivate plugins that are no longer needed, remove unused widgets and features from the theme, and replace a heavy component with a lighter one. Removing a feature removes its styles and scripts at the same time.
3. Split CSS by template
Developers can split one large stylesheet into a small shared file plus separate files for the shop, blog and landing pages. Each page downloads only the shared styles and its own template file.
4. Purge unused rules at build time
Tools such as PurgeCSS scan templates for class names and remove rules that never match. Utility-first frameworks generate only the classes you use. This is effective but needs a safelist for classes added by JavaScript, content from the CMS, and third-party widgets.
5. Inline critical CSS and defer the rest
Inlining the small set of rules needed for the first screen and loading the full stylesheet without blocking rendering speeds up the first paint even when the total CSS stays the same. The trade-offs are explained in critical CSS explained.
Unused CSS on WordPress sites
WordPress sites are the most common place to find large amounts of unused CSS, because every plugin and theme adds its own files. A practical order of work looks like this:
- List the stylesheets. View the page source or the Network panel filtered by CSS and note every file, together with the plugin or theme folder it comes from.
- Match files to features. For each file, ask which pages actually use that feature. A slider plugin used only on the home page, a form plugin used only on the contact page and a shop plugin used only on shop pages are typical candidates.
- Check the block editor styles. Sites that do not use the block editor on the front end may still load the block library stylesheet. Themes built for the block editor, on the other hand, need it, so test before removing.
- Unload per page. Use the plugin’s own setting if it has one; otherwise an asset manager can disable a file on pages where it is not needed.
- Retest. Run Coverage again and compare total CSS bytes and unused bytes with your first measurement.
This approach removes whole files rather than rewriting rules, which is why it rarely breaks layouts and is easy to undo if something looks wrong.
What breaks when unused CSS is removed
Automatic “remove unused CSS” features in optimisation plugins are popular because they are one click. They also cause many broken layouts. Typical casualties:
| What breaks | Why the tool missed it | How to protect it |
|---|---|---|
| Mobile menu, dropdowns, modals | Classes are added by JavaScript after a click | Safelist state classes such as “open” and “active” |
| Form error and success messages | They appear only after submission | Test forms with errors before and after |
| Hover and focus styles | Not triggered during analysis | Check keyboard navigation and focus outlines |
| Content added by editors later | New blocks use classes not present when purging | Keep block styles for all blocks editors may use |
| Cookie banners and chat widgets | Injected by third-party scripts | Exclude their stylesheets from optimisation |
After any change, clear all caches and test on a real phone and in a private window. Check the menu, a form submission, the cart, and at least one page of each template. Focus styles deserve special care: removing them hurts keyboard users and accessibility.
Common mistakes
- Chasing zero. Some unused CSS on each page is normal and harmless. Shared stylesheets that are cached after the first visit are often a good trade-off.
- Optimising only the home page. Test the pages where visitors actually convert.
- Stacking optimisation plugins. Two plugins both rewriting CSS lead to conflicts and hard-to-debug breakage.
- Ignoring the bigger costs. On many sites, images, fonts, third-party scripts and slow servers cost more than CSS. Fix the largest problem first.
- Forgetting minification and compression. Minifying and serving CSS with Gzip or Brotli is simple and safe. See what minifying really saves you.
How Site AI Audit helps
Site AI Audit includes Google PageSpeed measurements for mobile, with Core Web Vitals such as LCP and CLS, plus checks of server response time, compression and page weight. Findings are ranked by impact, so you can see whether stylesheets are a real bottleneck on your site or whether images, the server or scripts deserve attention first. After removing unused CSS, re-checking shows whether the change helped; re-checks and monitoring are part of the paid plans described on the pricing page.
Related reading
- How to Reduce Unused JavaScript and Speed Up Your Pages
- First Contentful Paint (FCP): What It Is and How to Improve It
- How to Find Which WordPress Plugin Is Slowing Your Site
The bottom line
Unused CSS delays rendering because browsers wait for stylesheets before drawing anything. Measure it with Coverage on several templates, stop loading plugin and component styles where they are not used, purge carefully with a safelist, and test interactive states before shipping. Aim for lean, not zero.
GYIK
What does “Reduce unused CSS” mean in PageSpeed Insights?
It means the page downloads stylesheets containing many rules that are not applied on that page. Because CSS blocks rendering, removing or deferring those rules can make content appear sooner.
Is it safe to use a “remove unused CSS” plugin feature?
It can work, but it often breaks menus, forms and styles added by JavaScript. Enable it on a staging copy first, safelist dynamic classes, and test every template and interactive element.
How much unused CSS is acceptable?
There is no fixed limit. Some unused CSS in a shared, cached stylesheet is normal. Focus on files where most of the content is unused on key pages and on stylesheets that block rendering.
Does unused CSS affect SEO?
Only indirectly. It can slow rendering and Core Web Vitals, which are part of page experience. Content relevance and quality matter far more for rankings than CSS size.
What is the difference between unused CSS and critical CSS?
Unused CSS is code a page never applies. Critical CSS is the small part needed to show the first screen, often inlined so the rest can load later without blocking rendering.



