WordPress Object Cache with Redis or Memcached: Step‑by‑Step for Shared Hosting and VPS

If you manage a busy WordPress site, you already know that page caching alone is not always enough. Dynamic queries, WooCommerce carts, mega‑menus pulling dozens of options, and bloated wp_options tables can still keep your database under constant pressure. That is exactly where a persistent object cache with Redis or Memcached changes the game. Instead of asking MySQL the same questions on every request, WordPress can store query results in RAM and reuse them in milliseconds. The result is lower TTFB, fewer slow queries, and much better resilience under traffic spikes.

In this guide, we will walk through step‑by‑step setups for both shared hosting and VPS. We will explain what object cache really does, how Redis and Memcached differ, how to enable them safely on typical cPanel/DirectAdmin hosting, and how to install and tune them on your own VPS. All examples are based on real‑world configurations we use at dchost.com when helping customers speed up WordPress and WooCommerce.

What WordPress Object Cache Actually Does (And Why Page Cache Is Not Enough)

WordPress already has an internal object cache layer, but by default it is in‑memory per PHP process only. Each request starts with an empty cache and throws it away at the end. A persistent object cache stores those objects in an external service such as Redis or Memcached, so that other PHP processes and future requests can reuse them.

What typically ends up in object cache?

• Results of expensive database queries (posts, terms, user meta, options)
• Transients and options from the wp_options table
• Complex query results used by big menus, product filters, related posts
• Fragments that page cache plugins cannot safely cache (e.g. user‑specific data)

If your wp_options table is already bloated or full of autoloaded rows, a persistent cache will help hide the symptoms, but you should still clean it. For that part, we highly recommend our detailed guide on WordPress database optimization, focusing on wp_options and autoload bloat.

Object cache works together with page caching, PHP‑FPM tuning and OPcache. If you have not yet reviewed your PHP and server settings, our article The server‑side secrets that make WordPress fly is a good companion read.

Redis vs Memcached for WordPress: Which One Should You Use?

Both Redis and Memcached are in‑memory key–value stores often used as object cache backends. From a WordPress perspective, they solve the same problem, but with different capabilities.

Redis in a nutshell

• Supports complex data types (lists, hashes, sets, sorted sets)
• Has built‑in persistence (RDB snapshots, AOF) if you enable it
• Provides more introspection: keys, memory usage, hit ratio, latency
• Great ecosystem for high availability and clustering when you outgrow a single VPS

Memcached in a nutshell

• Extremely simple and very fast for pure key–value lookups
• No built‑in persistence: data lives only in RAM
• Very lightweight; commonly available on shared hosting
• Scaling is usually done via client‑side sharding across multiple nodes

For most modern WordPress and WooCommerce sites we assist at dchost.com, we lean slightly towards Redis because of its tooling, observability and features like persistence and key introspection. But Memcached is still a good choice, especially on shared hosting where it may already be available and pre‑configured.

If you want a deeper comparison including TTL strategies and eviction policies, we have a separate in‑depth article: Redis vs Memcached for WordPress/WooCommerce with practical TTL and eviction tuning.

Planning: Shared Hosting vs VPS for Object Cache

The way you enable Redis or Memcached depends heavily on whether you are on shared hosting or you control a VPS (or dedicated server).

On shared hosting

• You typically do not have root SSH access.
• Redis or Memcached may already be running on the server, exposed via a local socket or TCP port.
• The main job is to install the right WordPress plugin and point it to the existing service.
• Tuning options (memory, eviction policy) are usually limited or fixed by the provider.

At dchost.com, we commonly see customers combine persistent object cache with LiteSpeed‑based page caching. If you are on LiteSpeed web server, our guide speeding up WordPress with LiteSpeed Cache on shared hosting fits neatly together with the object cache setup you will read below.

On a VPS

• You (or your sysadmin) have root access and are responsible for installation and security.
• You can decide how much RAM Redis/Memcached gets and which eviction policy is used.
• You can bind services to 127.0.0.1 only (recommended) or run them over a private network.
• You can later move Redis/Memcached to a separate VPS if the site grows.

If you are currently on shared hosting and frequently hit CPU or IO limits even after enabling caching, it might be time to upgrade. We explain the process in detail in our guide to moving from shared hosting to a VPS without downtime and in how we choose VPS specs for WooCommerce, Laravel and Node.js without overpaying.

