Redis vs. Memcached for WordPress: Which Object Cache Should You Actually Use?

Sooner or later, anyone trying to speed up a WordPress site ends up asking whether they should go with Redis or Memcached.

Google it and you’ll get benchmark graphs, forum threads that go on for pages, and guides written for people who manage server clusters for a living. Probably useful stuff. Not much help if all you want to know is which one to switch on for your site.

So let’s keep it simple. If your host gives you both, pick Redis. If it only gives you Memcached, use Memcached and don’t lose sleep over it. For most WordPress sites the gap between them is small, and more often than not your hosting provider has already made the call for you.

Below, I’ll go through what each one does and the few places where the difference actually shows up. Then we’ll look at how to connect either one to FastPixel.

A quick refresher: what an object cache does

WordPress talks to its database constantly. Every page load pulls site options, menus, widget settings, user info, product data, and a lot more.

WordPress actually has its own object cache, but out of the box it only lives for one request. Once a page is done loading, whatever was cached gets thrown out, so when the next visitor comes in, WordPress asks the database for the exact same things all over again.

That’s what a persistent object cache changes. The data stays in memory after the request ends, so next time WordPress can grab it from there and skip the database unless it really needs to go there.

Redis and Memcached are the two tools most hosts use for this. Both keep data in RAM (that’s why they’re so quick), and WordPress talks to them through a small drop-in file, object-cache.php, in your wp-content folder.

Not sure if your site needs one? WordPress will usually point it out for you in Tools > Site Health.

Meet the contenders

Memcached dates back to 2003. It stores keys and values in memory, and that’s about it. Simple on purpose. It can spread work across multiple CPU threads, doesn’t need much in terms of resources, and there’s very little to configure.

Redis is younger (2009) and does a lot more. Besides basic key-value storage, it has other data types and logical databases, supports replication, and can optionally save data to disk. Admins also get more say in how memory is used.

Most of those extras were built with much bigger applications in mind than a WordPress blog or store.

Redis vs. Memcached at a glance

Feature	Redis	Memcached
Works as a WordPress object cache	Yes	Yes
Speed	Very fast	Very fast
Data types	Strings, plus lists, hashes, sets, etc.	Mostly simple key-value
Persistence	Optional (depends on server config)	No
Max item size	Up to 512 MB	1 MB by default
Logical databases	Yes	No
Eviction control	Several policies to choose from	LRU-based
Replication	Built in	Not natively
Default port	6379	11211
How often hosts offer it	Very often	Fairly often

On paper, Redis wins most of those rows. For WordPress, only a handful of them really matter.

Where the differences actually matter for WordPress

Speed is basically a tie

On a typical site, you won’t feel a difference between the two.

What you will feel is going from no persistent object cache to having one. Switching from Memcached to Redis after that rarely changes much.

The 1 MB limit

Out of the box, Memcached won’t store any single item bigger than 1 MB.

Most of what WordPress caches is tiny, so this doesn’t come up often. The one to watch is alloptions, a bundle of settings WordPress loads on every page. Install enough plugins, or a couple that dump lots of data into the options table, and it can creep past 1 MB. Memcached then simply skips it, and WordPress goes back to the database for one of the queries it runs most.

A server admin can raise that limit. On shared or managed hosting, though, that admin isn’t you.

Redis accepts much larger values, so it’s rarely a problem there.

Server restarts

Restart Memcached and the cache is gone. It starts empty and fills back up over time.

Redis can write its data to disk, if the server is set up that way.

It’s nice to have, but I wouldn’t pick Redis for this reason alone. Everything in an object cache can be rebuilt from the database, so an empty cache just means the database works a bit harder for a while.

Several sites on one server

This is where Redis has a practical edge. It supports logical databases, numbered 0, 1, 2, and so on, so whoever runs the server can give each site its own space. Your host may assign one to you.

Memcached doesn’t have that. Sites sharing a Memcached server are kept apart with key prefixes instead.

Both approaches work. Redis just gives the people managing the server more room to organize things.

Memory management

When the cache fills up, something has to go. Memcached sorts that out on its own with an LRU-based system, which basically means stuff nobody’s asked for in a while gets pushed out first.

Redis lets admins choose between several eviction policies. Your host normally handles this, and the defaults are fine either way.

So which one should you use?

Go with Redis if your host offers both, if your site is large or database-heavy, if you run several WordPress sites on the same server, or if your host recommends it.

Memcached is completely fine if it’s the only option you’ve got, if your site is fairly simple and doesn’t carry a bloated options table, or if you’re already using it and nothing’s broken.

I wouldn’t bother migrating a healthy site from Memcached to Redis. A longer feature list on its own isn’t a good reason to switch.

The part nobody mentions: your host decides

