Somewhere in your PageSpeed Insights results is advice to reduce unused CSS, next to your theme’s stylesheet and a couple of plugin files, with a claim that a large share of each one is never used on the page. That sounds like an easy win. Delete what is not used, and the page gets lighter. Then you find that the tool which does this automatically has removed the styles for your mobile menu, and the hamburger icon opens a list of plain blue links.
Unused CSS is a real cost, but “unused” in that report has a narrow meaning: not used on this page, in this state, at the moment the test looked. Most of the trouble comes from forgetting that.
Why your pages carry CSS they never use
CSS is written for a whole site, not for one page. A theme has to style every layout it might ever be asked to show: shop pages, archives, comments, sidebars, galleries, forms, buttons in six colours. Your home page uses a slice of that. The browser still has to download and read the whole file before it paints, which is what makes stylesheets one of the render-blocking files that hold up the first paint.
The usual sources on a WordPress site:
- Multipurpose themes that include styles for dozens of demo designs, even after you picked one.
- Page builders, which load CSS for their widgets and add-on packs. Some load styles for widgets you never placed.
- Plugins that load site-wide. A form plugin used on one contact page, a slider used on the home page, a gallery used on one post, all loading their CSS everywhere.
- The block library stylesheet, which classic themes often load in full even if your pages are built with something else.
- Years of custom CSS pasted into the Customizer for sections that no longer exist.
None of this is anyone’s fault in particular. It is the price of general-purpose tools. The question is how much of it you can cut safely.
Measure it yourself with the Coverage panel
The PageSpeed figure is a single snapshot of one page. You can see the same thing in more detail in Chrome on your own computer:
- Open the page in a private window so you are not logged in.
- Press F12 for DevTools. Bring up its command box with Ctrl+Shift+P on Windows or Cmd+Shift+P on a Mac, enter “coverage”, and select Show Coverage.
- Click the reload button inside the Coverage panel. It records the page load.
- Filter the list to CSS. Each file shows its total size and how many bytes went unused, with a bar showing the split.
- Click a file to open it. Lines used during loading are marked differently from unused lines, so you can scroll and see which sections are dead weight on this page.
Now open the mobile menu, click a tab, trigger a popup, scroll to the footer. Watch the unused figure fall a little. That is the first lesson: some CSS is only “unused” until someone interacts with the page. If you want more on reading the other DevTools panels, the post on checking page load in the network tab covers that side.
Reading the number honestly
Three things to keep in mind before you act on the percentage:
Unused here does not mean unused anywhere. The styles for your product grid are unused on the About page, and essential on the shop. Deleting them from the stylesheet would break the shop. The goal is to send each page what it needs, not to cut the file down for one page.
States and screen sizes count. Hover effects, open menus, form errors, cookie notices, mobile layouts and print styles may not show during a test, but visitors meet them.
Size matters more than the share. A small stylesheet that is mostly unused costs almost nothing. A large builder file that is half unused is worth attention. Look at the bytes, not only the ratio.
Ways to reduce unused CSS on a WordPress site
There are roughly four approaches, from gentle to aggressive. Most sites end up using two of them.
| Approach | What it does | Risk |
|---|---|---|
| Theme and builder settings | Loads styles only for features or widgets in use | Low |
| Per-page asset unloading | Stops a plugin’s stylesheet loading on pages that do not use it | Low to medium |
| Automatic “used CSS” generation | Builds a trimmed stylesheet for each page and loads the full one later or not at all | Medium to high |
| Rebuilding with lighter tools | Replaces a heavy theme or builder | Low once done, but a real project |
Start with the settings you already have
Many themes have a performance section that lets you turn off modules you do not use, such as a built-in mega menu, WooCommerce styling on a site without a shop, or icon sets. Page builders have their own options too. Elementor, for example, has performance settings in recent versions that load widget styles more selectively; what each one does is covered in our post on speeding up an Elementor site. Block themes already load the styles for individual blocks only when those blocks appear on a page.
These switches are written by the people who made the code, which is why they are the safest place to begin.
Unload plugin styles where they are not needed
Tools such as Perfmatters (its script manager) and Asset CleanUp list every stylesheet and script on a page and let you disable each one on specific pages or post types. The classic example is a contact form plugin: keep its CSS on the contact page, switch it off everywhere else.
The risk is that you guess wrong about where a plugin is used. A form might also sit in a footer widget or a popup that appears on every page. Check before you unload.
Automatic used-CSS features
WP Rocket’s Remove Unused CSS, the unused CSS option in LiteSpeed Cache, and similar features in other optimisation plugins load each page, record which CSS selectors match its content, and serve a much smaller stylesheet built for that page. This is the option that makes the warning shrink the most, and it is the way most people try to remove unused CSS in WordPress.
It works well on many sites. It also fails in predictable ways, which the next section covers. Every one of these tools has a safelist, an exclusion box where you list selectors or files that must always be kept. Expect to use it.
Do not confuse this with critical CSS, which is about which styles arrive first rather than which are removed. They are often offered side by side; critical CSS is explained separately.
What breaks when too much is removed
The tools look at the page as it is first loaded. Anything that only appears later can lose its styling:
- Classes added by JavaScript. A menu that gets an “open” class when tapped, a sticky header that changes on scroll, a slider that adds “active” to the current slide. The tool never saw those classes, so their styles are gone.
- Content that loads afterwards. Popups, cookie banners, chat windows, search results, “load more” posts.
- Logged-in and customer views. Account pages, WooCommerce notices such as “added to cart”, and form validation messages.
- Fonts and icons. Font and icon definitions are sometimes judged unused, and icons turn into empty squares. If that happens, our post on icons showing as squares or fonts going missing walks through the causes.
The fix is nearly always to add the affected selector or the whole stylesheet to the safelist, clear the generated CSS, and test again.
A testing routine that catches problems
Each time you change a setting, clear the generated CSS and every cache layer you have, from the plugin to the CDN. Then, logged out, go through this list:
- Home page, a blog post, a service page, and the contact page, on desktop and a phone.
- Open the mobile menu and any dropdowns.
- Submit a form with a deliberate error so the validation message shows.
- On a shop: add to cart, view the cart, start checkout.
- Scroll the full page and watch for headers, footers or sliders that look wrong.
Measure the same pages in PageSpeed Insights before and after, running each test more than once. Our complete guide to website speed explains where this fits alongside images, caching and hosting, which often matter more than CSS on a slow site.
Frequently asked questions
Is it worth fixing unused CSS if my stylesheets are small?
Probably not much. The warning lists the share of each file that went unused, but a small file costs little time even if most of it is unused. Focus on the largest stylesheets first, usually the theme and page builder files, and leave tiny ones alone unless everything else is already done.
Can I just delete unused rules from my theme’s stylesheet?
It is not a good idea. A rule unused on one page is often needed on another, and anything you edit directly in a parent theme disappears with its next update. Use a child theme for your own CSS and let a tool or settings decide what loads on each page instead.
Will the trimmed CSS update when I change the design?
Not always on its own. Most used-CSS features rebuild a page’s trimmed stylesheet when you clear their cache or edit that page, but changes to theme settings, global styles or a header template may not trigger it. After any design change, clear the generated CSS yourself and check a few page types on desktop and phone.
Does unused CSS affect anything other than loading time?
Mainly loading time, because the browser must download and read the full stylesheet before painting. Very large stylesheets also give the browser more rules to match against the page, which adds a little work, but on most small business sites the download and the delay to first paint are the parts that count.
Trimming a heavy theme or builder stylesheet is fiddly work. If you would rather hand it over, it sits within the CSS and JavaScript side of our speed optimisation work, which begins by measuring your pages and ranking what needs fixing, so you can see whether CSS is even the biggest problem.
Next in this series: How to Reduce Unused JavaScript on WordPress
