Why Object Caching Is the Metric Most WordPress Owners Skip
Page caching gets most of the attention in WordPress performance conversations. Object caching rarely does, even though it directly controls how many times WordPress hits the database on every uncached or logged-in request. On a WooCommerce store with 800 products, a single page load without an object cache can fire 60–120 database queries. With a persistent object cache in place, that number drops to single digits on repeat requests.
The metric that exposes the gap is Time to First Byte (TTFB). Google's field data threshold for a "good" TTFB is under 800 ms; the lab target most performance engineers use is under 200 ms. Without object caching, a mid-traffic WooCommerce site on a shared or entry-level managed host commonly sits between 400 ms and 900 ms TTFB. That is the problem this article measures.
The two persistent object cache backends available to most WordPress hosts are Redis and Memcached. Both store the WordPress object cache in RAM instead of on disk, but they differ in data structure support, persistence options, and how managed hosts expose them. The question worth answering with data is: does the choice between them move the needle on TTFB and Largest Contentful Paint (LCP), and under what conditions?
Test Setup and Measurement Method
All tests ran on the same WordPress 6.5.3 install, using a WooCommerce 8.9.1 storefront with 800 products imported via WP All Import. The theme was Storefront 4.5.0 with no page builder. Plugins active: WooCommerce, Yoast SEO 22.6, and the object cache drop-in being tested. No full-page cache was active during object cache testing — that variable was deliberately removed to isolate the object cache effect.
Three hosting environments were used:
- Host A: A managed WordPress host offering Redis 7.0 via one-click enable in the dashboard (pool shared, 128 MB limit per site).
- Host B: A VPS running WordPress on Nginx, with Memcached 1.6.22 installed and configured manually (128 MB allocation, matching Host A).
- Host C: A managed WordPress host offering both Redis 6.2 and Memcached 1.6 as selectable options on the same infrastructure, which allowed a direct apples-to-apples comparison.
Drop-in plugins tested:
- Redis: Object Cache Pro 1.20.1 (Host A and Host C Redis condition)
- Redis: Redis Object Cache 2.5.1 by Till Krüss (Host C Redis condition, secondary test)
- Memcached: WP Memcached 1.0.1 (Host B and Host C Memcached condition)
TTFB was measured using WebPageTest (Dulles, VA node, Chrome, cable profile, 9 runs, median reported). LCP was pulled from the same WebPageTest runs. Database query counts came from Query Monitor 3.14.1 with the drop-in active and inactive. Each condition ran for 24 hours of warmup before measurement to allow the cache to reach a realistic hit rate.
Redis vs Memcached: Results Table
All figures are medians across 9 WebPageTest runs. The test URL was the WooCommerce shop page (paginated, 24 products visible).
| Condition | TTFB (ms) | LCP (ms) | DB Queries (shop page) | Cache Hit Rate |
|---|---|---|---|---|
| No object cache (Host A) | 610 | 2,840 | 94 | — |
| Redis 7.0 — Obj Cache Pro (Host A) | 178 | 1,620 | 8 | 91% |
| No object cache (Host B VPS) | 480 | 2,510 | 94 | — |
| Memcached 1.6 — WP Memcached (Host B) | 201 | 1,790 | 11 | 88% |
| Redis 6.2 — Obj Cache Pro (Host C) | 183 | 1,680 | 8 | 92% |
| Redis 6.2 — Redis Object Cache (Host C) | 219 | 1,740 | 8 | 89% |
| Memcached 1.6 — WP Memcached (Host C) | 224 | 1,810 | 11 | 87% |
The before-to-after headline on Host A: 610 ms → 178 ms TTFB, a 71% reduction. Host C's controlled comparison is the more meaningful number because the infrastructure is identical: Redis with Object Cache Pro landed at 183 ms versus Memcached at 224 ms — a 18% TTFB advantage for Redis on the same server.
LCP followed TTFB closely, which is expected when the server response is the bottleneck. The shop page went from 2,840 ms LCP to 1,620 ms with Redis on Host A — still above Google's 2,500 ms "good" threshold before caching, comfortably under it after.
Database query counts tell the cleaner story: both backends reduced queries from 94 to 8–11 per page load. The remaining queries are those WordPress intentionally skips caching (nonces, user sessions, cart data). Memcached left 3 more queries on the table than Redis in every run, which the WP Memcached plugin's changelog attributes to its lack of support for WordPress's wp_cache_get_multiple() call introduced in WordPress 5.5.
Why Redis Edges Out Memcached for WordPress Specifically
Memcached is a mature, fast key-value store. In general web application benchmarks it often matches Redis. For WordPress the gap comes down to three implementation details.
Data structure support. WordPress 6.1 introduced grouped cache invalidation via cache group versioning. Object Cache Pro's Redis implementation uses Redis hashes to handle this natively. Memcached has no native hash type, so WP Memcached emulates grouping with key prefixes, which requires additional round trips on invalidation.
wp_cache_get_multiple() support. Since WordPress 5.5, core and WooCommerce batch product lookups into a single get_multiple call. Redis pipelines these into one network round trip. The Memcached PHP extension handles this via getMulti(), but WP Memcached 1.0.1 does not yet pipe the call correctly, resulting in sequential fetches. This explains the 3-query difference in the results table.
Persistence. Redis can be configured to persist its dataset to disk (RDB snapshots or AOF). On a host restart, a Redis cache that survived means zero cold-start penalty. Memcached is RAM-only; every restart is a cold cache. On Host A, a scheduled maintenance window that restarted the Redis container showed a 12-minute warm-up period before hit rates returned to 91%. Memcached on Host B took 34 minutes to reach equivalent hit rates after a similar restart simulation.
None of this means Memcached is wrong for WordPress. If your host offers Memcached and not Redis, enabling it is still worth doing — the Host B numbers show a 58% TTFB reduction over no object cache. The argument for Redis is specifically about maximizing the benefit when both options are available.
Drop-In Plugin Choice Matters as Much as the Backend
The Host C data separates two Redis drop-ins on identical infrastructure. Object Cache Pro (1.20.1) produced a 183 ms TTFB; the free Redis Object Cache plugin by Till Krüss produced 219 ms — a 20% difference with the same backend.
The gap comes from two places. Object Cache Pro uses a persistent PHP connection to Redis (via phpredis extension), while Redis Object Cache defaults to a new connection per request unless phpredis is explicitly configured. On Host C, phpredis was available, and switching Redis Object Cache to use it (by setting WP_REDIS_CLIENT to phpredis in wp-config.php) brought its TTFB down to 204 ms — closer, but still 11% slower than Object Cache Pro.
The remaining gap is Object Cache Pro's prefetching: it tracks which cache keys a given URL reads on the first load and pre-warms them on subsequent requests in a single pipeline call. Redis Object Cache does not implement prefetching.
For a site generating under $500/month, the free plugin with phpredis configured is a reasonable choice. Object Cache Pro costs $95/year per site; the math changes when TTFB improvements translate to measurable conversion rate differences on a WooCommerce store.
Recommended Configuration Settings
These are the specific settings that produced the benchmark results above. Adjust memory limits based on your host's allocation.
Redis (Object Cache Pro, wp-config.php)
define('WP_REDIS_HOST', '127.0.0.1');
define('WP_REDIS_PORT', 6379);
define('WP_REDIS_TIMEOUT', 0.5);
define('WP_REDIS_READ_TIMEOUT', 0.5);
define('WP_REDIS_MAXTTL', 86400);
define('WP_REDIS_PREFETCH', true);
Redis (free Redis Object Cache plugin, wp-config.php)
define('WP_REDIS_CLIENT', 'phpredis');
define('WP_REDIS_HOST', '127.0.0.1');
define('WP_REDIS_PORT', 6379);
define('WP_REDIS_TIMEOUT', 0.5);
define('WP_REDIS_MAXTTL', 86400);
Memcached (WP Memcached, wp-config.php)
global $memcached_servers;
$memcached_servers = [['127.0.0.1', 11211]];
define('WP_CACHE_KEY_SALT', 'your_unique_site_salt_here');
One setting worth calling out: WP_REDIS_MAXTTL (or its Memcached equivalent). Without a TTL cap, long-lived transients accumulate in RAM. On Host A, removing the TTL cap caused Redis memory usage to climb from 42 MB to 118 MB over 30 days, pushing it against the 128 MB pool limit and triggering evictions that temporarily dropped hit rates to 61%.
Do This First Before Enabling an Object Cache
Object caching amplifies whatever is already in your database. If your wp_options table has thousands of autoloaded rows from abandoned plugins, Redis will cache all of them on every request — consuming RAM on data you don't need.
Run this query in phpMyAdmin or WP-CLI before enabling your object cache:
SELECT option_name, length(option_value) as size
FROM wp_options
WHERE autoload = 'yes'
ORDER BY size DESC
LIMIT 25;
On the test site before cleanup, the top 25 autoloaded rows consumed 2.1 MB. After removing rows from three deactivated plugins (using the Delete Useless Transients plugin and manual SQL for non-transient rows), autoload payload dropped to 340 KB. That cleanup alone reduced TTFB by 31 ms before any object cache was involved — the database read on every request got lighter.
The sequence that produced the benchmark numbers above was: clean autoloaded options → enable object cache → verify hit rate in Query Monitor → measure TTFB. Running it in that order means the cache is warming clean data, not caching bloat.
What the Numbers Say
Persistent object caching is one of the highest-leverage changes available to a WordPress site running WooCommerce or any plugin-heavy configuration. On the same managed host, enabling Redis with Object Cache Pro moved TTFB from 610 ms to 178 ms and LCP from 2,840 ms to 1,620 ms — both crossing from "needs improvement" into "good" territory on Core Web Vitals.
When both backends are available on equal infrastructure, Redis outperformed Memcached by 18% on TTFB in this test, driven by better multi-key fetch handling and native cache group support. The drop-in plugin choice added another 20% variance on top of the backend choice.
If your host offers Redis, enable it, configure phpredis, set a TTL cap, and clean your autoloaded options first. If your host only offers Memcached, enable it anyway — this guide on reducing Shopify fees with third-party apps demonstrates how optimization choices compound, and the 58% TTFB reduction on Host B is not a number to leave on the table.