Before we compare Redis and Memcached, let’s get honest: most WordPress sites asking this question don’t need either yet.

I see this at Rocket.net daily. Developers install Redis on shared hosting with 512MB RAM and wonder why their site crashes. Agencies set up Memcached clusters for static brochure sites that would be fine with just page caching.

This guide gives you a framework—not just a comparison. You’ll know if you need object caching, which to choose if you do, and when neither is actually the right answer.

First: Do You Actually Need Object Caching?

Object caching stores database query results in memory. Instead of asking MySQL “What’s the site title?” 50 times per page load, WordPress asks once and retrieves it from memory.

When object caching matters:

• Dynamic sites (WooCommerce, membership sites, forums)
• Logged-in traffic (page cache doesn’t help here)
• Complex queries (custom post types, meta-heavy sites)
• High-traffic admin (multiple editors working simultaneously)

When object caching is overkill:

• Static blogs (page cache handles this)
• Most brochure sites (same)
• Single-author sites (admin slowness is usually CPU, not database)

The test: Disable object caching temporarily. If you don’t feel the difference, you didn’t need it.

Redis vs Memcached: Head-to-Head

Factor	Memcached	Redis
Speed	Slightly faster for simple key-value	Negligible difference in practice
Data Types	Strings only	Strings, lists, sets, hashes
Persistence	Ephemeral (memory only)	Optional persistence to disk
Memory Efficiency	Slightly better	Good
WordPress Integration	Drop-in file	Plugin or drop-in
Complexity	Simpler	More features, more to configure

Here’s what that actually means for WordPress:

Data Types: Does It Matter?

Redis supports complex data structures (lists, sets, sorted sets). For WordPress object caching, this is mostly irrelevant—WordPress stores simple key-value pairs.

Persistence: Feature or Trap?

Redis can persist data to disk. Memcached loses everything on restart.

The trap: Redis persistence sounds like a safety feature. For WordPress object caching, it’s actually a performance risk. If Redis restarts and loads gigabytes of cache from disk, your site crawls until the cache rebuilds.

Memcached’s ephemerality is a feature, not a bug. Cache should be fast and disposable.

WordPress Integration

Memcached: The drop-in file is standard, maintained by WordPress core contributors, and Just Works on hosts that support it.

Redis: Requires the Redis Object Cache plugin or a custom drop-in. More setup, more options, more that can go wrong.

My Decision Framework

Choose Memcached If:

• Basic WordPress site, no WooCommerce
• Simple hosting environment
• You want the lowest-friction solution
• Your host offers it (cPanel usually has it)

Choose Redis If:

• WooCommerce or heavy dynamic content
• Multiple WordPress instances sharing cache
• You need cache analytics (Redis has better introspection)

Choose Neither If:

• Page cache is handling your traffic fine
• Database queries aren’t your bottleneck
• You’re on shared hosting with limited RAM

FAQ

Will object caching speed up my frontend?

Not directly. Page cache handles frontend speed. Object caching helps logged-in users and dynamic content.

Can I use both Redis and Memcached?

No—WordPress uses one object cache backend at a time.

Last updated: February 2026. I work at Rocket.net where we configure object caching automatically.

# Why Is My WordPress Admin So Slow? Real Causes + Fixes That Actually Work

If you’ve ever stared at a spinning WordPress dashboard while trying to publish a post, you know the frustration. The frontend of your site might load fine, but the backend—the place where you actually work—feels like wading through molasses.

I see this pattern daily at Rocket.net. Sites migrate to us with “optimization plugins” stacked five deep and caching layers that do nothing for the admin experience. The problem isn’t always what you think.

This guide cuts through the generic advice. We’ll diagnose where your slowness actually lives, identify the real culprits (not just symptoms), and give you fixes that match your technical reality.

—

## First, Diagnose Where the Slowness Lives

Before you install another plugin or change hosts, answer three questions:

**Is it every admin page or specific ones?**
– Every page = server-level or global WordPress issue
– Specific pages = plugin conflict or query-heavy functionality

**Is it consistent or random?**
– Consistent = configuration or resource limitation
– Random = background processes, scheduled tasks, or server load

**Does it happen at specific times?**
– Scheduled backups running
– Cron jobs firing
– Traffic spikes hitting shared resources

There’s no point optimizing for database queries if your real problem is CPU throttling. Get specific before you get busy.

—

## The Real Culprits (In Order of Likelihood)

### 1. Admin-ajax.php Flooding (Most Common)

WordPress uses admin-ajax.php for asynchronous updates—the Heartbeat API that auto-saves posts, shows plugin notifications, and keeps your dashboard “live.”

