I recently opened up the theme running one of my websites. Not the settings screen. The code. I have 33 years in technology, so this wasn’t my first look under a hood, but I was still surprised by what I found.
I have 33 years in technology, so this wasn’t my first look under a hood, but I was still surprised by what I found.Share on X
The site had been slow for a while, and I’d eliminated everything else. Hosting fine, plugins lean, caching aggressive, images optimized. The only suspect left was the theme. So I unzipped it and started reading.
What I found was a collection of parts. This matters beyond speed. As I laid out in the opening article of this series, your website is your beacon on the internet. For a service business it’s where your credibility lives, and everything attached to it, starting with the theme, either strengthens that beacon or slowly degrades it.
The monster on the slab
There was JavaScript running an animation loop for a cursor follower, a decorative dot that trails your mouse around the screen.
Trendy effect a few years back. No page on my site ever displayed that element. The template that would have rendered it was never called from anywhere. But the code still ran on every single page load, attaching mouse listeners to every button, link, and form field, updating the position of an element that didn’t exist. Every visitor’s browser did that work for nothing.
There was CSS for a media player the theme never used. There were three different generations of settings systems living side by side, each added when the developers needed something the previous one couldn’t do, none removed when its replacement arrived. There were hooks for features that had been taken out, still firing on every request, calling functions that did nothing.
None of this was broken, exactly. The site worked. It just carried the dead weight on every page, for every visitor, forever.
I find that more irritating than a bug. Users report a bug and developers fix it. Developers ship working dead weight forever, because nobody is ever going to file a ticket about a cursor that doesn’t exist. I call it a Frankenstein’s monster because that’s what it is. Nobody sat down and designed this theme. Somebody assembled it, from pieces built at different times, by different people, for different purposes, and stitched the seams just well enough that it would stand up and walk.
How does a WordPress theme become a Frankenstein?
Every part is loaded on every page, whether you use it or not.
Once you understand how commercial themes are made, the mess stops being surprising and starts being inevitable.
Theme shops don’t build themes from scratch. They build a base once, a big one, loaded with every module a customer might ever want: mega menus, sliders, tickers, demo importers, cursor followers, a dozen header layouts. Then they produce new themes by reskinning that base. Change the fonts, change the colors, swap the demo content, give it a new name, publish it as a separate listing.
The economics drive everything. A theme shop makes money per listing. A theme built from scratch is one listing per year of work. Reskinning produces a listing per week. Guess which approach wins. The theme on my site was exactly this: a reskin of another theme by the same vendor. That was itself assembled from modules that appear across the vendor’s whole catalog. My theme was a diff on top of a pile of diffs.
When your product is an assembly of shared modules, removing anything is expensive. Strip the cursor follower out of one theme and you’ve created a special case your build process must track forever. Leave it in and it costs you nothing. It only costs your customers, a little, on every page load, multiplied by every visitor, multiplied by every site running the theme. That cost is invisible to the vendor, so the vendor never pays it.
A fact worth knowing: being in the official WordPress theme directory means less than most people assume.
Themes go through a largely automated check plus a volunteer review focused on requirements compliance. Passing that gate means the theme follows the rules. It doesn’t mean anyone vouched for the engineering. My Frankenstein came from the official directory.
That one is a real problem. Site owners see the directory badge and assume somebody checked the engineering, and nothing on the listing tells them the check was about rules compliance.
Why can’t a caching plugin fix a bloated WordPress theme?
The standard advice when a WordPress site is slow is to add a caching plugin, and caching does help. It helps the way painkillers help a broken leg.
Caching stores the finished page so the server doesn’t rebuild it for each visitor.
That fixes server time. It does nothing about what is in the page. If your theme ships 300 kilobytes of styles for modules you don’t use, the cache serves those 300 kilobytes faster. If the theme runs an animation loop for an element that doesn’t exist, that loop runs in your visitor’s browser, after the cache has done its job, on every page view. No cache layer touches it.
This is why so many site owners end up in a loop I’ve watched for years. The site is slow. They add an optimization plugin. The score improves a little.
The site is still slow, they add another plugin, and now they have two more moving parts and the same underlying problem. The weight is in the theme, and the theme is the one thing the optimization tooling works around instead of on.
How do you fix a Frankenstein WordPress theme?
Nobody is going to write their own theme, and I’m not going to pretend otherwise. The answer depends on where you are.
If you’re choosing a theme, choose by what is missing. The marketing pushes you the other way. Theme listings compete on feature count: 50 demos, 12 sliders, unlimited headers. Every one of those features is code that ships to your visitors whether you use it or not. A theme that does less is a smaller monster. Find a theme that does what you want instead of a box with tons of parts in it.
The default themes that ship with WordPress are among the few designed from scratch. The people building them have quality as their incentive instead of listings, and the newer block themes are structurally leaner than the old assemble-everything generation. They’re not glamorous. They’re also not carrying three settings systems and a ghost cursor.
Test before you commit. Every theme has a live demo, and the demo is the theme on its best behavior, running the vendor’s own content on the vendor’s own hosting. Run that demo through PageSpeed Insights before you install anything. Two minutes. If the demo scores poorly, your site will score worse, because your site adds your plugins and your content on top. A slow demo is the vendor telling you, in writing, that they don’t care. Believe them.
It’s a bitch to change themes, too. The original idea was that the theme holds the structure and the styles, so your data stays separate and you can swap themes. They’ve drifted from that. They store things in their own spots that don’t carry over, so I had to re-enter a lot of data each time. After the third switch I was done. I wrote my own plugin that stores that data in the custom CSS under Advanced > Customize CSS, so it survives a theme change.
If you’re already married to a monster, contain it. You can’t easily strip a bad theme, but you can stop feeding it. Every theme option you enable, every demo section you import, every bundled plugin you activate adds weight. Turn off what you don’t use, keep the plugin count ruthless, and let good caching mask what remains. Containment isn’t a cure, but it’s real relief, and for a hobby site it’s enough.
If your site earns money, fork it once and own it. This is what I finally did. I had the theme copied into a private version and stripped of everything my site doesn’t use: the phantom cursor, the unused player, the dead hooks, the styles for absent modules. One-time job, and the difference wasn’t subtle. The site went from sluggish to scoring 100 on desktop performance. More important, I now know what every line in that theme does, because every line that did nothing is gone.
This is the kind of work I take on for clients whose sites have earned it.
The moral of the monster
I don’t think theme developers are villains. They respond rationally to a marketplace that rewards listings and feature lists and never audits what ships inside. The incentives guarantee Frankenstein’s monsters, so stop being surprised when you get one.
Look at who pays. The vendor never feels the cost of that ghost cursor. The site owner does, in slow pages and visitors who give up and leave, and most of them will never open the code to find out why. A marketplace that ships dead weight to that many sites and calls it features deserves a lot more scrutiny than it gets.
Next in this series: what happened when I tried to leave two page builders, one because it was bad and one because it was excellent. The exit cost more than either arrival, and that asymmetry is the subject of Divorcing Your Page Builder.
Frequently Asked Questions