Most comparisons skip this bit. On shared or managed hosting, you generally can’t install Redis or Memcached yourself.

They run at the server level, much like page caching with NGINX or Varnish, outside of WordPress. PHP also needs the matching extension enabled, and that’s your provider’s side of things. If you’re on your own VPS or dedicated server, you can set them up yourself.

In practice, check what your host offers first. If both are there, pick Redis. If there’s only one, use that. If there’s neither, ask, because plenty of hosts will turn it on when requested or include it in a higher plan.

It’s usually tucked away in the control panel under something like Caching, Performance, or Services. You can also just message support: “Do you offer Redis or Memcached for object caching, and can you send me the connection details?”

Using Redis or Memcached with FastPixel

FastPixel supports both Redis and Memcached, so it doesn’t matter which one your host runs.

One thing worth being clear about: FastPixel doesn’t provide the Redis or Memcached service itself. It has to be running on your server, with the right PHP extension enabled, and your hosting provider gives you the details to connect to it.

Those details usually look something like this:

• Host: often 127.0.0.1 or localhost, or a hostname from your provider
• Port: 6379 for Redis and 11211 for Memcached are the defaults, but your host might use a different one
• Password: only if your host has authentication turned on
• Redis DB ID: if your host assigned your site a specific database number

Once you’ve got them:

1. Update FastPixel to the latest version.
2. In your WordPress dashboard, go to FastPixel > Object Cache.
3. Pick Redis or Memcached and fill in the connection details.
4. Adjust any extra options you need.
5. Save.

From there, FastPixel takes care of plugging the object cache into WordPress.

There are a few more settings you can tweak if you want: the default object lifetime, persistent connections, cache groups you’d rather not cache, caching for wp-admin operations, global groups for multisite networks, and whether transients should live in memory instead of the database. Our Object Cache documentation explains each one.

Page cache and object cache are not the same thing

People mix these up all the time, so it’s worth a quick detour. An object cache doesn’t replace page caching. They handle different parts of the job.

A page cache saves the finished HTML of a page. The next visitor gets that saved copy, and WordPress doesn’t have to build anything.

An object cache saves the bits of data WordPress needs while it’s building a page. That matters most on pages that can’t come straight from the page cache, like WooCommerce carts and checkout, member areas, anything a logged-in user sees, and the wp-admin dashboard.

FastPixel does page caching and can also connect WordPress to Redis or Memcached, so you get both layers working side by side.

How to check that your object cache is working

Once it’s switched on, give it a quick check.

Open Tools > Site Health first. If WordPress was nagging you about a persistent object cache before, that recommendation should be gone now.

Query Monitor, a free plugin, is handy for a closer look. It shows how many database queries each page runs and how the object cache is being used, and you should see that number drop on repeat loads.

Then test the parts of your site where object caching actually counts: logged-in pages, WooCommerce admin screens, anything database-heavy. Your homepage is a poor test, since it’s probably served from page cache already.

If the connection fails, check the port and password before anything else. Those two cause most of the trouble. Make sure the Redis or Memcached PHP extension is enabled, too. Still stuck? Your host’s support team can confirm whether the service is running and reachable from your site.

FAQs

Is Redis faster than Memcached for WordPress?

Not in a way you’re likely to notice on a typical WordPress site. Where Redis pulls ahead is features and flexibility.

Can I use Redis and Memcached at the same time?

Not on the same WordPress site. WordPress loads a single object-cache.php drop-in, so you pick one. If your hosting changes later, you can switch.

Do I still need page caching if I have an object cache?

Yes. Page caching serves the finished page, while object caching speeds things up when WordPress actually has to build one. On sites that benefit from both, they work well together.

Will object caching help a small blog?

A little, but not as much as on dynamic sites. If most of your visitors are anonymous readers getting cached pages, WordPress isn’t doing much database work for them anyway. Stores, membership sites, forums, and sites with lots of logged-in users get far more out of it.

Does FastPixel provide Redis or Memcached?

No. FastPixel connects to either one, but the service has to be available on your hosting server. Your host can tell you what’s available and send you the connection details.

Could object caching break my site?

It’s rare. A badly configured cache can sometimes serve stale data, so a setting you just changed might not show up right away. Flushing the object cache usually sorts it out, so try that first if something looks off.

The bottom line

Most of the Redis vs. Memcached debate is about infrastructure details that don’t really affect the average WordPress site.

If your host offers both, go with Redis. It copes better with large objects and gives you more ways to separate and manage cached data. If Memcached is what you have, use it without worrying.

What makes the bigger difference, on sites that benefit from object caching, is turning it on in the first place. Which of the two you pick comes second.

FastPixel supports both, so once your host sends over the connection details, you can simply use whichever option they provide.