Step‑by‑Step: Enable Object Cache on Shared Hosting

We will assume you use a typical cPanel or DirectAdmin shared hosting account, with PHP already working and WordPress installed.

1. Check if Redis or Memcached is Available

First, confirm what your hosting account supports:

• Log in to your hosting control panel.
• Look for sections like “Select PHP Version”, “PHP Extensions”, or “PHP PEAR/PECL”.
• Check if redis and/or memcached extensions are listed and enabled.

You can also create a small PHP info file to confirm:

<?php
phpinfo();

Upload it as phpinfo.php to your site root, open it in a browser, and search for redis or memcached. Once you confirm one of them is present, delete this file for security.

Some providers document the connection details (host, port, socket path) in their knowledge base or panel. At dchost.com, for example, we clearly state connection strings for supported cache services so you can plug them into your plugin quickly.

2. Choose a WordPress Object Cache Plugin

You need a plugin that knows how to talk to Redis or Memcached and integrate with WordPress’ object cache API. Popular choices include:

• Redis Object Cache plugin (simple, focused, widely used)
• W3 Total Cache (full suite with page, object and database cache)
• Litespeed Cache (if you are on LiteSpeed, it supports Redis/Memcached as backend)

On shared hosting we usually recommend starting with Redis Object Cache or your existing performance plugin’s object cache module, to avoid overlapping features.

3. Configure Redis Object Cache on Shared Hosting

1. In WordPress admin, go to Plugins → Add New and search for “Redis Object Cache”.
2. Install and activate the plugin.
3. Go to Settings → Redis (or Tools → Redis, depending on version).
4. Click Enable Object Cache.

If your hosting provider uses default settings (Redis on 127.0.0.1:6379 or a local socket), the plugin will often detect it automatically. If not, switch to advanced settings and fill in:

• Host: the Redis hostname or IP (often 127.0.0.1 or localhost)
• Port: commonly 6379
• Database: an integer like 0 or 1 (your host might assign each account its own DB index)
• Prefix: useful if you run multiple WordPress installs on the same Redis (e.g. myshop_)

After saving, the plugin will typically create a object-cache.php drop‑in in wp-content. This file overrides WordPress’ internal object cache and routes all calls to Redis.

4. Configure Memcached Object Cache on Shared Hosting

If Memcached is available but Redis is not, the process is similar:

• Install a plugin that supports Memcached as an object cache backend (for example, W3 Total Cache).
• In W3 Total Cache, go to Performance → General Settings.
• Under Object Cache, choose Memcached as the method and save.
• Under Performance → Object Cache, configure the Memcached servers (e.g. 127.0.0.1:11211).

If your host runs a shared Memcached instance, they may provide a specific host and port. Always prefer 127.0.0.1 or a Unix socket when possible – it’s slightly faster and does not cross the network stack.

5. Verify That Object Cache Is Working

After enabling Redis or Memcached, you should verify that it is actually being used:

• Most plugins show status, hits and misses on their settings page.
• You can install the Query Monitor plugin to see reduced database query counts on cached pages.
• Test under load with tools like Loader.io, k6 or your preferred alternative; TTFB should be more stable.

If you see errors like “Could not connect to Redis” or “Memcached extension not loaded”, double‑check that the PHP extension is enabled and that your credentials (host, port, socket) are correct. If issues persist, your hosting support team (for dchost.com customers, that’s us) can confirm server‑side connectivity.

Step‑by‑Step: Install and Configure Redis/Memcached on a VPS

On a VPS you control both the cache service and the WordPress site. This gives you more power – and more responsibility. The examples below assume a typical Debian/Ubuntu‑based server with Nginx or Apache, PHP‑FPM and MariaDB/MySQL.

1. Prerequisites

• Root SSH access to your VPS.
• WordPress installed and working over PHP‑FPM.
• Basic familiarity with editing config files in nano or vim.

If you are setting up a fresh VPS, our articles on securing a new VPS in the first 24 hours and on choosing the right PHP limits are worth skimming before you go live.

2. Install Redis on a VPS

On Debian/Ubuntu:

sudo apt update
sudo apt install redis-server php-redis -y

Then harden and tune Redis. Open /etc/redis/redis.conf:

sudo nano /etc/redis/redis.conf

Recommended baseline settings for a single VPS:

