Remove Unused CSS
Strip CSS rules that no page uses to shrink stylesheets and unblock rendering.
Metrics
This technique can move up to 33% of LCP's share of the Lighthouse score.
This technique can move up to 67% of TBT's share of the Lighthouse score.
This technique does not move CLS.
This technique can move up to 67% of FCP's share of the Lighthouse score.
This technique can move up to 67% of SI's share of the Lighthouse score.
This technique does not move TTFB.
Overview
WordPress themes ship with CSS for every feature — sliders, WooCommerce, contact forms, widgets — whether or not the current page uses them. A typical theme delivers 150–500 KB of CSS per page, of which 80–95% applies to zero visible elements. Every byte of CSS is render-blocking: the browser cannot paint until all stylesheets are downloaded, parsed, and the style cascade is computed.
Impact grade, A+ to D: how much of the Lighthouse score this technique can move. Unaffected: CLS, TTFB.
The Problem
CSS is the only resource that both blocks rendering and requires a full style recalculation before first paint. A 200 KB stylesheet takes 40–80 ms to parse and another 30–60 ms to compute styles — on top of transfer time. Lighthouse reports ‘Reduce unused CSS’ when it detects rules whose selectors match no elements in the current DOM.
Performance Impact
LCP
50–200ms
LCP element renders sooner when render-blocking CSS is reduced
TBT
50–200ms
fewer CSS rules = faster style recalculation on interaction
FCP
100–400ms
smaller render-blocking CSS transfers and parses faster
SI
100–300ms
paint begins sooner when the critical render path is shorter
Risk: Medium
over-aggressive purging can strip styles for dynamic content
How it works
01
Audit unused CSS
Open Chrome DevTools → Coverage (Ctrl+Shift+P → Coverage). Load the page and check the CSS coverage report. Red bars indicate unused ranges. Lighthouse also reports estimated savings under ‘Reduce unused CSS’.
02
Use PurgeCSS or UnCSS
PurgeCSS scans your HTML templates and JavaScript files for class names, then removes any CSS rule whose selector contains no matching class. Run it in your build pipeline with safelist patterns for dynamically-added classes.
03
Conditionally enqueue stylesheets in WordPress
Use
wp_enqueue_style()conditionally — only load WooCommerce CSS on shop pages, contact form CSS only where the form shortcode is present, slider CSS only on pages with sliders. This is lower-risk than purging and preserves full CSS fidelity.04
Combine with Critical CSS
After removing unused rules, inline the remaining above-fold CSS as critical CSS and defer the rest. The combination removes both bloat and render-blocking latency — often reducing FCP by 300–700 ms together.
Limitations
- PurgeCSS cannot detect classes added dynamically by JavaScript at runtime — they must be explicitly safelisted.
- Third-party plugin CSS (WooCommerce, contact forms) is difficult to purge safely without exhaustive testing of every state.
- Purging changes the stylesheet on every build — requires regression testing of all page types after deployment.
Common Mistakes
Running PurgeCSS without a safelist for dynamic classes
Classes added by JS (menu-open, is-active, swiper-slide-active) are not present in static HTML and will be purged. Build a comprehensive safelist or use regex patterns to protect entire namespaces.
Purging CSS for a production site without testing all page types
Run the purged build against every page template — home, post, category, product, cart, checkout, 404. One missing class on the checkout page can break conversions.
Need help applying this to your site?
Targeted fixes, not guesswork. We identify which techniques move the needle for your specific WordPress stack.
Start an Engagement