WordPress Object Caching with Redis and Memcached

Object caching stores the results of database queries in memory and reuses them across requests, instead of only within one.
It helps most where page caching cannot: logged-in users, carts, checkouts and the admin.
Redis is the right default. Memcached is fine but has fewer WordPress-facing features and no persistence.
Without a persistent object cache, WordPress rebuilds the same query results on every single request.
Set maxmemory-policy allkeys-lru on Redis, or a full cache will start refusing writes rather than evicting old keys.

What does object caching do for WordPress?

It keeps the results of database queries in memory so the next request can reuse them. WordPress already has an object cache, but by default it only lives for the duration of a single request. A persistent backend such as Redis makes it survive between requests, so a query that ran once serves thousands of visitors.

	Default WordPress	With Redis
Cache lifetime	One request	Until the data changes or expires
Same query on the next request	Runs again against the database	Read from memory
Helps logged-in users	No	Yes
Helps the admin area	No	Yes
Helps WooCommerce checkout	No	Yes

The last three rows are the point: these are exactly the pages a full-page cache cannot help with.

It is not a replacement for page caching

Page caching stores finished HTML for anonymous visitors and is the bigger win on a content site. Object caching stores query results and helps everywhere, including pages that can never be cached as a whole. Busy sites want both, and they do not overlap. See setting up an Nginx reverse proxy cache.

When will object caching actually help?

The gain is proportional to how much of your traffic cannot be page cached, and to how query-heavy your pages are. A small brochure site behind a page cache will barely notice. A shop where every visitor has a session will notice a great deal.

Site type	Expected benefit	Why
Brochure site, mostly anonymous	Small	Page caching already answers nearly every request
Busy blog with comments	Moderate	Logged-in commenters bypass the page cache
WooCommerce shop	Large	Carts and checkout are never page cached
Membership or LMS site	Large	Almost every visitor is logged in
Site with a very large options table	Large	Autoloaded options are read on every request
Multisite network	Large	Site and network options are queried constantly

If most of your traffic is logged out and already cached, spend the effort elsewhere first.

Is your site a good candidate?

cd /var/www/example.com

# Queries per page load: over 100 suggests real headroom
wp eval 'global $wpdb; get_posts(); echo $wpdb->num_queries . " queries" . PHP_EOL;'

# Autoloaded options: over 1 MB and object caching will help a lot
wp db query "SELECT ROUND(SUM(LENGTH(option_value))/1024/1024, 2) AS mb
  FROM wp_options WHERE autoload='yes'"

# Is a persistent object cache already active?
wp cache type

A large autoloaded options table is the clearest signal. That data is read on every request and object caching removes almost all of that cost.

Redis or Memcached: which should I use?

Redis, unless something in your environment already standardises on Memcached. Both are fast enough that raw speed is not the deciding factor; Redis has better tooling, richer data types, optional persistence and a more actively maintained WordPress plugin.

	Redis	Memcached
Speed for WordPress	Fast	Fast: no meaningful difference
Survives a restart	Yes, optionally	No, cache is lost
Data types	Strings, hashes, lists, sets	Strings only
Grouped cache invalidation	Yes	Limited
WordPress plugin	Redis Object Cache, actively maintained	Older, less active
Also usable for	Sessions, queues, rate limiting	Caching only

Persistence matters more than it sounds: a Memcached restart empties the cache and sends every request to the database at once.

Install and enable Redis

# 1. Redis server and the PHP extension
sudo apt install -y redis-server php8.3-redis
sudo systemctl enable --now redis-server

# 2. Confirm PHP can see it
php -m | grep redis
redis-cli ping        # expect PONG

# 3. Enable it in WordPress
cd /var/www/example.com
wp plugin install redis-cache --activate
wp redis enable
wp redis status

The plugin writes an object-cache.php drop-in to wp-content. If wp redis status says Connected, it is live.

Redis configuration that matters

# /etc/redis/redis.conf

# Localhost only. Redis has no authentication by default.
bind 127.0.0.1 ::1
protected-mode yes

# Cap the memory Redis may use
maxmemory 512mb

# Evict the least recently used keys when full. This line is essential.
maxmemory-policy allkeys-lru

# A cache does not need disk persistence; skip the write overhead
save ""
appendonly no

sudo systemctl restart redis-server

Without maxmemory-policy, Redis defaults to noeviction and starts returning errors on write once full, rather than making room.

Never expose Redis to the internet

Redis has no authentication enabled by default and assumes it sits on a trusted network. An internet-reachable instance is trivially readable and writable by anyone who finds it, and has been used to write SSH keys onto servers. Bind to localhost, and if it must cross a network, put it on a private one with a password set.

How do I confirm the object cache is working?

Verification

cd /var/www/example.com

# Should report 'redis', not 'default'
wp cache type

# Plugin's own view: connection status, hit ratio, keys stored
wp redis status

# Live Redis statistics
redis-cli info stats | grep -E 'keyspace_hits|keyspace_misses'
redis-cli info memory | grep -E 'used_memory_human|maxmemory_human'
redis-cli dbsize