bind 127.0.0.1
protected-mode yes
port 6379

# Limit memory usage (example: 512MB)
maxmemory 512mb
maxmemory-policy allkeys-lru

• bind 127.0.0.1 ensures Redis is not exposed to the public internet.
• maxmemory prevents Redis from consuming all your RAM.
• maxmemory-policy allkeys-lru is generally safe for WordPress: least‑recently‑used eviction of any key.

Restart Redis:

sudo systemctl restart redis-server
sudo systemctl enable redis-server

Test from the shell:

redis-cli ping
# Response should be: PONG

3. Install Memcached on a VPS

If you prefer Memcached or want both options available:

sudo apt update
sudo apt install memcached php-memcached -y

Edit /etc/memcached.conf:

sudo nano /etc/memcached.conf

Key parameters:

# Memory in MB
default: -m 64

# Listen on localhost only
-l 127.0.0.1

Adjust -m to a reasonable value, e.g. -m 256 or -m 512 depending on your VPS RAM. Then restart:

sudo systemctl restart memcached
sudo systemctl enable memcached

4. Connect WordPress to Redis on a VPS

Back to WordPress:

1. Install and activate the Redis Object Cache plugin.
2. In the plugin settings, set Host to 127.0.0.1 and Port to 6379.
3. Click Enable Object Cache.

For advanced setups, you can configure Redis in wp-config.php before the /* That's all, stop editing! */ line:

define( 'WP_REDIS_HOST', '127.0.0.1' );
define( 'WP_REDIS_PORT', 6379 );
// Optional: use a non-default database if you share Redis
// define( 'WP_REDIS_DATABASE', 1 );
// Optional: prefix if multiple installs share one Redis
// define( 'WP_CACHE_KEY_SALT', 'myshop_example_com_' );

Save, then go to the plugin page and confirm that it detects Redis and reports an active connection with a non‑zero hit ratio after some traffic.

5. Connect WordPress to Memcached on a VPS

With Memcached and php-memcached installed, you can use W3 Total Cache, LiteSpeed Cache or another plugin that supports it:

• Install your chosen plugin.
• Enable Object Cache and pick Memcached as the method.
• Set the server as 127.0.0.1:11211.

Some object cache drop‑ins specifically designed for Memcached may require placing a custom object-cache.php file into wp-content. Always follow the plugin’s documentation carefully; don’t leave multiple incompatible drop‑ins active at the same time.

Testing, Monitoring and Troubleshooting Object Cache

Once Redis or Memcached is connected, the real question is: is it helping? Here are practical checks we use day‑to‑day.

1. Watch Cache Hit Ratios

Most Redis/Memcached plugins display hit and miss counts. After some normal traffic, you should see the hit ratio trend upward. If it remains near zero, something is wrong (or your cache is constantly being flushed).

For Redis, from the server console:

redis-cli info stats | egrep 'keyspace_hits|keyspace_misses'

For Memcached, you can use:

echo stats | nc 127.0.0.1 11211 | egrep 'get_hits|get_misses'

2. Compare Database Load Before and After

Use Query Monitor or your database’s slow query log to compare:

• Average number of queries on cached pages
• Number of slow queries (> 1s) under similar traffic

Combined with server‑side tuning (PHP‑FPM and MySQL/InnoDB), object cache should reduce both query counts and tail latency. Our article on server‑side optimization for WordPress walks through a full tuning checklist that pairs nicely with object caching.

3. Common Problems and Fixes

• “Error establishing Redis connection”: check that Redis is running and reachable from the PHP user. On a VPS, confirm systemctl status redis-server and that bind in redis.conf permits localhost.
• High memory usage: if Redis or Memcached starts evicting crucial keys too aggressively, raise maxmemory (Redis) or -m (Memcached) or lower TTLs in your plugin.
• Stale or wrong data: relatively rare with object cache, but can happen with aggressive transients. Clearing the object cache after big migrations or plugin changes is safe and often solves the issue.
• Conflicts between caching plugins: avoid enabling multiple object cache solutions at once. One object-cache.php drop‑in at a time.

Best Practices for Stable, Fast WordPress Object Caching

A few patterns make the difference between “it works sometimes” and “it just runs” in production.

1. Keep Redis/Memcached Local or on a Private Network

For latency‑sensitive cache traffic:

