DEV Community

Cover image for Your WordPress Site Is Bleeding Memory — Here's How to Stop It
Prakhar
Prakhar

Posted on

Your WordPress Site Is Bleeding Memory — Here's How to Stop It

#wordpress #webdev #performance #wordpressplugin

Your WordPress Site Is Bleeding Memory — Here's How to Stop It

Why your site might be slower than you think, and what you can do about it.

"Why is my site so slow?"

If you've worked with WordPress for any amount of time, you've heard this question. Maybe from a client. Maybe from yourself at 2am trying to figure out why a page takes 8 seconds to load.

The frustrating part? The answer is almost never simple.

Want the quick fix?

I built a free plugin called Hungry Resource Monitor that shows you exactly what's eating your resources. It tracks memory, finds bloated databases, spots orphaned crons, and tells you which plugins are the heaviest. If you don't want to read this whole thing, just install it and see for yourself.

But if you want to understand why WordPress sites get slow, keep reading.

What Actually Happens When Someone Visits Your Site

When a visitor loads a page, WordPress does a lot behind the scenes:

  1. PHP starts up and loads all the WordPress files
  2. Every active plugin gets loaded — even if it's not needed for that page
  3. Your theme loads
  4. WordPress hits the database a bunch of times
  5. All your hooks and filters run
  6. The page gets assembled and sent out

Each step uses memory and takes time. The more plugins you have, the more this adds up.

The Memory Thing

PHP has a memory limit — usually 128MB or 256MB. If a page load uses more than that, you get the dreaded:

Fatal error: Allowed memory size of 134217728 bytes exhausted
Enter fullscreen mode Exit fullscreen mode

But here's the thing: you might not hit that limit, and your site can still be slow. A page using 100MB of memory is going to feel sluggish compared to one using 30MB.

What uses the most memory?

  • Page builders (Elementor, Divi, WPBakery) — these can easily use 50-80MB
  • WooCommerce with lots of products
  • Plugins that load big libraries they don't really need
  • Badly written custom code

The Database Thing

WordPress stores almost everything in the database: posts, settings, user info, plugin data. Every time it needs something, it runs a query.

A fast site might run 20-30 queries per page. I've seen sites running 500+ queries on a single page. That's insane.

Where do all these queries come from?

  • Plugins that aren't optimized
  • Themes that query the same data over and over
  • Poorly written custom code
  • Just... too many plugins doing too many things

The Bloat Problem

WordPress databases get fat over time. Here's why:

Revisions

Every time you hit save on a post, WordPress keeps a copy. Edit a post 50 times? That's 50 revisions sitting in your database. I've seen sites with 10,000+ revision rows. They all add up.

Orphaned Stuff

When you delete a post, WordPress usually cleans up after itself. But not always. Custom code and some plugins leave behind "orphaned" data — rows in the database that reference things that don't exist anymore.

I once cleaned a database where 40% of the postmeta table was orphaned junk.

Transients

These are temporary cached values. The problem is, some plugins create transients that last forever or don't get cleaned up when they expire. Over time, you end up with thousands of useless rows.

Auto-Drafts and Trash

WordPress creates auto-drafts as you write. Deleted items sit in trash for 30 days. On busy sites, these pile up fast.

The Cron Problem Nobody Talks About

WordPress has a scheduling system called wp-cron. It runs background tasks like publishing scheduled posts, sending emails, or cleaning up old data.

Here's the problem: when you delete a plugin, its scheduled tasks often stick around.

These "orphaned crons" try to run code that doesn't exist anymore. They waste resources and sometimes cause errors.

I've seen sites with 100+ orphaned cron jobs from plugins that were deleted years ago. Still running. Still trying. Still failing.

How to Actually Fix This

You've got a few options:

1. Use a Monitoring Tool

You can't fix what you can't see. Tools like Query Monitor are great for developers doing deep debugging. But if you want something simpler that just shows you what's wrong, try Hungry Resource Monitor.

It gives you:

  • A dashboard showing your top resource consumers
  • Easy database cleanup (revisions, transients, orphaned data)
  • A list of all your cron jobs with orphaned ones highlighted
  • Unused plugins and themes that are just taking up space
  • Weekly email reports so you don't have to keep checking

Full disclosure: I built it. But it's free and it works.

2. Limit Revisions

Add this to your wp-config.php:

define('WP_POST_REVISIONS', 5); // Keep only 5 revisions per post
Enter fullscreen mode Exit fullscreen mode

3. Clean Up Regularly

Whether you use a plugin or WP-CLI, schedule regular cleanups. Get rid of old revisions, expired transients, and orphaned data.

4. Audit Your Plugins

Do you really need all of them? Every plugin you deactivate is one less thing loading on every page.

5. Check Your Autoloaded Options

WordPress loads certain options on every single page load. If plugins store huge amounts of data with autoload enabled, it slows everything down. You can check this with:

SELECT option_name, LENGTH(option_value) as size
FROM wp_options
WHERE autoload = 'yes'
ORDER BY size DESC
LIMIT 20;
Enter fullscreen mode Exit fullscreen mode

The Bottom Line

WordPress performance isn't about finding one magic fix. It's about understanding where your resources are going and cleaning up the mess that accumulates over time.

Start with visibility. Once you can see what's actually happening, the fixes usually become obvious.

Give Hungry Resource Monitor a try. It's free, stores everything locally (no data sent anywhere), and it might show you things about your site you didn't know.

Prakhar Bhatia builds WordPress stuff at nandann.com.

Top comments (0)