WordPress Use a Persistent Object Cache

In WordPress under Tools > Site health you will sometimes see a message saying “you should use a persistent object cache”.

In this post I’ll be talking about what a persistent object cache is, what it does, how you make use of a persistent object cache when using WordPress and the benefit you’ll see by doing so.

What you’ll see in WordPress if you’re not using a persistent object cache.

If you log in to your WordPress, then hover your mouse over “Tools” in the menu on the left hand side, you’ll see a “Site Health”:

And if you click on “Site health” you’ll often see the “you should use a persistent object cache” message:

But what is a persistent object cache? What does it do? How can you use a peristent object cache? And why would you want to make use of a persistent object cache?

I’ll be answering these questions in this post.

What is a persistent object cache?

For this to make sense, it helps to know that when the page of a WordPress site is requested, the PHP that makes up the WordPress installation is executed, this interacts with the database, and the two combine to generate page output. What follows makes more sense if you understand that this is what’s taking place in WordPress.

A persistent object cache is a mechanism used to store and retrieve objects in a persistent manner. In the context of caching, an object refers to a data structure or an instance of a class that holds data and methods to operate on that data.

Roughly translated and put in to the context of WordPress, the object cache is a mechanism that allows for the caching of data at the level of PHP objects (the programming language that WordPress is written in), and the results of database queries.

What this means is that instead of having to go through the whole, PHP execution, and database interaction to generate page output, parts (objects) of what’s been done already can be “remembered” (cached) and referred back to (retreived from the object cache).

Imagine that you have to do a sum to work out something like how many tiles you’ll need to tile a bathroom, the sum would be:

(Height of wall 1 x width of wall 1 / area of single tile = number of tiles for wall 1) + (height of wall 2 x width of wall 2 / area of single tile = number of tiles for wall 2) + (height of wall 3 x width of wall 3 / area of single tile = number of tiles for wall 3) + (height of wall 4 x width of wall 4 / area of single tile = number of tiles for wall 4) = Total number of tiles needed to tile bathroom.

Obviously, you can work this out as per the above… but imagine if you get the answer, then forget it, then need to work it out again. Normally, you’d have to work out the whole sum again, but if some of the above has been “remebered” (cached) you don’t need to do the entire sum again as above. If the number of tiles for each wall has been “remebered” (cached) your sum becomes a lot more simple:

Number of tiles for wall 1 + number of tiles for wall 2 + number of tiles for wall 3 + number of tiles for wall 4 = total number of tiles.

This is (roughly speaking) how object caching works. Part of the “sums” used to generate page output are “remebered” (cached) so that the sum of a page call doesn’t have to be worked out in entirety. Parts of what’s been “remebered” (cached) can be used to make the “sum” less laborious and therefore be worked out faster.

When you use an object cache in WordPress, various types of data can be cached, some examples of what might be cached by the object cache in WordPress are:

Database Queries: Results of frequently executed database queries can be cached. This includes queries for retrieving posts, pages, comments, and other types of content.
Results of Expensive Operations: If your WordPress site performs complex operations or calculations to generate certain data, the results of these operations can be cached to avoid recomputing them on every request.
Serialized Data: Some plugins or themes may store complex data structures as serialized PHP objects. Caching these serialized objects can help improve performance.
Metadata: Metadata associated with posts, users, or other WordPress entities can be cached. For example, the metadata for a post might include information like the post’s author, publication date, and custom fields.
Query Results: The results of complex queries, especially those involving custom post types or taxonomies, can be cached to avoid repeating the same queries.

The benefits of using a persistent object cache with WordPress.

The main benefit of using a persistent object cache in your WordPress is an improvement in performance. This can have a positive effect when it comes to optimisting your WordPress installation.

Really, what the “you should use a persistent object cache” message displayed in the site health section of WordPress means is “you should use a persistent object cache to improve the performance of your WordPress site”.

If you take the sum analogy that I’ve used above, and consider that page output generated by your WordPress is effectively a giant sum, then the net result of using a persistent object cache in your WordPress installation would be:

It takes less time to do the page output “sum” when using object caching, as parts of the sum have already been rememebred.

How effective a persistent object cache will be when it comes to performance is really dictated by what your “sum” to generate page output is in the first place.

If we compare two websites, one being a 4 page portfolio with a contact form, that’s been made using a light web builder and a minimal plugin set, and the other being a monster of a WooCommerce based e-commerce site site, with 40 plugins installed, the sums for each of these aren’t exactly going to be the same.

