What is an Object Cache? Redis and Memcached for WordPress explained

An object cache keeps the results of database queries in memory so WordPress does not have to fetch them from the database again on the next request. That sounds unspectacular. On shops, membership sites and anything where many visitors are logged in, though, it often makes the biggest difference to load time. WordPress does come with its own object cache, but that one forgets everything after every page load. Only with Redis or Memcached in the background does it become a persistent object cache that keeps data across many requests. In this article you will learn how that works in detail, how Redis and Memcached differ, when the effort pays off and which mistakes to avoid during setup.

What is an object cache in WordPress?

Every time someone opens a page on your website, WordPress assembles it from lots of individual pieces. It loads the site settings, the menus, the widgets, the post itself, the author data, categories, tags and everything your plugins need on top. Nearly all of that lives in the database (MySQL or MariaDB). A normal page easily adds up to 50 to 150 database queries, and with WooCommerce and a few larger plugins considerably more. Many of them ask exactly the same thing on every request: What is the site called? Which plugins are active? What does the main menu look like?

An object cache remembers the answers to questions like these. WordPress checks the cache first, and only if nothing is there does the query go to the database. The result is then stored in the cache and is ready instantly the next time. The name comes from the fact that WordPress does not store finished pages there, but individual data objects: a post, a list of options, the metadata of a user.

Think of a sticky note next to your keyboard. Instead of digging through the filing cabinet every time, you glance at the note first. For a single question that hardly saves any time. When the same question gets asked a thousand times a day, it saves a lot.

How does the WordPress object cache work?

WordPress has had its own class for the object cache for many years, WP_Object_Cache. WordPress core and many plugins talk to it through functions like wp_cache_get() and wp_cache_set(). The catch: without additional software, this cache only lives as long as a single page load. As soon as the page has been delivered, the memory is empty again, and the next visitor starts from scratch.

That does not make this temporary cache useless, because it prevents duplicate queries within one request. Things only get really interesting with a persistent object cache, though. For that, a file called object-cache.php sits in the wp-content folder. WordPress detects it automatically on startup and then uses an external service such as Redis or Memcached instead of its own temporary storage. The data stays there across many page loads until it expires, changes or the memory is full. You do not have to write this file yourself. Plugins like Redis Object Cache ship with it and put it in the right place when you activate them.

A side effect many people do not know about concerns transients. These are cached values with an expiry date that plugins like to use, for example for responses from external APIs. Without a persistent object cache, transients end up in the wp_options table and bloat it over time. With Redis or Memcached they move into memory instead, and the database stays leaner.

Object cache, page cache and OPcache: what is the difference?

As soon as the topic is WordPress and caching, three terms come up that are easily confused. They work on different levels and complement each other rather than replacing one another.

• Page cache: stores the complete, finished page as HTML and serves it without even starting WordPress. WP Rocket, LiteSpeed Cache and WP Super Cache work this way, for example. Nothing is faster, but only as long as all visitors see the same page.
• Object cache: stores individual results from the database. WordPress still runs on every request, but has to ask the database far less often.
• OPcache: has nothing to do with your data at all. It makes sure PHP does not have to read and compile the WordPress files again on every request. On almost every hosting plan it is already active today.

The most important point: a page cache only helps with pages that look the same for everyone. As soon as someone logs in, adds something to the cart or works in the backend, it is bypassed. That is exactly where the object cache steps in. For a blog with almost only anonymous readers, a good page cache therefore does more. For a shop, a learning platform or a forum, the object cache is often the bigger lever.

Redis vs. Memcached: which object cache is right for WordPress?

Both systems keep data in memory and store it as simple pairs of key and value. As an object cache, both are fast enough. The differences are in the details.

Redis is the usual choice for WordPress today. It can store more than just keys and values, for example lists, hashes and sets, and if you want it writes its contents to disk so the cache survives a restart. On top of that come replication, finer access control and a large ecosystem. For WordPress there is also Redis Object Cache, a very widely used and well maintained plugin. After a license change at Redis in 2024, Valkey was created as well, a free fork under the umbrella of the Linux Foundation that many hosting providers now use. For WordPress it behaves exactly like Redis, and as a rule you will not notice any difference.

Memcached is older and deliberately simple. It only knows keys and values, stores nothing permanently and loses its entire contents on every restart. In return it uses several CPU cores at once and is very easy to spread across multiple servers. One limit that occasionally shows up with WordPress: by default a single entry may be at most 1 MB in size. With very large options, such as the bloated settings of some page builders, that can cause problems.

Our recommendation: if your host offers both, go with Redis. If only Memcached is available, that is no reason to worry, it is perfectly sufficient as an object cache. Far more important than the choice between the two is that a persistent object cache is running at all and is configured sensibly. A third candidate, by the way, is APCu, a cache built right into PHP. It does not need a separate service, but only works on a single server and plays a smaller role in practice.