**The problem:** Plugins abuse this endpoint. Page builders, real-time analytics dashboards, and poorly coded tools can fire dozens of requests per minute. On shared hosting with limited PHP workers, this creates a traffic jam.

**How to check:**
1. Open Chrome DevTools (F12)
2. Go to Network tab
3. Filter by “XHR”
4. Navigate around your admin
5. Count admin-ajax.php requests and their timing

If you see 5+ requests loading slowly (>500ms each), you’ve found your bottleneck.

**The nuanced fix:**

Don’t just disable Heartbeat—that breaks auto-save and real-time collaboration features. Instead:

1. **Install Query Monitor** (free plugin)
2. Check which plugins are triggering admin-ajax calls
3. Plugin-specific solutions:
– Heartbeat Control plugin (selective rate limiting)
– Disable for non-essential users
– Limit to post editor only

**The insight I see at Rocket.net:** Most “admin slow” complaints resolve when we move sites here because our PHP worker limits are generous. But the underlying plugin behavior should still be fixed—you’re just masking the problem with better hardware.

—

### 2. Plugin or Theme Conflict

**Quick conflict check protocol:**

1. Rename `/wp-content/plugins` folder to `plugins-old`
2. Create new `plugins` folder
3. Does admin speed up? You’ve found the culprit category
4. Move plugins back 3-5 at a time until slowness returns
5. That batch contains your problem

**Common offenders I see:**

– **Backup plugins running scheduled jobs**: UpdraftPlus, BlogVault, BackupBuddy firing during your work hours
– **Security plugins with real-time scanning**: Wordfence admin-side scans consuming resources
– **Page builders loading in editor**: Elementor, Divi, Beaver Builder loading full frontend assets in backend
– **Analytics dashboards**: Jetpack stats, Google Analytics plugins querying massive datasets

**Theme-specific issues:**

Some themes load custom font libraries, icon sets, or entire frontend frameworks in the admin. Check if the slowness persists with a default theme (Twenty Twenty-Four) activated.

—

### 3. Server Resource Limits (The “CPU Steal” Problem)

Here’s what most generic guides won’t tell you: your admin might be slow because you’re being throttled.

**What CPU steal is:** On shared hosting (and even some “cloud” hosts), your CPU time is shared with other accounts. When neighbor sites spike, the hypervisor takes cycles from you. You can’t see this in typical WordPress dashboards, but it’s brutal for admin performance.

**How to check:**

If you have SSH access:
“`
top
“`

Look for “st” (steal time) in the CPU line. If it’s consistently above 10%, you’re being throttled.

**The real test:**
1. Export your site via All-in-One WP Migration (or similar)
2. Import to a local server (LocalWP, Laravel Valet, etc.)
3. Is admin fast locally? It’s your host, not your site.

**When to change hosting vs. fix your site:**

– CPU steal present + simple site (under 20 plugins) = hosting problem
– CPU steal absent + admin still slow = optimization problem
– WooCommerce + shared hosting = both (Woo needs resources)

—

### 4. Database Bloat and Slow Queries

WordPress databases accumulate cruft: post revisions, spam comments, transient options, orphaned metadata.

**The silent killer: wp_options bloat**

Transients and autoloaded options can balloon your database. I’ve seen sites with 500MB+ `wp_options` tables where WordPress has to load the entire thing on every admin request.

**Check your database size:**

Install Query Monitor and look at the “Queries by Component” tab. If you’re seeing 1000+ queries on a simple admin page, that’s your problem.

**Quick database cleanup:**

“`sql
— Delete old post revisions (keep last 5)
DELETE FROM wp_posts WHERE post_type = ‘revision’ AND ID NOT IN (SELECT * FROM (SELECT ID FROM wp_posts WHERE post_type = ‘revision’ ORDER BY ID DESC LIMIT 5) AS temp);

— Delete spam comments
delete FROM wp_comments WHERE comment_approved = ‘spam’;

— Delete trash comments
delete FROM wp_comments WHERE comment_approved = ‘trash’;
“`

**Or use WP-CLI:**
“`
wp transient delete –expired
wp post delete $(wp post list –post_status=trash –format=ids)
“`

**Prevent future bloat:**

Add to `wp-config.php`:
“`php
define(‘WP_POST_REVISIONS’, 5);
define(‘AUTOSAVE_INTERVAL’, 120);
“`

—

### 5. Missing Object Cache

Here’s the technical truth: WordPress is database-heavy. Without object caching, every admin page load queries MySQL dozens (or hundreds) of times for the same data.