• Run Redis/Memcached on the same VPS as PHP, or on a dedicated cache VPS within the same data center region.
• Avoid exposing them on public IPs. Use bind 127.0.0.1 or a private VLAN.
• Use firewall rules (UFW, nftables, security groups) to restrict access further.

We go deeper into firewall best practices in our VPS security and nftables guides, but the core idea is simple: never leave Redis or Memcached open to the world.

2. Choose Sensible TTLs and Eviction Policies

Object cache is most effective when it avoids excessive churn:

• Use reasonable default TTLs (e.g. minutes to hours) for most objects.
• Avoid setting everything to “no expiration” if your memory budget is small.
• For Redis, allkeys-lru is usually a good starting policy; for Memcached, rely on its default LRU behavior.

If you want concrete TTL examples tailored to WooCommerce, search filters and heavy menus, our dedicated article on Redis vs Memcached TTL and eviction tuning for WordPress/WooCommerce covers several production scenarios.

3. Pair Object Cache with Page Cache and PHP/MySQL Tuning

Object cache is not a silver bullet. For best results, combine:

• Page cache: via LiteSpeed Cache, Nginx microcaching, or another full‑page cache layer
• OPcache: so PHP does not recompile scripts on every request
• PHP‑FPM tuning: right number of workers for your CPU/RAM
• MySQL/InnoDB tuning: buffer pool size, slow query analysis, and proper indexes

We discuss MySQL/InnoDB tuning for WooCommerce in depth in our article on the WooCommerce MySQL/InnoDB tuning checklist, and page caching strategies in our full‑page caching guide for WordPress that won’t break WooCommerce.

4. Watch Disk and RAM on VPS Plans

Redis and Memcached keep data in RAM, so you should:

• Leave enough memory for PHP‑FPM, MySQL and the OS.
• Start conservatively (e.g. 256–512 MB for Redis on smaller VPS instances).
• Monitor RAM usage and swap; if you see frequent swapping, either lower cache memory or upgrade your VPS.

Using NVMe‑based VPS plans helps a lot when cache misses fall back to disk. To understand why, our article comparing NVMe SSD, SATA SSD and HDD for hosting explains the performance difference in real‑world terms.

When to Move Beyond a Single Server Object Cache

For many sites, a single VPS with Redis or Memcached is more than enough. But as traffic or complexity grows, you may outgrow this architecture. Signs include:

• CPU saturation even though your cache hit ratio is high.
• Long MySQL queries because your data model or reporting needs became complex.
• Need for high availability or maintenance windows with zero cache loss.

At that stage, you may:

• Offload Redis to a dedicated cache VPS within the same data center.
• Scale MySQL with replicas or clusters.
• Introduce a load balancer and multiple PHP‑FPM nodes sharing the same Redis cluster.

We have a separate advanced guide focused on high‑availability Redis for WordPress with Sentinel, AOF/RDB and real failover, which is a natural next step when a single Redis instance is no longer enough.

Summary and How We Approach This at dchost.com

Persistent object cache with Redis or Memcached is one of the highest‑impact, relatively low‑risk optimizations you can make for WordPress and WooCommerce. On shared hosting, it is often as simple as enabling a PHP extension, installing the right plugin and pasting a host/port. On a VPS, you gain full control over installation, memory, security and eviction policies, which lets you squeeze the most out of your hardware.

In real‑world projects we manage at dchost.com, the winning formula usually looks like this:

• Clean up wp_options and slow queries first.
• Enable page cache and OPcache.
• Add Redis (or Memcached) as a persistent object cache.
• Tune PHP‑FPM and MySQL to match your traffic pattern.

This layered approach keeps your site fast and predictable, even during campaigns or seasonal peaks. If you are already hosting with us and want to enable Redis or Memcached, our support team can confirm what is available on your plan and help you pick a safe configuration. If you are planning a move to a VPS or dedicated server, we can size your resources (CPU, RAM, NVMe, bandwidth) so that WordPress object cache has enough headroom to really shine.

The next practical step: decide whether you will start on your current shared hosting or on a VPS, pick Redis or Memcached with the considerations above, and follow the relevant step‑by‑step section. Once your object cache is live, give your site a few days under normal traffic, monitor hit ratios and database load, and then iterate. Small, deliberate tuning moves in caching usually pay back far more than one‑off “optimization” plugins, and they give you a predictable performance foundation to grow on.