Open the network tab in your browser’s developer tools on a typical WordPress homepage, and you might be surprised. Thirty, forty or more stylesheets and scripts. Styles for a contact form on a page with no form. Slider scripts on pages without sliders. Three different icon libraries. A page builder’s entire animation framework loaded for one fade-in effect.
This bloat slows everything down. Stylesheets block rendering, scripts compete for the main thread and mobile visitors pay the price in slower loading and laggy interactions. It’s one of the main reasons sites struggle with Core Web Vitals.
The good news is that much of this code can be removed, loaded only where it’s needed or deferred. The bad news is that careless optimisation breaks sites in confusing ways. Here’s how to do it properly.
Why WordPress sites get bloated
WordPress itself is fairly lean on the front end. The bloat comes from how plugins and themes load their assets:
- Sitewide loading. Many plugins load their CSS and JavaScript on every page, because it’s simpler than working out where they’re needed.
- Multipurpose themes. Themes built to do everything load code for features you’ll never use.
- Page builders. Builders often load large frameworks, animation libraries and icon sets.
- Third-party scripts. Analytics, ads, chat, heatmaps and social embeds add up quickly.
- Duplicate libraries. Several plugins loading their own copies of the same library.
Step 1: Audit what’s loading
Before changing anything, find out what’s actually there.
Browser developer tools
Open the network tab, filter by JS and CSS, and reload the page. Note the file names, sizes and where they come from. The plugin folder name in the URL tells you which plugin loaded each file.
The Coverage panel in Chrome DevTools shows how much of each CSS and JavaScript file is actually used on the current page. It’s common to see stylesheets where 90 percent of the rules go unused.
Query Monitor
Query Monitor’s Scripts and Styles panels list every enqueued asset with its handle, which is the name WordPress uses to identify it, along with dependencies and the component that registered it. You need these handles to remove or modify assets in code.
Make a list
For each asset, write down:
- Which plugin or theme loads it.
- Which pages actually need it.
- Its size.
You’ll quickly see the biggest opportunities.
Step 2: Remove what you don’t need at all
The best optimisation is deletion.
- Remove unused plugins. Every plugin you delete takes its assets with it.
- Turn off unused features. Many plugins and themes have settings to disable modules, icon libraries, Google Fonts or animations you don’t use.
- Replace heavy plugins with lighter ones. A social sharing plugin that loads 200 KB of scripts can often be replaced with simple share links that load nothing.
- Question third-party scripts. Is anyone using that heatmap tool? Is the chat widget generating enquiries?
Step 3: Load assets only where they’re needed
Some plugins are needed, just not everywhere. A contact form plugin is needed on the contact page. A WooCommerce store’s cart scripts aren’t needed on blog posts.
Conditional dequeuing in code
WordPress lets you remove enqueued assets with wp_dequeue_script and wp_dequeue_style. Use conditional tags to decide where:
The priority of 100 makes sure this runs after the plugin enqueues its assets. Handle names vary, so use the ones Query Monitor shows. Put this code in a small custom plugin rather than your theme, so it survives theme changes.
Asset management plugins
Several plugins provide an interface for disabling specific scripts and styles on specific pages or post types. They’re convenient, especially for sites without a developer, but use them carefully. Disabling a dependency can break things in subtle ways.
WooCommerce assets
WooCommerce loads some scripts and styles across the site, such as cart fragments that update the mini cart. On sites where blog content far outnumbers shop pages, limiting these to shop pages can make a real difference. Test the mini cart, add to cart buttons and checkout carefully afterwards.
Step 4: Defer and delay JavaScript
Scripts that load in the page head without defer or async block the browser from rendering the page until they download and run.
defer and async
- defer downloads the script in parallel and runs it after the HTML is parsed, in order.
- async downloads in parallel and runs as soon as it’s ready, in no particular order.
defer is safer for most scripts, because it preserves execution order, which matters when scripts depend on each other.
Since WordPress 6.3, you can specify a loading strategy when registering scripts:
WordPress handles dependencies intelligently. If a deferred script depends on another script, WordPress adjusts loading so the order still works. For third-party plugin scripts, you can’t always change how they’re registered, but many optimisation plugins can add defer to scripts.
Delaying until interaction
Some optimisation tools offer to delay JavaScript entirely until the visitor interacts with the page, by scrolling, clicking or moving the mouse. This can dramatically improve lab scores. It’s powerful but risky:
- Features that should work immediately, like menus or above-the-fold sliders, may not respond on the first tap.
- Analytics may undercount visitors who leave without interacting.
- Scripts that expect to run in a certain order can break.
Use delay for clearly non-essential scripts, like chat widgets and some marketing tags, and exclude anything needed for the first interaction.
Step 5: Reduce CSS
CSS is render-blocking by default, so large stylesheets directly delay the first render.
Remove unused CSS
Tools that generate “used CSS” for each page can strip out unused rules. Some optimisation plugins do this automatically. Results can be impressive, but test carefully. Styles for elements that appear only after interaction, like menus, modals or form errors, can be removed accidentally.
Critical CSS
Critical CSS means inlining the small amount of CSS needed to render the visible part of the page, and loading the rest without blocking. It improves perceived load speed. Generating and maintaining it manually is tedious, so most sites use a plugin or service.
Block themes load less by default
Modern block themes and the block editor load styles more selectively than older themes. WordPress can load styles only for blocks used on the page. If you’re planning a redesign, a lean block theme reduces CSS bloat at the source.
Step 6: Combine and minify carefully
Minification removes whitespace and comments, making files smaller. It’s safe in most cases and worth doing.
Combining files into one used to be standard advice, but with HTTP/2 and HTTP/3, loading several smaller files is efficient, and combining can actually hurt caching. I rarely combine files today unless there’s a clear measured benefit.
Testing changes safely
Asset optimisation is where I see the most broken sites. A few rules:
- Change one thing at a time and test after each change.
- Test on staging first.
- Test real functionality, not just appearance: menus, forms, sliders, cart, checkout, search, logged-in features and the mobile menu.
- Check the browser console for JavaScript errors after each change.
- Clear all caches between tests, including page cache, CDN and browser.
- Test as a logged-out visitor, because many optimisations don’t apply to logged-in users.
Keep a note of what you changed, so you can reverse it if a problem appears days later.
Building leaner sites from the start
If you build sites, prevention is easier than cure:
- Choose a lightweight theme or build a lean custom theme.
- Enqueue assets only on templates that use them.
- Use native browser features before adding libraries. CSS can handle many animations without JavaScript.
- Avoid adding a plugin for every small feature.
- Keep a performance budget, a target maximum for JavaScript and CSS per page, and check it before launch.
Frequently asked questions
Will removing scripts break my site?
It can, if you remove something a feature depends on. That’s why auditing, testing one change at a time and checking the console are essential. Done carefully, removing unnecessary assets is safe.
Do I need a developer to do this?
Simple steps, like removing plugins and disabling unused features in settings, don’t require a developer. Conditional dequeuing, critical CSS and careful script deferral are easier with technical knowledge.
Is a high PageSpeed score worth breaking functionality for?
No. A working site with a decent score beats a broken site with a perfect score. Aim for real improvements in loading and responsiveness, not just the number.
Should I remove jQuery?
WordPress no longer loads jQuery on the front end unless something requires it. Many plugins and themes still depend on it. Removing it only makes sense when nothing on the page needs it, which you can check in Query Monitor’s dependency list.
Final thoughts
JavaScript and CSS bloat creeps in one plugin at a time, and it quietly slows every page. Audit what loads, delete what you don’t need, load the rest only where it’s used and defer scripts that don’t need to run immediately. Test every change properly, and you’ll get faster pages and better Core Web Vitals without breaking the features your visitors rely on.
