Speed Up WordPress with Redis Object Caching on a VPS

If you've already installed a caching plugin, switched to a faster PHP version, and optimized your images, but your WordPress admin dashboard still feels sluggish and your database CPU keeps spiking — the bottleneck usually isn't page caching at all. It's the hundreds of repeated database queries WordPress runs on every single request. That's exactly what Redis object caching fixes, and it's one of the most underused performance tools on VPS hosting.

Symptom: Fast Homepage, Slow Everything Else

This is the classic pattern that points to a missing object cache:

• Your homepage loads fast because a page-caching plugin (WP Super Cache, W3 Total Cache, etc.) is serving a static HTML copy.
• But /wp-admin, WooCommerce cart/checkout pages, logged-in user views, or any page that can't be page-cached still crawl.
• SHOW PROCESSLIST in MySQL shows dozens of near-identical SELECT queries against wp_options, wp_postmeta, or wp_usermeta hitting at once.
• Your VPS's MySQL/MariaDB process is pegging CPU even though traffic isn't that high.

Page caching only speeds up requests it can serve statically. Everything dynamic — logged-in traffic, e-commerce, membership sites, admin work — still runs the full WordPress bootstrap and hits the database on every load. That's the gap object caching closes.

Cause: WordPress Re-Queries the Same Data Constantly

WordPress core, by default, uses an in-memory object cache that only lives for the duration of a single page request. The moment that request finishes, the cache is thrown away. So if 50 visitors load your site in the same minute, WordPress runs the same "get me all the active plugins" or "get me this post's meta" query 50 separate times — even though the underlying data hasn't changed.

Redis (or Memcached) fixes this by acting as a persistent object cache that lives across requests, in RAM, shared by every visitor. Once one request fetches a value, every subsequent request reads it straight from memory instead of hitting MySQL again. On a busy WooCommerce store or membership site, this alone can cut database load by 60-80%.

Fix: Install and Configure Redis on Your VPS

This walkthrough assumes an Ubuntu/AlmaLinux VPS with WordPress running on Nginx or Apache. If you're on shared cPanel hosting instead of a VPS, check with your host first — Redis needs to be installed at the server level, so it's not something you can self-provision from cPanel alone (SkyServer VPS plans include root access, so you can do this yourself).

Step 1: Install the Redis Server

On Ubuntu/Debian:

sudo apt update
sudo apt install redis-server -y
sudo systemctl enable redis-server
sudo systemctl start redis-server

On AlmaLinux/CentOS:

sudo dnf install redis -y
sudo systemctl enable redis
sudo systemctl start redis

Confirm it's running:

redis-cli ping
# should return: PONG

Step 2: Lock Redis Down (It Binds to All Interfaces by Default in Some Builds)

Open /etc/redis/redis.conf and check these three lines:

bind 127.0.0.1 -::1
protected-mode yes
requirepass a-long-random-password-here

Redis has no authentication by default on older configs, and an open Redis port on the public internet is a known ransomware target — attackers scan for exactly this. If you only need Redis for WordPress on the same server, binding it to localhost and setting a password is non-negotiable. Restart after editing:

sudo systemctl restart redis-server

Step 3: Install the PHP Redis Extension

WordPress needs PHP to be able to talk to Redis. Install the extension for whatever PHP version your site actually uses:

sudo apt install php-redis -y
sudo systemctl restart php8.1-fpm   # match your actual PHP-FPM version

Verify it loaded:

php -m | grep redis

If nothing prints, double-check you installed the extension for the same PHP version your site is running — it's easy to install it for the wrong version if you have multiple PHP versions on the box.

Step 4: Connect WordPress to Redis

Install the Redis Object Cache plugin (by Till Krüss) from the WordPress plugin directory, or via WP-CLI:

wp plugin install redis-cache --activate

Then add your Redis credentials to wp-config.php, above the "That's all, stop editing!" line:

define( 'WP_REDIS_HOST', '127.0.0.1' );
define( 'WP_REDIS_PORT', 6379 );
define( 'WP_REDIS_PASSWORD', 'a-long-random-password-here' );
define( 'WP_REDIS_TIMEOUT', 1 );
define( 'WP_REDIS_DATABASE', 0 );

Enable the object cache from WP-CLI or from Settings → Redis in wp-admin:

wp redis enable

You should see "Status: Connected" on the Redis settings page. If it says "Not connected," it's almost always one of: wrong password, PHP Redis extension not loaded for the active PHP version, or Redis bound to the wrong interface.

Step 5: Confirm It's Actually Working

Run this while your site is getting traffic (or just refresh a few pages):

redis-cli -a your-password INFO stats | grep keyspace

You should see keyspace_hits climbing steadily higher than keyspace_misses. If hits stay at zero, the plugin isn't actually writing to Redis — recheck the wp-config.php constants.

A Quick Word on WooCommerce and Multisite

If you're running WooCommerce, object caching matters even more than on a plain blog, because cart sessions, product stock, and pricing all involve repeated meta lookups per visitor. Set WP_REDIS_DATABASE to a unique number (0, 1, 2...) for each WordPress install if you're running multiple sites on one VPS and sharing the same Redis instance — otherwise their caches will collide and you'll see one site's data bleeding into another's admin screens.

Prevention: Keep an Eye on Memory

Redis stores everything in RAM, and by default has no memory ceiling — on a small VPS that can starve MySQL or PHP-FPM of memory during traffic spikes. Set a cap and an eviction policy in redis.conf:

maxmemory 256mb
maxmemory-policy allkeys-lru

allkeys-lru tells Redis to quietly evict the least-recently-used keys once it hits the limit, instead of crashing or refusing new writes. For most single-WordPress-site VPS setups, 128–256MB is plenty; a busy multisite or WooCommerce store might need more. Watch it with:

redis-cli -a your-password INFO memory | grep used_memory_human

They're not competing tools — a well-tuned WordPress site on a VPS typically runs all three together.

Frequently Asked Questions

Do I need Redis if I already have a caching plugin like WP Super Cache?

Page caching plugins and object caching solve different problems. If your site has any dynamic traffic — logged-in users, WooCommerce, membership content, forums — a page cache alone won't touch those requests. Redis speeds up the database layer underneath everything, cached or not.

Is Redis available on shared cPanel hosting or only VPS?

Redis needs to be installed and run at the server level, so it's typically a VPS or dedicated server feature rather than something available on standard shared hosting. If you're on shared hosting and need object caching, ask your host whether Redis or Memcached is offered as an add-on, or consider moving to a VPS plan.

What happens if Redis crashes or runs out of memory?

WordPress falls back gracefully to querying MySQL directly — your site keeps working, just slower, exactly as it was before you set up Redis. It won't take the site down. That said, set a maxmemory cap so Redis evicts old keys instead of consuming all available server RAM.

Should I use Redis or Memcached?

Both work well as WordPress object caches. Redis is generally preferred now because it supports persistence (optional), more data types, and is what most modern caching plugins and managed WordPress hosts default to. Memcached is a bit lighter but lacks Redis's extra features. Unless you have a specific reason to choose Memcached, Redis is the safer default.

Will enabling Redis break my site if something goes wrong?

If misconfigured, the Redis Object Cache plugin will simply show "Not connected" and WordPress continues to run without the object cache — it won't cause fatal errors. The one thing to watch is a corrupted object-cache.php drop-in file in wp-content; if the plugin fails mid-install, delete that file manually via File Manager or SSH and reactivate the plugin.