TLDR: I set up Redis as a persistent object cache on my WordPress site and saw faster admin pages, lower database load, and snappier page generation. This guide walks you through what Redis is, why it matters for WordPress performance, a step-by-step setup you can follow, testing tips, and common mistakes to avoid so you can safely speed up your site.
Redis Cache for WordPress: A Short Intro and Why I Wrote This
I still remember the late night when my site started timing out under traffic from a popular newsletter. I had optimized images, used a CDN, and followed advice on how to speed up WordPress, but the admin screens and dynamic queries were still slow. The answer for me was Redis. Once Redis was in place as an object cache, page generation times dropped and my server stayed calm during spikes. I wrote this because I want you to avoid those sleepless nights and get predictable performance.
What is Redis and how does it work with WordPress?
Redis is an in-memory key-value store that excels at fast reads and writes. In a WordPress context, Redis holds expensive-to-generate data such as query results, options, and computed fragments, so PHP does not have to rebuild those values on every request. Unlike transient caching that expires after a set time, Redis can act as a persistent object cache that survives multiple requests and reduces database queries dramatically.
Why Redis cache matters for WordPress sites
There are three main reasons I decided Redis was worth the effort:
- Lower database load: Redis reduces repeated SELECT queries for repeated data, which keeps CPU and I/O low.
- Faster dynamic responses: Logged-in users and admin pages benefit because object caching works where page cache does not.
- Scalability: When traffic spikes, Redis helps your PHP workers serve content without overwhelming MySQL.
When Redis is not the best fit
Redis is not a replacement for full-page caching or a CDN. If your site is static and anonymous users only need cached HTML pages, a page cache plus CDN might be enough. Also, if you are on very limited shared hosting without Redis support, it may be hard to configure. For most VPS, managed WordPress, or cloud hosts, Redis is a practical next step after basic caching.
How do you set up Redis cache on WordPress? A practical step-by-step
Below is the process I followed. I split it into the server layer, WordPress plugin layer, and verification so you can follow it in order.
Step 1 – Prepare your environment
Before starting, check your host documentation. Many hosts offer Redis as an add-on or a one-click service. If you manage your own server (Ubuntu, Debian), install Redis with apt or your package manager. In short:
- Install Redis on the server (sudo apt install redis-server on Debian/Ubuntu).
- Secure the installation: bind to localhost if only PHP on the same server will use it, or enable AUTH and firewall rules if you need remote access.
- Ensure redis-server is running and set to start at boot.
Step 2 – Install a WordPress Redis plugin
I used the official Redis Object Cache plugin for WordPress because it is simple and widely supported. From the WordPress admin, install and activate “Redis Object Cache” or use composer if you prefer to manage packages.
Step 3 – Configure connection settings
Open wp-config.php and add connection constants only if needed. Many plugin installs detect Redis on localhost automatically. Typical constants you might add look like this:
- define(‘WP_REDIS_HOST’, ‘127.0.0.1’);
- define(‘WP_REDIS_PORT’, 6379);
- define(‘WP_REDIS_PASSWORD’, ‘your_redis_password’);
Be careful: do not commit secrets to your public repo. Use environment variables or a secure method to inject passwords.
Step 4 – Enable object caching and choose your prefix
From the plugin settings, enable object caching. I recommend setting a unique key prefix if you host multiple WordPress instances on the same Redis server. This avoids key collisions between sites.
Step 5 – Tune Redis memory policy
Redis is memory-first. Choose an eviction policy that suits your site. For example, allkeys-lru works well for general-purpose caching so Redis evicts the least recently used keys when memory is full. Set a reasonable maxmemory based on your server size, then monitor usage.
Step 6 – Combine Redis with other caching techniques
Redis works best when paired with a page cache and a CDN. Use Redis for object caching and a plugin like WP Super Cache, WP Rocket, or your host-provided page cache for static HTML. Also maintain your image pipeline and optimization strategy so static assets are small and served fast. If you tune images and reduce payload, you get the maximum benefit from both Redis and CDNs. For tips about image workflows, see image optimization WordPress.
Step 7 – How to purge and warm the cache
When you update content or deploy changes, you need a strategy to purge affected keys and prime the cache. The Redis Object Cache plugin provides an option to flush the object cache. If you run deployments, make sure your CI clears Redis keys for that environment. When testing, manually purge from the plugin or CLI and visit critical pages to warm cached entries. If you are unsure how to purge, the host docs or the plugin UI will walk you through tools to purge cache WordPress.
How I verified Redis was helping
After enabling Redis, I ran these checks:
- Monitor MySQL slow query log and watch for fewer repeated reads.
- Use a profiling plugin or New Relic to compare TTFB before and after.
- Inspect Redis metrics (hits, misses, used memory, evicted keys) to ensure the cache is warm and being used.
What you should avoid when using Redis
There are a few pitfalls I learned the hard way:
- Avoid storing large blobs in Redis. Keep values reasonably sized so memory is used efficiently.
- Do not expose Redis without authentication. If you must bind to a public interface, use TLS and strong passwords.
- Be careful with object cache persistence across deployments. If you change code that changes object structures, stale objects can break behavior. Clear cache during migrations.
- Don’t treat Redis as a long-term datastore for user data. It is a cache. Use your database for durable storage.
Performance tuning and realistic expectations
Redis is not magic. It speeds up dynamically generated content and admin tasks, but it does not replace good application design. After setup, I recommend:
- Measure using identical test scenarios before and after.
- Watch memory and eviction rates to avoid cache thrashing.
- Combine with a robust page cache for public pages and a CDN for static assets.
Frequently Asked Questions
Will Redis replace my page cache or CDN?
No. Redis complements page caching and CDNs by caching PHP-level objects and database query results. Use Redis for dynamic and logged-in experiences while relying on page cache and CDN for anonymous users and static assets.
Is Redis secure for shared hosting?
On shared hosting you often cannot install Redis. If your host offers Redis as a managed add-on, ensure it uses authentication and network isolation. If you must use a remote Redis instance, enable TLS and limit connections to your application IPs.
How much memory does Redis need?
That depends on your site. Start small and monitor. A few hundred megabytes can help small sites, but busier sites may need several gigabytes. Monitor used_memory_rss and keyspace stats to make informed decisions.
Can I use Redis for sessions and object caching at the same time?
Yes. Redis is commonly used for both sessions and object cache. Use distinct key prefixes or separate logical databases to avoid collisions and make it easier to flush only what you need.
What happens during deployments when cache keys change?
If your code changes object formats or cache keys, clear the Redis object cache as part of your deploy script. That prevents type errors and stale data from affecting new code paths.
How do I troubleshoot cache misses?
Look at plugin logs and Redis INFO stats. Increase verbosity temporarily in the plugin to log keys being written and read. Misses are normal while warming the cache; persistent high misses may indicate incorrect prefixing or connection problems.
Summary
In my experience, Redis provided reliable, low-latency caching that improved both frontend responsiveness for dynamic pages and admin usability under load. The setup is straightforward on modern hosts and pays off when you combine it with page caching, CDN, and efficient asset delivery. However, remember Redis is a cache not a database and secure it properly.
Next steps I recommend
Start by checking whether your host offers Redis. If not, test Redis on a staging server, measure the performance gains, and automate cache clearing during deploys. Finally, maintain image and asset optimization so the whole stack performs well end to end. If you want deeper guidance on improving site speed beyond object caching, review resources that cover broader optimisation techniques like how to speed up WordPress and pairing Redis with good media practices like image optimization WordPress.