Redis is an open source (BSD licensed), in-memory data structure store, used as a database, cache and message broker. It can be combined with other databases like MySQL to provide a mechanism to cache your queries.
In this article, we'll show how to cache the MySQL queries that are required to render WordPress pages. This will provide us with significant performance gains, though with some caveats.
Intro to Better Wordpress Caching
WordPress uses the MySQL database to cache internal application objects (breadcrumbs, menu items, etc.) which can be expensive to generate. Since the database also handles queries for page requests, it's possibly the most common bottleneck and often causes increased load-times.
Redis provides a caching mechanism that acts as an alternative to the MySQL database. If a user visits a WordPress page, the MySQL queries required to generate the page are served via Redis which caches the results. This results in blazing fast load times, comparable to static pages.
Another popular caching choice is Memcached. However, Redis does almost everything that Memcached does so we will be using Redis for the sake of this tutorial.
How Does Redis Caching Work?
When a user requests a WordPress page for the first time, a MySQL query is performed on the server. Redis caches this query, so when another user requests the same WordPress page, the results are provided from Redis without the need to query the database again.
If the query is not cached in Redis, the results are provided by MySQL, which are then added to the Redis cache.
If a particular value is updated in the database, the corresponding Redis value is invalidated to prevent bad cache data from being served to the user.
Tutorial Requirements
Here is the list of technologies used in this article:
- 2 WordPress installations (with and without the plugin, for benchmarks)
- Redis server
- Redis WP Object Cache Plugin
WordPress Installation
You can download the latest version of WordPress here and set up two different installations on a host like Heroku or AWS.
Redis Server
ScaleGrid provides world-class support for Redis Standalone and Master/Slave clusters with enhanced security features. We'll be using a Standalone Redis cluster hosted on ScaleGrid with the Allkeys-LRU caching strategy, and you can signup for a free 30-day trial of our Redis hosting to assist with this tutorial.
Redis WP Object Cache Plugin
This plugin is used as a drop-in to your WordPress installation and can be configured to use the Redis host. You can find the plugin here.
Setup Instructions: Redis Object Cache for WordPress
Here are the steps for getting the Redis Object Cache Plugin installed on a WordPress installation.
Step 1: Install the Redis Cache Plugin
This tutorial assumes that you already have two fresh installations of WordPress set up. On one of them, you need to install the Redis Object Cache plugin. Once the plugin is installed, you can activate it from the plugins menu.
Step 2: Find Redis in your Settings
Once the plugin is activated, a Redis option will appear under the Settings Menu.
Step 3: Add WordPress Configurations
After setting up the plugin, we need to add configuration options to the WordPress config file. At a minimum, you would need to set up the following options:
define('WP_REDIS_HOST', '');
define('WP_REDIS_PASSWORD', '');
You can find the above options on the ScaleGrid Redis Cluster Details page.
Save the config and enable the Object Cache. If the authentication is correct, you should see the following screen:
At this point, Redis has been configured as a cache for your WordPress installation.
Monitoring and Debugging WordPress Queries
All Redis clusters come installed with the Redis command line interface (redis-cli) tool that you can use to monitor the incoming query requests from WordPress. Here's a screenshot of how this might look:
If you do not see any output on the console, go to the WordPress website and refresh.
WordPress & Redis Metrics to Track
The major metric to track here is the page load time. Here is the default configuration we're using for the fresh install:
- WordPress: 4.9.5
- Redis: v.4.0.2
- WordPress Theme: Twenty Seventeen
Based on a fresh installation on the above parameters, we can see almost 50% reduction in page load times:
- Without the Redis Object Cache = ~900ms
- With the Redis Object Cache = ~400ms
Redis Object Cache Disadvantages
There are a few caveats to using the Redis Object Cache approach on WordPress. The caching mechanism does not work well if you have a lot of plugins and themes installed. This is due to the fact that all their data would need to be cached as well with Redis.
You can also learn how to Cache Tweets Using Node.js, Redis, and Socket.io in our earlier article.
As always, if you build something awesome, do tweet us about it @scalegridio. If you need help with MongoDB or Redis hosting and management, reach out to us at support@scalegrid.io.
Top comments (2)
Great tutorial on using Redis for WordPress caching! As a Cloudways user, I’ve experienced how Redis integration significantly enhances performance, especially with managed hosting. Combining Redis with Cloudways makes setup and management seamless while delivering blazing-fast load times!
Redis is a powerful tool for enhancing the performance of WordPress installations, and I appreciate this insightful article on its implementation! It’s impressive to see how leveraging Redis can reduce page load times significantly—down from around 900ms to just 400ms.
As someone who manages multiple WordPress sites, I’ve seen firsthand the benefits of optimized caching solutions. For those looking to take full advantage of Redis, choosing the right hosting provider can make a big difference. For instance, Cloudways offers managed hosting that seamlessly integrates Redis caching, which can help developers focus on building rather than managing servers. This not only improves site speed but also ensures that your resources scale smoothly as traffic increases.
I’m curious to hear what other tools or configurations everyone is using to optimize their WordPress sites. Let’s keep this discussion going!