Skip to content
SEO Optimizer is live, Audit on page SEO and AI-search readiness. Try it free
تسجيل الدخول

How to Reduce Unused CSS

"Reduce unused CSS" means your page downloads style rules it never applies. Unlike most JavaScript, CSS is render-blocking by default: the browser will not paint anything until it has downloaded and parsed every stylesheet in the <head>. So unused CSS directly delays First Contentful Paint and Largest Contentful Paint. This guide shows how to find it, remove it safely and keep it out.

Why Unused CSS Slows Your Page

The browser needs the full CSS Object Model before it can lay out and paint the page, because any rule could affect any element. A 300 KB stylesheet of which your page uses 20 KB still has to be fully downloaded and parsed before the first pixel appears. On a slow mobile connection that is easily a second of blank screen. Unused CSS also costs time on every style recalculation, which shows up as slower interactions on big pages.

Where unused CSS usually comes from:

  • Full CSS frameworks (Bootstrap, Foundation, older Tailwind setups without purging) shipped in full for a handful of components.
  • One global stylesheet containing styles for every page and every component on the site.
  • WordPress themes and plugins that enqueue their CSS on every page, even pages that do not use the plugin.
  • Icon fonts and component libraries loaded in full.
  • Dead styles for features and pages that were removed years ago.

How to Find Unused CSS

  1. DevTools Coverage. Open the command menu in Chrome DevTools, choose "Show Coverage", reload the page and click around. Each stylesheet shows its unused bytes, and the source view marks unused rules in red.
  2. Check several page types. Unused CSS is per page. A rule unused on the homepage may be essential on checkout, so check your key templates, not just one URL.
  3. Look at the network panel for third-party stylesheets (fonts, widgets, plugins) you did not know were loading.

How to Reduce Unused CSS

1. Purge unused CSS at build time

Let your build remove selectors that never appear in your templates. Tailwind CSS does this automatically when its content paths point at all your template files. For other setups, PurgeCSS scans your HTML and JavaScript and strips unused selectors.

postcss.config.jsPurge unused selectors with PurgeCSS in production
module.exports = {
  plugins: [
    require("autoprefixer"),
    process.env.NODE_ENV === "production" &&
      require("@fullhuman/postcss-purgecss")({
        content: ["./src/**/*.{html,js,jsx,ts,tsx,vue,svelte}"],
        // Classes added at runtime must be safelisted or they get purged
        safelist: [/^is-/, /^has-/, "open", "active"],
      }),
  ].filter(Boolean),
};

The safelist matters. Classes that are only added by JavaScript at runtime, or built from string concatenation, are invisible to the scanner and will be removed unless you list them.

2. Inline critical CSS, load the rest later

Critical CSS is the small set of rules needed to render the visible part of the page. Inline it in the <head> and load the full stylesheet without blocking rendering. Tools like Critters (built into some frameworks) or the critical package extract it automatically.

index.htmlInline critical CSS and load the full stylesheet without blocking
<head>
  <style>
    /* critical rules for the header and hero, generated at build time */
  </style>
  <link rel="preload" href="/styles/main.css" as="style"
        onload="this.onload=null;this.rel='stylesheet'">
  <noscript><link rel="stylesheet" href="/styles/main.css"></noscript>
</head>

3. Split CSS by route or component

CSS Modules, scoped component styles (Vue, Svelte, Astro) and per-route CSS in frameworks such as Next.js only ship the styles a page uses. If everything lives in one global file, move component styles next to their components.

4. Stop loading plugin and widget CSS everywhere

On WordPress, the biggest win is usually dequeuing plugin stylesheets on pages that do not use the plugin (a contact form plugin's CSS only needs to load on the contact page). Asset manager plugins can do this without code. Our WordPress audit page covers the common offenders.

5. Replace heavy frameworks and icon fonts

If you use five components from a full CSS framework, import only those modules or replace them with your own small styles. Swap icon fonts for inline SVG icons so you only ship the icons you use.

6. Delete dead styles regularly

Purging handles selectors that match nothing in your templates, but old styles that still match something (a forgotten banner class) survive. Review Coverage on your main templates every few releases and delete what no longer serves a purpose.

Unused CSS and Render-Blocking Resources

Unused CSS and render-blocking resources are two sides of the same problem: the first is about how much CSS you ship, the second about whether it blocks the first paint. Reduce unused CSS first, then make what remains non-blocking with critical CSS. Do the same for scripts with our guide to reducing unused JavaScript.

How Scanverra Detects Unused CSS

A Scanverra performance audit lists stylesheets that ship unused CSS with the potential byte savings for each, together with render-blocking resources, unminified CSS and font loading issues, and explains which metric each one affects, usually LCP and First Contentful Paint. Fixes are written for the framework or CMS it detects (for example Tailwind content paths, Next.js CSS handling or WordPress plugin dequeuing). The audit measures one page load, so a rule it reports as unused on one page may be needed on another; check your other templates before deleting styles outright. Then move on to fixing LCP, which unused CSS often holds back.

الأسئلة الشائعة

الأسئلة الشائعة

It means your page downloads CSS rules that are never applied on that page. Because CSS blocks rendering, the browser still has to download and parse all of it before painting, which delays the first paint and LCP.

Mostly, if you configure it carefully. Build-time purging can remove classes that are only added by JavaScript or built from strings, so add those to a safelist and test interactive states like menus and modals.

Critical CSS is the minimal set of styles needed to render the part of the page visible on first load. Inlining it lets the browser paint immediately while the full stylesheet loads in the background.

Yes, mainly Largest Contentful Paint, because render-blocking CSS delays when the largest element can paint. Very large stylesheets can also slow style recalculation during interactions.

Themes and plugins often load their stylesheets on every page, even where they are not used. Dequeuing plugin CSS on pages that do not need it is usually the biggest single improvement.

مجاني - بدون تسجيل

Check this on your own site

Run a free scan and see exactly where you stand - no sign-up required.

تشغيل الفحص المجاني