**Object cache explained simply:** Instead of asking the database “What’s the site title?” 50 times per page load, WordPress asks once, stores the answer in memory (Redis/Memcached), and retrieves it from there.

**Symptoms you need object caching:**
– TTFB is fine but Time to Interactive is slow
– Database CPU is high on your host dashboard
– Admin feels sluggish even on fast hosting

**The fix:**

If you’re on **Rocket.net**: Object caching is enabled by default. You’re done.

If you’re on **shared hosting**: Ask your host if they support Redis or Memcached. Most don’t on entry-level plans.

If you’re on **VPS/Cloud**: Install Redis and the WP Redis plugin, or use the Memcached Object Cache drop-in.

**Important:** Object caching helps, but it won’t fix a bloated site. Clean your database first.

—

## Quick Wins (Do These First)

Before diving deep, try these 80/20 fixes:

1. **Install Query Monitor** — See what’s actually slow, not what you think is slow
2. **Check Heartbeat frequency** — Install Heartbeat Control, set to 60 seconds in Dashboard only
3. **Limit post revisions** — Add the `WP_POST_REVISIONS` line to wp-config
4. **Disable unused dashboard widgets** — In Screen Options, uncheck everything you don’t use
5. **Check for scheduled tasks** — Admin Tools → Scheduled Actions (if WooCommerce) — look for stuck or frequent jobs

—

## When to Stop Optimizing and Change Hosting

I’ve spent hours optimizing sites that just needed better hosting. Here’s my 500ms rule:

**If your TTFB (
Time to First Byte) is consistently >500ms on admin pages, even after plugin cleanup:**

Your hosting is likely the bottleneck. Here’s when to make the move:

| Hosting Type | Admin Speed Expectation | When to Upgrade |
|————–|————————|—————–|
| $3-10/mo Shared | 800ms-2s+ TTFB | Always (this is the problem) |
| $15-25/mo Managed | 300-500ms TTFB | If you have WooCommerce or 20+ plugins |
| $30-50/mo Premium | 150-300ms TTFB | Only if still slow after optimization |

**Reality check:** Most “admin slow” complaints I see at Rocket.net come from sites on hosts that advertise “unlimited” everything but throttle CPU at 10%. The optimization plugins can’t fix what the host broke.

**If you’re hitting resource limits, don’t keep optimizing—upgrade.**

[If you’re curious about managed WordPress hosting, I work at Rocket.net and we handle migrations and optimization as part of our service.]

—

## When You’ve Tried Everything: The Service Option

Some admin slowness requires server-level diagnostics: MySQL slow query logs, PHP profiling, opcode cache analysis.

**You might need expert help if:**
– You’ve disabled all plugins and admin is still slow
– Your host says “everything looks fine on our end”
– You’ve hit a wall and don’t have SSH access to dig deeper

I offer a fixed-price WordPress optimization service specifically for these situations: server-level diagnostics, database optimization, and a prioritized fix list.

[Rocket Engine WordPress Speed Diagnostic]

—

## FAQ

**Will a page cache plugin fix admin slowness?**

No. Page caching only speeds up what visitors see (the frontend). Admin pages are dynamic and bypass page cache by design. “WP Rocket” doesn’t help your dashboard.

**How do I know if it’s my host or my site?**

Export your site (All-in-One WP Migration), import it to LocalWP (free desktop app), and test admin speed. If it’s fast locally, it’s your host. If it’s still slow, it’s your site configuration.

**Is WP Rocket supposed to help admin?**

No—WP Rocket is specifically for frontend page caching. However, WP Rocket’s “Heartbeat Control” feature (in advanced settings) can help if admin-ajax.php is your bottleneck.

**Can I just increase PHP memory limit?**

Only if you’re hitting memory limits. Check your PHP error logs for “allowed memory size exhausted.” Arbitrarily increasing memory without knowing the root cause masks problems rather than fixing them. Most admin slowness is CPU or database, not memory.

**What’s the most common fix you see work?**

Limiting post revisions and cleaning the wp_options table. Second most common? Getting off shared hosting that throttles CPU.

—

## Summary: Your Action Plan

**Step 1:** Install Query Monitor and identify if admin-ajax.php or database queries are the culprit.

**Step 2:** If admin-ajax.php is high, use Heartbeat Control to throttle it selectively.

**Step 3:** If database queries are high, clean revisions and transients.

**Step 4:** If TTFB is >500ms consistently, test locally to confirm hosting is the issue.

**Step 5:** If you’ve hit a wall, consider server-level diagnostics.

—

