Speed

Reduce Unused CSS and JavaScript in WordPress: What to Fix and What to Ignore

Why plugins and page builders load CSS and JavaScript on every page, how to load them only where needed, and when the unused-code warning isn't worth chasing.

Reduce Unused CSS and JavaScript in WordPress: What to Fix and What to Ignore
On this page
  1. What the warning actually measures
  2. Why WordPress sites load code everywhere
  3. Step 1: Remove plugins you don't need
  4. Step 2: Load scripts only where they're needed
  5. Asset manager plugins
  6. Page builders and "remove unused CSS" features
  7. When the warning isn't worth chasing
Key takeaways
  • The warning counts code not used during one page load, so it points to possible waste rather than code you can safely delete.
  • Remove plugins you don't need first, then load form, slider, shop and payment scripts only on the pages that use them.
  • Small savings, third-party code you rely on and pages with good real-user Core Web Vitals are usually not worth chasing.

PageSpeed Insights often tells WordPress site owners to "reduce unused CSS" and "reduce unused JavaScript", with a list of files and an estimate of how much could be saved. Some of that saving is real and worth having. Some of it is noise. Here's where unused code comes from, how to cut it safely and when the warning is best left alone.

What the warning actually measures

During the test, the browser tracks which parts of each CSS and JavaScript file were used while the page loaded. Everything else counts as unused, and files with a lot of it get listed.

"Unused" means unused on this page, during this load. A stylesheet may hold rules for your contact page, the open mobile menu or a pop-up that hasn't appeared yet, and code that only runs when someone clicks counts as unused too. So the figure points to where waste may be; it isn't a list of code you can delete.

To see it yourself, open Chrome's developer tools, choose Coverage from the More tools menu and reload the page. Each file is shown with its used and unused portions.

Why WordPress sites load code everywhere

A plugin usually can't know which pages you'll use it on, so many play safe and load their files on every page:

  • A form plugin's styles and scripts site-wide, though the form is only on the contact page
  • A slider's files everywhere for one slider on the homepage
  • WooCommerce files on blog posts and the About page
  • Page builder add-on packs loading code for dozens of widgets you never use
  • Full icon libraries for a handful of icons
  • Multipurpose themes bundling features for every kind of website

Browsers cache these files after the first visit, but a new customer arriving from Google has to download and process all of it. JavaScript costs more than CSS, because the phone has to run it, which can also make taps feel sluggish; see how to improve INP.

Step 1: Remove plugins you don't need

The cleanest unused code is code that never loads. Go through your plugin list and ask of each one: why is it here, is that reason still current, and could something already on the site do the job?

  • Delete plugins left over from old campaigns, trials or a previous developer
  • Don't run two plugins that do the same thing, such as two form or two slider plugins
  • Keep page builder add-ons to one well-made pack, or none
  • Replace a heavy plugin used for one small feature with a lighter option or a short snippet

Deactivate on a staging copy first, test, then delete. Essential WordPress plugins covers what most business sites actually need.

Step 2: Load scripts only where they're needed

Next, stop the plugins you keep from loading everywhere. A sensible map for a typical site:

AssetLoad it on
Form plugin and spam protectionPages with a form
Slider or carouselPages with a slider
WooCommerce shop and cart scriptsShop, product, cart and checkout pages (plus any header mini-cart)
Payment gateway scriptsCheckout
Map or booking widgetContact or booking pages

Developers do this with a few lines of code that remove a file unless the page matches a condition, kept in a child theme or small custom plugin so updates don't overwrite it. Some plugins also have a setting to load only where their block or shortcode appears, so check for that first. Block themes help too: WordPress can load core block styles only for the blocks used on each page.

Asset manager plugins

If you'd rather not touch code, an asset manager plugin lists every CSS and JavaScript file each page loads and lets you switch files off per page, per post type or site-wide with exceptions. Some performance plugins include a similar script manager. Used carefully, they work well. Used carelessly, they break things:

  • Files depend on each other, so switching off a shared library can break several plugins at once
  • A file that looks unnecessary may power the mobile menu, cookie banner or form validation
  • Rules are easy to forget, so a new page with a form may go live without the form's scripts

Change one thing at a time, test logged out with caches cleared, and keep a note of every rule so the next person working on the site understands it.

Page builders and "remove unused CSS" features

Page builders are a common source of this warning because they're designed to build anything. Recent Elementor versions include performance features, some switchable in its settings and some on by default, that load widget code only where those widgets are used. Flatter layouts with fewer widgets and add-ons mean less code as well; see why Elementor sites get slow.

Several performance plugins also offer a "remove unused CSS" option that builds a trimmed stylesheet for each page. It can work well, but styles that only apply after interaction, such as an open mobile menu, a pop-up or a form error message, may be stripped because they weren't used during the scan. These plugins let you safelist such styles, so check menus, pop-ups and forms on a phone after enabling it.

When the warning isn't worth chasing

  • The savings are small. A few kilobytes across a couple of files won't change what visitors feel
  • It's third-party code you need. Analytics, Tag Manager, payment and chat scripts include code you don't use, and you can't edit them; you can only decide whether and when they load (see third-party scripts)
  • Real-user Core Web Vitals are already good. If visitors get a fast experience, clearing a lab warning adds little
  • The fix costs more than it's worth. Rebuilding a theme just to clear a warning rarely makes sense unless a redesign is due anyway

Focus on large files, on JavaScript before CSS, and on the pages that bring enquiries or sales.

Want the unused code trimmed without breaking your forms and menus? See WordPress speed optimisation, or Elementor development for builder sites that need a leaner rebuild.

Need help with your website?

I'm Sameer, a freelance WordPress developer building fast, SEO-friendly websites since 2020. Tell me what you need and I'll reply with a plan and a fixed quote within 24 hours.

Found this useful? Share it:
Contact

Let's build your next website

Available for freelance projects, agency white-label work and long-term maintenance. Feel free to pass this along to your team or company.

Your details are emailed to me, then WhatsApp opens so we can chat right away.

Chat now