From Slow to Slower: WordPress Backend Bloat Is Getting Worse
When it comes to optimizing WordPress performance, all eyes are on the front end. Page builders talk endlessly about "clean HTML," asset minification, or lazy-loading images to improve Lighthouse scores. However, there's one area that's almost completely overlooked—despite its significant impact: backend bloat.
Behind every slow WordPress site is a web of autoloaded plugin files, unnecessary classes, and functions that run even when they’re not needed. WooCommerce is one of the most powerful and widely used plugins in the WordPress ecosystem—but it's also one of the most bloated. Over the years, it has quietly grown into a backend heavyweight, affecting Time to First Byte (TTFB) even on pages that don’t touch e-commerce functionality at all.
In this post, I’ll walk you through a series of real-world measurements comparing WooCommerce versions from 5.6.2 to 10.1.2—both in empty test installs and on a real e-commerce site. The results demonstrate the significant amount of unnecessary overhead introduced in newer versions and its direct impact on backend speed, memory usage, and cold start performance.
This all started when I took over maintenance and admin work on a busy WooCommerce-based e-shop for a long-term client. The site was far from minimal—it ran over 90 active plugins, WooCommerce with multiple plugins for shipping, membership, subscription, and a busy blog with ads, premium access...
At first, I reached for what most developers do: a plugin that promised plugin optimization. I tried one called “Plugin Optimiser.” It worked to some extent, but it was too rigid and lacked the level of control I needed. So I forked it. And then eventually, I rewrote it entirely—what began as a hack turned into a full-featured tool I now maintain: Advanced Plugin Filter.
With it, I built over 60 filters for that single site—each one tuned to load only the necessary plugins depending on the request type: front-end, admin, AJAX, REST API, Cron jobs, and more. It was the only way to keep the experience usable without removing core features the business relied on.
AJAX calls that used to feel stuck now respond in milliseconds. Admin pages, especially those related to WooCommerce orders, became actually pleasant to use. We shaved entire seconds off the TTFB just by cutting out the dead weight. According to today’s stats, the average TTFB on a product page is 660ms when full page cache is not used and running on one of the fastest CPUs money can buy today.
Some plugins don’t play well when you try to disable them in certain branches—routing breaks, actions are skipped, or hooks don’t fire. And it does add complexity: every plugin you introduce has to be tested across contexts. But the trade-off is worth it when you're trying to run a high-functioning e-commerce site on WordPress at scale.
What WordPress really needs is a cultural shift: where back-end performance is treated with the same seriousness as front-end, with arrival of the Oxygen builder. Just like you wouldn’t load 1.5MB of unused CSS, plugin code that’s never used in a given request should not be loaded at all.
To measure how WooCommerce’s backend footprint has grown over time, I designed two test scenarios: one controlled and minimal, the other based on a real-world WooCommerce store. Both were run locally on Windows for consistent environment control.
1. Clean WordPress Install – Minimal Load
This scenario isolates WooCommerce to reveal its standalone impact.
This scenario replicates a real e-commerce site with all the usual complexity.
While TTFB (Time To First Byte) is a widely used term, what I measured technically isn’t the traditional TTFB reported by browser dev tools or external monitors.
Instead, I measured the time between when WP_START_TIMESTAMP is defined in WordPress Core and when the PHP shutdown function is triggered — just after the main thread finishes executing.
This means my values exclude:
I chose this approach intentionally. It isolates the part of the request lifecycle that WordPress plugins and themes can actually influence — making it a more accurate reflection of backend bloat, rather than external delivery issues.
That said, for the sake of readability, I still refer to it as TTFB throughout this post. Just know that this is a focused, internal measurement — not the browser-visible TTFB from tools like Lighthouse or WebPageTest.
Each scenario focused on specific backend points to maintain comparability:
1. Minimal Install
Tested Page: /wp-admin/tools.php (standard admin Tools screen)
Why? It's a neutral backend screen where WooCommerce doesn’t need to do anything—but still loads.
2. Real Store
Tested Page: A product page with multiple variations and bundles.
Why? Real-world frontend scenario with the full stack running.
For each scenario and WooCommerce version, I captured:
Each request was measured under two conditions:
Cold Run:
Warm Run:
It’s important to understand that OPcache has a time-to-live (TTL). In real-world scenarios, especially on sites that don’t receive constant traffic or run on shared hosting, there’s a high chance that OPcache won’t always be ready. When that happens, PHP has to reload all the files, parse them, compile them, and repopulate the OPcache before it can run the code.
I know this firsthand because I’ve measured real-world e-shops. Even on high-performance dedicated servers running low load, if the OPcache isn’t ready, you’ll see a +5 second spike in TTFB. On shared or less performant hosting, that possibility is even higher. That’s why we have to consider cold runs as a realistic scenario—because it does happen in the wild.
To understand WooCommerce’s true backend footprint, I first measured it in total isolation.
This scenario used the cleanest setup possible: a fresh WordPress install on Windows, with only one plugin activated — WooCommerce — and an intentionally blank theme. No caching layers, no object cache, no CDN. Just WordPress, WooCommerce, and a stopwatch script.
The tested page was /wp-admin/tools.php — a backend admin screen where WooCommerce has no visible presence or functionality. In theory, this page shouldn’t require WooCommerce at all. And yet, as you’ll see, WooCommerce still autoloads hundreds of files and introduces measurable delay.
To make the difference clear, I also measured the same page with no plugins at all, using WordPress core only.
| Version | Files Loaded | OPcache Memory | Cold TTFB | Warm TTFB |
|---|---|---|---|---|
| WordPress Core Only | - | – | 580 ms | 30 ms |
| WooCommerce 5.6.2 | 493 | 10 MB | 1.1 s | 130 ms |
| WooCommerce 7.5.1 | 746 | 13 MB | 1.2 s | 130 ms |
| WooCommerce 10.1.2 | 893 | 19 MB | 1.4 s | 140 ms |
In short: WooCommerce does not respect context. Even on a backend page it has no reason to touch, it autoloads everything — costing hundreds of milliseconds and consuming server memory.
Next, let’s see how this changes when we measure WooCommerce in a real-world environment, with dozens of active plugins, a custom theme, and live product pages. Note, I couldn't downgrade to 5.6.2, so measurements are missing.
| Version | Files Loaded | OPcache Memory | Cold TTFB | Warm TTFB |
|---|---|---|---|---|
| WooCommerce 7.5.1 | 746 | 13 MB | 3.7 s | 1.0 s |
| WooCommerce 10.1.2 | 844 | 20 MB | 4.6 s | 1.1 s |
Next, let’s break down what exactly is consuming this time — which functions and files are responsible for the slowdown, and whether they’re actually needed.
To understand where WooCommerce was spending time on the product page, I profiled the real-world with version 10.1.2 using plugin Code Profiler Pro. The results were clear: the bloat isn’t just about file count or memory — it’s what those files do at runtime.
From the profiler output:
These aren’t just theoretical inefficiencies. They show up in TTFB and compound with every plugin and feature WooCommerce insists on loading globally, regardless of context.
WooCommerce is the case study here — but it’s just the tip of the iceberg. I used it because it makes it easier to demonstrate the point because of its size. But make no mistake — 99% of plugins contribute to this problem in some form. And yes—even those that claim to be performant, lightweight, optimized, and built by long-term community members and developers. The hype is real. But don’t just take my word for it—see for yourself how many files it required to load on a neutral page. I’ve yet to see a plugin truly developed to be lean and frugal in what PHP files it loads.
The narrative that “WordPress is slow” isn’t just perception — it’s becoming reality. And not because of WordPress Core, but because of how the ecosystem evolved without any backend loading discipline. The platform’s reputation suffers. And with AI and vibe coding, the worst is yet to come.
If this doesn’t change, WordPress risks going the way of Kodak, BlackBerry, Nokia, and others—once dominant, but ultimately unable to evolve within the very environment they helped define.
And yes, speaking of environment — there’s a real cost to this inefficiency. WordPress powers over 40% of the internet. The amount of electricity wasted on parsing, compiling, and executing unused PHP code on millions of requests per second word-wide is difficult to calculate — but undeniably massive. Optimising backend loading behaviour at scale wouldn’t just improve performance — it would have a measurable impact on the web’s carbon footprint.
This is about more than shaving off milliseconds. It’s about acknowledging that we’ve been ignoring the backend for too long, and it’s starting to catch up with us.
I originally used Plugin Optimizer to try to mitigate this — and eventually rewrote it into my own tool, Advanced Plugin Filter, because there was no way to control what didn’t need to load. As already mentioned, plugins filtering has its trade-offs not many users want to deal with. This mindset should be built into plugin development from the start.
If we want WordPress to survive and thrive in the years ahead, we need to get serious about backend performance—not only for speed, but also for sustainability, credibility, and the long-term health of the WordPress ecosystem.
Let's start the discussion! Let me know what you think in the comments section or through the contact form.