*Last updated: February 2026. I work at Rocket.net and see these patterns daily. These recommendations come from troubleshooting WordPress at enterprise scale.*

Breeze vs W3 Total Cache: Which Free Cache Plugin Wins in 2026?

Caching is essential for WordPress performance, but choosing the right plugin can feel overwhelming. Two free options dominate the conversation: Breeze Cache and W3 Total Cache. In this comparison, I will break down which one deserves your attention based on setup complexity, performance, and long-term reliability. By the end, you will know exactly which cache plugin to install.

Quick Comparison: At a Glance

Feature	Breeze	W3 Total Cache
Setup Difficulty	Easy	Complex
Defaults	Optimized out-of-box	Requires tuning
Origin	Cloudways	Independent
Best For	Beginners	Tweakers

Breeze prioritizes simplicity with smart defaults that work immediately. W3 Total Cache offers granular control but demands technical knowledge to configure correctly. Choose based on your comfort level.

Breeze Cache: Deep Dive

Breeze Cache originated from Cloudways managed hosting, designed specifically for their platform but available to all WordPress users. The philosophy is simple: caching should just work without endless configuration panels.

Setup and Configuration

Install Breeze from the WordPress repository and activate it. Upon activation, basic caching is already enabled. The settings panel has three tabs: Basic, Advanced, and CDN. Most sites only need the Basic tab. For beginners, the default settings deliver solid performance immediately. Advanced users can tweak minification, group files, and database options, but it is not required.

Performance Benchmarks

In standard tests, Breeze consistently delivers sub-second Time to First Byte on shared hosting. Page load times typically drop 40-60% after activation. The plugin handles minification cleanly without breaking layouts, a common problem with aggressive cache plugins.

Pros and Cons

• Pros: Zero-configuration defaults, clean interface, Cloudways integration, reliable minification, fast support response
• Cons: Fewer advanced options, limited CDN integration options, newer plugin with smaller community

W3 Total Cache: Deep Dive

W3 Total Cache is the veteran of WordPress caching, established over a decade ago. It pioneered many caching techniques now standard across plugins. However, that legacy means complexity.

Setup and Configuration

W3 Total Cache presents a dashboard with dozens of options spread across multiple pages. You will choose between various caching methods: disk, APC, memcached, redis. Each section requires decisions about what to cache and how. Misconfiguration is common and can break your site or deliver worse performance than no caching at all. The plugin assumes you understand web performance concepts before you start.

Performance Benchmarks

When configured correctly, W3 Total Cache is powerful. It can match or exceed Breeze performance with the right settings and hosting environment. However, default settings are conservative and manual optimization is required to see benefits approaching premium plugins.

Pros and Cons

• Pros: Extensive customization, multiple caching backends, CDN integration options, established community, proven track record
• Cons: Steep learning curve, overwhelming interface, easy to misconfigure, slower support response, occasional compatibility issues

Side-by-Side Feature Comparison

Feature	Breeze	W3 Total Cache
Page Caching	Yes	Yes
Browser Caching	Yes	Yes
Database Optimization	Basic	Advanced
Object Caching	No	Yes
CDN Integration	Built-in	Requires config
Minification	Auto	Manual
Lazy Load	Images only	No
Group Files	Yes	Yes

Which One Should You Choose?

Choose Breeze Cache if you want performance gains without technical complexity. It is ideal for small business sites, blogs, and anyone who prefers set-it-and-forget-it optimization.

Choose W3 Total Cache if you enjoy tweaking server configurations and have time to learn its extensive options. It suits developers and advanced users who need fine-grained control over every caching layer.

Setting Up Your Chosen Plugin

For Breeze: Install, activate, and you are done. Optionally enable minification in the Advanced tab if your layout handles it. Clear cache after any theme or plugin updates.

For W3 Total Cache: Start with Page Cache enabled using Disk: Enhanced method. Enable Browser Cache. Test minification carefully as it frequently breaks layouts. Enable Object Cache only if you understand object caching or use a plugin requiring it. Always test your site after each settings change.

Conclusion

Both Breeze and W3 Total Cache can significantly improve WordPress performance. Breeze delivers faster wins with less risk for most users. W3 Total Cache rewards technical users willing to invest time in optimization. For reliable performance without headaches, Breeze is the 2026 recommendation.

When you outgrow free caching plugins, consider upgrading to WP Rocket or NitroPack for additional features and dedicated support. Both handle edge cases better and include advanced optimizations unavailable in free options.

Which cache plugin are you using? Share your experience in the comments below.