As the “sum” of the portfolio site’s page output is already quite small, the effect of using object caching on a site built in this manner will also be quite small. This is because it’s effectively parts of a sum that wasn’t that complex in the first place that are being cached.

The “sum” of the e-commerce based site is going to be a lot more complex, simply because of the number of plugins and WooCommerce being used to manage products, orders, customer accounts, and the site itself, all within the WordPress installation. As this “sum” is more complex, caching parts of it are likely to have more positive effect on performance compared to the portfolio site.

What it is that provides a persistent object cache.

What I’ve mentioned above talks about what object caching is and what it does in the context of WordPress. But what is it that actually provides the object cache?

Both Redis and Memcached provide object caching. Both are services that can either be installed directly on web hosting servers, or they can be installed on their own standalone servers.

To make use of either Redis or Memcached the service needs to be installed and running, and PHP modules are needed to allow PHP to interact with either.

As well as the object caching service, and the respective PHP module being required, WordPress also needs to be configured to use object caching (it doesn’t do this JUST from the PHP modules and service being installed alone).

Unless you’re operating your own server you won’t be able to install Redis or Memcached, and maybe not the PHP modules for either in addition.

If you’re not using your own server it’s possible that you’ll only be able to do the WordPress configuration part, to make use of object caching. Obviously, the object caching service and the PHP modules need to be available for you to be able to configure your WordPress to make use of a persistent object cache.

So if you can’t install some of the required elements how can you check if a persistent object cache is available?

Should you use Redis or Memcahed?

Whether you should use Redis or Memcahed depends on your caching needs (that’s helpful isn’t it?).

When it comes to using Redis or Memcached with WordPress, both can provide object caching to improve performance. There are, however, some differences between the two, and the choice is likely depend on your requirements and preferences. Here are some considerations you might consider:

Data Types and Data Storage Models:

Redis: Redis is often referred to as a “data structure server” because it supports various data types such as strings, hashes, lists, sets, and more. It allows for more complex data structures to be stored, making it versatile for various use cases beyond simple key-value storage.
Memcached: Memcached is designed for simple key-value pair storage. It doesn’t support complex data types, and each value is treated as an opaque blob. It is more straightforward and lightweight compared to Redis.

Persistence:

Redis: Redis provides options for data persistence, allowing data to be stored on disk. This means that data can survive a system restart. If you have data that you want to persist across server reboots, Redis might be a better choice.
Memcached: Memcached is an in-memory caching system with no built-in support for persistent storage. If persistence is not a requirement for your caching needs, Memcached could be a straightforward choice.

Ease of Use:

Redis: Redis has a richer set of commands and features, but this can also make it more complex. It provides additional functionalities beyond caching, and if you’re comfortable with Redis, you may find it more versatile.
Memcached is simpler and has a more straightforward API. If you’re looking for a caching solution that’s easy to set up and use without additional complexities, Memcached might be a good fit.

The choice between Redis and Memcached for WordPress largely depends on your WordPress, what it does and how you use it, which is all very variable.

Both Redis and Memcached can effectively serve as object caching solutions for WordPress, and the “better” option can vary based on your needs. The might help you decide:

Use Redis if:

Data Types and Advanced Features: You need support for a variety of data types and more advanced features beyond simple key-value pairs.
Persistence: You want the option for data persistence to survive server restarts.
Versatility: You’re looking for a versatile data store that can serve purposes beyond caching, such as acting as a message broker, pub/sub system, or supporting more complex data structures.

Use Memcached if:

Simplicity: You prefer a simple and straightforward caching solution with a basic key-value storage model.
Lightweight: You want a lightweight solution that is easy to set up and use without additional complexities.
Specific Caching Requirements: Your caching needs in WordPress are straightforward, and you don’t require the more advanced features provided by Redis.

Checking to see if a persistent object cache is available.

If you’re operating your own server, you’ll know if you have object caching available, as it will have been you that installed the object caching service and the respective PHP modules. If you’re using shaed hosting on the other hand, how would you know if object caching is available?

The obvious answer is to ask your hosting provider if object caching is available to your site, and if it is, what the settings are that you’d need to use to make use of object caching (more on the settings in a moment).

That said, there are other ways that you can check to see if object caching is available, and one of these is by using PHP’s built in phpinfo() function.

The phpinfo() function is used to display the local PHP environment, and it can be used to check to see which PHP modules are available in your hosting. Therefore, you can use phpinfo() to check to see if the redis or memcached PHP modules are available, and if they are, it strongly suggests that object caching is available on the platform used to host your WordPress site.