When is a persistent object cache worth it?

An object cache is not a miracle cure. How much it helps depends on how many requests bypass the page cache and land directly at WordPress, and how much work the database has to do for them. The effect is especially noticeable for:

• WooCommerce shops, because cart, checkout and customer account never come from the page cache.
• Membership sites, learning platforms and forums where many users are logged in.
• Editorial teams where several people work in the backend at the same time.
• Websites with many plugins that store their data in options and transients.
• Large websites with thousands of posts, terms or users.

WordPress itself gives you a hint here. Since version 6.1, the Site Health screen under Tools recommends a persistent object cache once your website exceeds certain sizes, for example more than 1,000 posts, comments or users.

On the other hand, an object cache does little for a small company website with ten pages that has almost only anonymous visitors and already uses a good page cache. There, the page cache answers nearly every request anyway, before WordPress even starts.

How do I set up an object cache with Redis in WordPress?

The exact path depends on your hosting. Many managed hosts already have Redis available and let you turn it on with a switch in their customer panel, and some even set everything up for you. When in doubt, ask support briefly before installing anything yourself. On your own server, it usually goes like this:

1. Install and start Redis, on Debian or Ubuntu for example with the redis-server package.
2. Install the phpredis extension for PHP (package php-redis) so PHP can talk to Redis. The plugin also ships with Predis, a variant that needs no extension at all, but it is noticeably slower.
3. Add the connection details to wp-config.php, above the line that marks the end of editing.
4. Install the Redis Object Cache plugin and enable the object cache in its settings. This creates the object-cache.php file.

define( 'WP_REDIS_HOST', '127.0.0.1' );
define( 'WP_REDIS_PORT', 6379 );
define( 'WP_REDIS_DATABASE', 0 );
define( 'WP_REDIS_PREFIX', 'mysite_' );
define( 'WP_REDIS_MAXTTL', 86400 );

Always set the prefix as soon as several websites share the same Redis instance. Without it, two installations can overwrite each other's data, and that leads to very strange errors. If you prefer the command line, the last step is done with wp plugin install redis-cache --activate followed by wp redis enable. For large shops there is also the commercial solution Object Cache Pro.

What are the most common object cache mistakes?

An object cache is quick to set up, but a few pitfalls come up again and again.

• No memory limit: without maxmemory, Redis grows until the server runs out of memory. With a limit but the default policy noeviction, Redis rejects new entries once memory is full, and WordPress suddenly throws errors. For a cache, allkeys-lru is the right choice: Redis then simply evicts the entries that have gone unused the longest.
• Redis open to the internet: Redis should only be reachable on 127.0.0.1 or a private network and should have a password. Open instances on port 6379 are actively searched for and abused.
• Stale data after direct changes: anyone who changes data directly in the database, for example with phpMyAdmin or during an import, bypasses the cache. WordPress then keeps showing the old values. Clear the cache afterwards, either in the plugin settings or with wp cache flush.
• A forgotten object-cache.php after a move: if you move to a server without Redis, the file sometimes stays behind in the wp-content folder. In the harmless case you only see a notice in the admin area, in the worst case WordPress stops with a fatal error. Deleting the file via FTP then helps.
• Redis on a remote server: every cache access then costs a trip across the network. With hundreds of accesses per page load, latency eats up part of the benefit again. Ideally Redis belongs on the same server, or at least in the same data center.

maxmemory 256mb
maxmemory-policy allkeys-lru

These two lines in redis.conf are enough for most websites. How much memory you need depends on the size of the website. For a typical shop, 256 MB is a good starting point.

How do I check whether the object cache is working?

There are several ways to see whether the cache is really doing its job:

• In the plugin: Redis Object Cache shows in its settings whether a connection exists and provides small statistics on hits and misses.
• On the command line: wp cache type tells you which object cache is active. If it says Default, no persistent cache is running.
• With Query Monitor: the free plugin shows the object cache hit rate and the number of database queries for every page load. Compare the values with and without the cache once, the difference is often bigger than expected.
• Directly in Redis: redis-cli info stats returns keyspace_hits and keyspace_misses, among other things. If the hit rate stays low even after a few hours of operation, something is usually wrong with the configuration, for example a memory limit that is too small.

How InspectWP helps you assess your website's caching

An object cache works on the server, so you cannot see it directly from the outside. Its effect, however, you can. The InspectWP report measures, among other things, the Time to First Byte, meaning how long the server takes until the first byte of the page arrives. InspectWP flags values above 800 milliseconds as a warning, and that is exactly where an object cache helps when the page does not come from the page cache. InspectWP also detects which plugins are used for caching, including Redis Object Cache, based on the short comment the plugin leaves in the source code by default. Together with the details about the hosting provider, the server and the PHP version, this quickly gives you a feel for whether a website's caching still has room for improvement.