# Watch commands in real time (development only, it is noisy)
redis-cli monitor

Hit ratio is keyspace_hits divided by hits plus misses. Anything above about 80 percent on a warm cache is working well.

Measure the difference

# Queries per request, with the cache on and off
wp eval 'global $wpdb; get_posts(["posts_per_page"=>20]); echo $wpdb->num_queries . PHP_EOL;'

wp redis disable
# run it again, note the number
wp redis enable

# Time to first byte on a page that bypasses the page cache
for i in $(seq 1 10); do
  curl -s -o /dev/null -w '%{time_starttransfer}\n' \
    "https://example.com/my-account/?nocache=$RANDOM"
done | awk '{s+=$1} END {printf "avg %.3fs\n", s/10}'

Test a logged-in or account page. Testing the homepage measures your page cache, not the object cache.

Symptom	Cause	Fix
wp cache type says default	The drop-in is missing	wp redis enable, and check wp-content is writable
Connection refused	Redis is not running or is on another port	systemctl status redis-server; redis-cli ping
Hit rate stays very low	Cache is being flushed constantly	A plugin is calling wp_cache_flush on every request
OOM command not allowed	Redis is full with noeviction set	Set maxmemory-policy allkeys-lru
Stale content after an edit	A plugin is not invalidating its own keys	Flush with wp cache flush, then report it

Row four is the one that takes a site down, and the one-line configuration fix prevents it entirely.

How do I use object caching safely on WooCommerce?

WooCommerce benefits more than most sites, because carts, accounts and checkout can never be page cached. It also has the most to lose from a caching mistake, so a few rules are worth following exactly.

Never cache the cart, checkout or account pages at the page level. Object caching is safe there; full-page caching is not, and mixing the two up is how customers see each other's baskets.
Give Redis enough memory for your catalogue. A shop with thousands of products and variations will evict useful keys constantly on a small allocation, which produces a low hit rate and no benefit.
Test stock levels under concurrency after enabling it. Stale stock data is the failure mode that costs money, and it shows up under load rather than in a single manual test.
Flush the cache on deploy. A code change that alters what a cached value means, with the old value still in memory, produces behaviour nobody can reproduce.
Watch the hit rate after enabling it, not just on the first day. A plugin added later that flushes the cache on every request will quietly undo the whole thing.

Flush safely

# Flush the WordPress object cache
wp cache flush

# Flush only this site's keys on a shared Redis instance
wp redis flush

# Nuclear: empties EVERY database on the instance.
# Never run this on a Redis shared with other sites or services.
redis-cli FLUSHALL

Prefer wp redis flush. FLUSHALL on a shared instance clears every other site's cache at the same time.

This layer should come with the hosting

Object caching is standard infrastructure rather than something every site owner should be configuring by hand. On G7Cloud each site gets its own isolated cache alongside its own database and PHP pool, so a neighbour's traffic cannot evict your keys. See our WordPress caching and WooCommerce speed optimisation.

If the database itself is the problem rather than the number of queries, caching will only mask it. Safely trimming a large WordPress or WooCommerce database covers the underlying size problem.

Frequently asked questions

What is object caching in WordPress?

Storing the results of database queries in memory so later requests reuse them instead of querying again. WordPress does this by default only within a single request. A persistent backend such as Redis makes the cache survive between requests, which is where the real gain comes from.

Do I need object caching if I already have page caching?

It depends what your traffic looks like. If nearly every visitor is anonymous and served from the page cache, the extra gain is small. If you run a shop, a membership site or anything where visitors log in, object caching helps exactly the pages page caching cannot touch.

Is Redis or Memcached better for WordPress?

Redis for most sites. Speed is comparable, but Redis offers optional persistence, richer data types, better cache invalidation and a more actively maintained WordPress plugin. Choose Memcached only if your infrastructure already standardises on it.

How much memory should I give Redis?

256 MB is enough for a typical content site; 512 MB to 1 GB suits a busy WooCommerce shop with a large catalogue. Watch used_memory_human against maxmemory_human and raise it if evictions are frequent. Always set maxmemory-policy to allkeys-lru.

Is object caching safe for WooCommerce?

Yes, and it helps considerably, because carts and checkout can never be page cached. The rule is not to add full-page caching to cart, checkout and account pages. Test stock behaviour under concurrent load after enabling it, since that is where a caching problem would show.

Why is my Redis hit rate so low?

Usually something flushing the cache constantly, often a plugin calling wp_cache_flush on every request, or a cache too small for the working set so keys are evicted before reuse. Check redis-cli info stats for evicted_keys, and raise maxmemory if that number is climbing.

Put this into practice on G7Cloud

Every site runs in its own dedicated container behind ScaleShield, with daily backups that are restore-tested every night. Start on the free plan, no card needed.

About G7Cloud Engineering

Platform team

Articles written by the engineers who build and run G7Cloud: UK managed hosting and the AI Website Builder. We write about what we operate every day: containers, backups, databases, and the small-business websites that run on them.

More about G7Cloud →