How to Fix a 4s+ admin-ajax.php Delay (CPU Steal vs Plugin Issues)

Have you ever clicked Save or Update in WordPress and watched a spinning wheel turn for 4, 5, even 8 seconds? That agonizing wait almost always traces back to a single file: admin-ajax.php. Before you start deleting plugins or blaming your host, you need to know exactly what is causing the delay. In this guide, I will walk you through a systematic approach to diagnose whether the culprit is a misbehaving plugin or CPU steal from your hosting provider. By the end, you will have actionable steps to restore snappy admin performance.

What admin-ajax.php Actually Does

admin-ajax.php is WordPress built-in handler for asynchronous requests. Every time your post autosaves, a widget refreshes, or a page builder updates in real time, admin-ajax.php processes that request behind the scenes. It lives in your wp-admin directory and acts as the bridge between your browser and the server, enabling dynamic interactions without full page reloads.

Under normal conditions, these requests complete in under 500 milliseconds. The problems start when plugins fire excessive AJAX requests, run inefficient database queries, or when your server lacks resources to process requests promptly. Understanding this mechanism is crucial because it tells us where to look when things go wrong.

Plugin Issues vs CPU Steal: How to Tell

Not all delays are created equal. Plugin-related slowdowns typically appear during specific actions like saving posts or using page builders. They happen consistently and correlate with particular workflows. CPU steal, on the other hand, manifests as sporadic delays across all admin-ajax operations, often worse during peak hours.

The key difference is consistency. Plugin issues are usually intermittent and tied to specific actions, while CPU steal creates a persistent slowdown regardless of what you are doing. Understanding this distinction determines your fix strategy, as the solutions are completely different.

Diagnosis Step-by-Step

Check 1: Browser DevTools Network Tab

Open your WordPress admin and press F12 to open DevTools. Click the Network tab and trigger the slow action. Look for admin-ajax.php requests in the list. Click any request to examine the Timing breakdown. If Waiting (TTFB) exceeds 4000ms, your server is struggling to generate the response. Check the Payload tab to see which plugin triggered the request.

Check 2: CPU Steal Detection via SSH

SSH into your server and run this command to check CPU steal:

top -bn1 | grep "Cpu(s)"

Look for the st column (steal time). Consistently seeing values above 10% indicates your host is overselling resources. Values above 30% explain why admin-ajax.php crawls. Run this command multiple times throughout the day, especially during peak hours, to confirm the pattern.

Check 3: Query Monitor Plugin

Install Query Monitor from the WordPress repository. Once activated, it adds a toolbar showing query count and execution time. Trigger a slow admin-ajax action, then check the AJAX section. Look for slow queries taking over 100ms, duplicate queries, and which plugins triggered them. Query Monitor reveals exactly which functions are causing delays.

Fixing Plugin-Related Issues

Once Query Monitor identifies the problematic plugin, start with the toggle method. Deactivate all plugins, then reactivate them one by one while monitoring admin-ajax.php timing. When latency spikes, you have found your offender.

For plugins relying on the WordPress Heartbeat API, throttle the frequency by adding this to your functions.php:

add_filter( 'heartbeat_settings', function($settings) {
 $settings['interval'] = 60;
 return $settings;
} );

This changes the Heartbeat API from its default 15-second interval to 60 seconds, dramatically reducing admin-ajax.php calls. Consider Perfmatters for granular control over Heartbeat across different admin screens.

Fixing CPU Steal and Hosting Issues

If CPU steal is your diagnosis, no plugin cleanup will help. You are on shared or virtualized hosting that is oversold. The only solution is upgrading your infrastructure.

Cloudways provides cloud-based VPS with guaranteed CPU allocation and no steal time. Resources are dedicated to your instance and you can scale vertically in minutes. Rocket.net offers edge-cached WordPress hosting with virtually unlimited CPU resources and enterprise-grade infrastructure. Both eliminate the noisy neighbor problem entirely.

Symptom	Plugin Issue	CPU Steal
Timing	Intermittent	Consistent
Pattern	Specific actions	All admin-ajax calls
Peak Hours	Consistent	Worse during peak
Fix	Optimize or replace	Change hosting

Conclusion

Slow admin-ajax.php requests stem from either plugin inefficiency or CPU steal. Use DevTools for initial diagnosis, SSH for CPU verification, and Query Monitor to pinpoint plugin culprits. Fix plugins by optimizing or replacing them; fix CPU steal by upgrading to quality managed hosting. Your WordPress admin will thank you.

What is your experience with admin-ajax.php slowdowns? Share which diagnostic step revealed your culprit in the comments below.