The Hidden Performance Tax: How Unused CSS and JavaScript Slow Down Every Page

I ran a coverage report on a client's homepage last month. Out of 640 KB of CSS loaded on that single page, 412 KB was never used. Not a single selector matched. Not one rule applied. The browser downloaded it, parsed it, and threw it away. That was just the CSS. The JavaScript was worse.

The Problem Nobody Sees

Every WordPress page loads the same bundle of CSS and JavaScript regardless of what is actually on that page. Your contact page loads WooCommerce styles. Your blog loads slider scripts. Your homepage loads form validation for a form that only exists on one interior page.

This is not a minor inefficiency. Studies show the average website ships roughly 37% unused CSS and 43% unused JavaScript. On WordPress sites with a few plugins and a page builder, those numbers climb much higher. I have seen sites where over 70% of loaded assets go completely unused on any given page.

The reason this persists is that it is invisible. Your site still works. Pages still render. Nothing is technically broken. But every unused kilobyte adds load time, blocks rendering, and taxes the browser. On mobile devices with slower processors and spotty connections, the cost compounds fast.

Why This Hurts More Than You Think

CSS is render blocking by default. The browser will not paint a single pixel until it has downloaded and parsed every stylesheet in the head of your document. When half of that CSS is irrelevant to the current page, you are forcing visitors to wait for code that does nothing.

This directly impacts Largest Contentful Paint. LCP measures when your main content becomes visible. If the browser is stuck parsing 400 KB of CSS it will never use, that is time your visitor spends staring at a blank screen. Google wants LCP under 2.5 seconds. Unused CSS can easily add half a second or more, especially on mobile.

JavaScript is often worse. Unused scripts still need to be downloaded, parsed, and compiled. Even deferred scripts consume CPU time. On a mid range phone, parsing 500 KB of JavaScript can take over a second. That processing time directly contributes to poor INP scores because the main thread is busy with code that has nothing to do with the page the visitor is looking at.

In my experience running WordPress sites, the performance difference between loading everything everywhere versus loading only what each page needs is dramatic. I have seen LCP improvements of 1 to 2 seconds just from eliminating unused assets. No server changes. No hosting upgrade. Just stop loading code that is not being used.

How WordPress Makes It Worse

WordPress was not designed for per page asset loading. Plugins enqueue their styles and scripts globally because that is the simplest approach and it always works. A contact form plugin has no way to know which pages actually have a form on them, so it loads everywhere just in case.

Themes compound the problem. A theme with 15 built in features loads CSS for all 15 on every page, even if you only use three. Page builders are particularly aggressive. They generate massive stylesheets covering every possible layout combination, then serve the entire bundle on every page.

The numbers add up fast. A typical WordPress site with WooCommerce, a contact form, a slider, and a page builder might load 800 KB to 1.2 MB of CSS and JavaScript on a simple blog post that needs almost none of it. That is bandwidth wasted, rendering delayed, and interactivity degraded on every single page view.

WordPress 6.9 took a step in the right direction by introducing per block CSS delivery for core blocks. That helps, but it only covers the blocks WordPress ships. Your theme and plugin assets are still loaded globally unless something actively prevents it.

What Most People Get Wrong

The first instinct is usually minification. Shrink the files. Remove whitespace. Combine everything into fewer requests. That helps a little, but it misses the point entirely. Minifying 400 KB of unused CSS gives you 350 KB of unused CSS. You have made a smaller version of something that should not be loaded at all.

The second mistake is combining files. Merging all CSS into one file and all JavaScript into one file was good advice in the HTTP/1.1 era. With HTTP/2 and HTTP/3, the browser can handle many small files efficiently. Combining actually makes the problem worse because now every page loads one massive file containing styles and scripts for every other page on your site.

The third mistake is thinking a CDN solves this. A CDN delivers your files faster, but it still delivers all of them. Serving 600 KB of unused CSS from an edge server 50 miles away is better than serving it from a server 3,000 miles away, but you are still serving 600 KB of unused CSS. Speed of delivery does not fix the problem of delivering too much.

The real fix is surgical. Each page should only load the CSS and JavaScript it actually uses. Nothing more. That sounds simple, but on WordPress it requires understanding which assets belong to which pages and selectively loading or unloading them. Doing this manually across a site with dozens of pages and a handful of plugins is tedious and fragile. One theme update can break your carefully curated asset list.

The DIY Reality

I have tried managing this manually. You can dequeue scripts and styles with PHP conditionals. Check what page you are on, then remove what is not needed. It works. But maintaining it is a different story.

Every time you add a plugin, you need to audit what it loads and where. Every theme update might re enqueue something you removed. Every new page might need assets you dequeued globally. It becomes a full time job on an active site.

Then there is the risk. Remove the wrong stylesheet and your checkout page breaks. Dequeue a script that another script depends on and you get silent JavaScript errors that you might not notice for weeks. I once dequeued what I thought was an unused jQuery library and discovered two months later that it broke the mobile menu on tablets in landscape mode. Nobody reported it because nobody tested that specific combination.

The manual approach also does not handle unused CSS within files. Even after you stop loading WooCommerce styles on your blog, the WooCommerce styles that do load on product pages still contain thousands of selectors that your particular site does not use. Trimming CSS at the selector level requires tooling that goes well beyond what you can do with a few PHP conditionals.

The Real Cost Is Cumulative

Unused assets do not just affect page speed. They affect everything downstream.

Slower pages mean higher bounce rates. Google reports that as page load time goes from 1 second to 3 seconds, bounce probability increases by 32%. From 1 to 5 seconds, it increases by 90%. When a meaningful chunk of that load time is wasted on unused code, you are losing visitors to a problem that is entirely fixable.

Core Web Vitals suffer across the board. LCP gets worse because CSS blocks rendering. INP gets worse because JavaScript occupies the main thread. Even CLS can be affected when late loading styles cause layout recalculations.

And it scales linearly with traffic. If your site gets 100,000 page views a month and each page loads 400 KB of unnecessary assets, that is 40 GB of wasted bandwidth. Your visitors are collectively downloading 40 gigabytes of code that does absolutely nothing. On metered mobile connections, that waste has a real cost your visitors are paying.

What Good Looks Like

The difference between a WordPress site that loads everything globally and one that loads assets intelligently is striking. In my experience, properly optimized sites typically show 30 to 50% reductions in total CSS size per page and 40 to 60% reductions in JavaScript. That is not optimization by percentages. That is removing hundreds of kilobytes from every page view.

The before and after is the kind of thing you can feel. Pages that took 3 to 4 seconds to become interactive start responding in under a second. Mobile performance goes from failing Core Web Vitals to passing comfortably. The site does not just test faster. It feels faster to use.

The best part is that nothing changes visually. Your site looks exactly the same. Your features all work. You have not removed any functionality. You have just stopped loading code where it is not needed. It is the rare optimization that is purely upside with no tradeoff.

That is exactly why we built per page asset optimization into our performance plugin. Every page should only load what it needs. Not what every other page on your site might need. The browser should spend its time rendering your content, not parsing code it will never execute.