Using phpinfo() to check for object caching.

Using a phpinfo() to check for object caching is quite straight forward.

Within the file manager in your hosting navigate to the document root of your domain, then create a new file:

Name the new file phpinfo.php and then create it:

Then right click on the phpinfo.php file, and select edit:

Now we need to add the phpinfo() to the file, so enter this:

<?php phpinfo(); ?>

And then save your changes:

Now if you browse to https://addressofyoursite.com/phpinfo.php you’ll see the local PHP environment displayed:

That’s a big page of PHP environment isn’t it? Don’t get too bogged down with it all, what you’re looking for is a section that mentions either Memcached:

Or Redis:

What the above means is that the Redis and Memcached PHP modules are both installed.

Although this does mean that it’s likely that Redis and/or Memcached are available, it’s possible that it might JUST be the PHP modules that are installed, but not the underlying service (if your hosting provider has only installed the modules). Also, this doesn’t neccessarily mean that the Redis or Memcached service is running locally.

If you find that what I’ve mentioend below doesn’t work for you, then you’ll need to contact your hosting provider to check to see if object caching is available, and what settings you should use.

Redis and Memcached settings.

When configuring your WordPress to make use of object caching, you’ll often (although not always) have to define the address of the object caching server, and the port or the object caching service.

If the object caching service is running on the same server as your hosting the settings you’ll need are:

Memcached:

Server address: 127.0.0.1 (or localhost)

Port: 11211

Redis:

Server address: 127.0.0.1 (or localhost)

Port: 6379

Again, the PHP modules being available aren’t a guarantee that Redis or Memcached are running on the same server as your hosting. If they’re not, you’ll need to ask your hosting provider for the settings (the equivalent of the above) that you’ll need to use.

Configuring WordPress to use a Persistent Object Cache.

WordPress itself doesn’t provide any facililty to configure object caching. You’ll need to use a plugin to bring object caching in to effect on your WordPress.

It’s quite often the case that caching plugins will provide the facility to bring object caching in to effect, and there are also plugins that can simply be installed, with no configuration required.

Let’s start with the easiest first, and that’s the zero config plugin:

Object Cache 4 Everyone:

The Object Cache 4 Everyone plugin is a zero config plugin. All you do is install and activate this plugin, and you then have object caching! I would guess that this plugin relies on the object caching service running locally (I mean it’s not like it can guess the address of an object caching server is it?).

This plugin is a good choice it you’re already using a caching plugin that doesn’t provide object caching, as it add object caching functionality and that’s all. It’s easy to use, due to it’s zero configuration aspect.

W3 Total Cache:

The W3 Total Cache plugin is one of my favourite caching plugins. It does an awful lot to do with caching (more than just object caching), so it can be quite configuration heavy, and it can be a bit over the top for some users. I like it due to the many caching facilities it provides.

After installing W3 Total Cache, to configure object caching in W3 Total Cache, hover over “Performance” in the menu on the left hand side, then click on “General Settings”:

Then scroll down to the “Object cache” section, and select Redis or Memcached in the “Object cache method” drop down box:

W3 total cache select object caching method

Then save (top right), then click on “Object cache” in the menu on the left hand side:

If you set Memcached in the “Object cache method” box, enter this in the “Memcached hostname:port / IP:port:” field (these will differ if your hosting provider gave you different settings to use an external object caching server):

127.0.0.1:11211

Then click the “test’ button, and as long as you see “test passed”, save your settings:

W3 total cache object cache settings memcached

But if you chose Redis in the “Object cache method” box, you’ll need to enter some different settings, again this is in the “Object cache” section of W3 Total cache. The settings you’ll need to connect redis are:

127.0.0.1:6379

Enter these in the “Redis hostname:port / IP:port:” then click “Test” and provided the test passes, save your settings:

W3 total cache object cache settings redis

And that’s how you configure W3 Total Cache to use object caching.

LiteSpeed Cache:

The LiteSpeed cache plugin is really good to use if you have the Litespeed web server running on your hosting (I’ll have to do a blog post on this in the future), but it can still be used (with proxy/CDN caching) if your hosting doesn’t use the Litespeed web server. This plugin can also be used to being object caching in to effect.

After installing and activating the Litespeed cache plugin, hover over “Litespeed Cache” in the menu on the left hand side, then click on “cache”:

Then click on “Obect”:

On the page that’s then displayed, if you’re using Memcached, set:

Object Cache: ON

Method: Memcached

Host: localhost (or the address of the object caching server your hosting provider gave you)