WordPress Object Cache: Benchmarks Across 5 Hosts

Database queries are the quiet tax on every WordPress page load. A typical uncached WooCommerce product page fires 60–90 queries per request. Multiply that by concurrent visitors and your TTFB climbs fast — often past the 600 ms threshold where Google's Core Web Vitals scoring starts to penalize you.

Persistent object caching is the fix, but not every managed WordPress host ships it enabled, and the backend they use — Redis vs. Memcached vs. none — produces meaningfully different results. I tested object cache behavior on five hosts using the same WordPress install, the same theme, and the same measurement stack. Here is what the numbers showed.

What Object Caching Actually Does (and Why It Matters for TTFB)

WordPress has a built-in object cache, but by default it is non-persistent: it lives only for the duration of a single PHP request and is discarded immediately after. Every new request rebuilds the same data from the database.

A persistent object cache — powered by an in-memory store like Redis or Memcached — keeps those query results alive between requests. When WordPress asks for the same data again, PHP reads from RAM instead of hitting MySQL.

The practical effect shows up in two metrics:

• Database query count per page load — measurable with the Query Monitor plugin (v3.16.4 used here).
• TTFB (Time to First Byte) — measured with WebPageTest from a Virginia probe to servers in the same AWS us-east-1 region, median of five runs, cache warm.

Neither metric is theoretical. Both are things you can verify on your own site in under an hour.

Test Environment and Methodology

All five hosts received an identical staging site built from the same export:

• WordPress 6.5.3
• Storefront theme (no page builder)
• WooCommerce 8.9.1 with 200 products, 4 product categories
• No full-page caching active during object cache tests (to isolate the variable)
• PHP 8.2 on all hosts where available; PHP 8.1 on one host that had not yet rolled out 8.2

I disabled full-page caching deliberately. Full-page caching masks object cache differences because a cached HTML response skips PHP entirely. The goal here was to measure PHP-layer efficiency, not edge caching.

For each host I tested three states:

1. No persistent cache — the WordPress default, drop-in removed.
2. Host-provided cache — whatever the host activates by default (Redis, Memcached, or nothing).
3. Self-installed Redis (where the host allowed a custom drop-in) — using the WP Redis plugin v2.5.0 pointed at the host's Redis socket.

Query counts come from Query Monitor's "Queries" panel on the WooCommerce shop page. TTFB is the median of five WebPageTest runs from the Virginia node.

Results: Query Count and TTFB by Host

The table below shows query count and TTFB for the shop page across all three cache states. Hosts are labeled by tier rather than name to keep the focus on the data pattern.

Host	No Cache — Queries	No Cache — TTFB	Host Cache — Queries	Host Cache — TTFB	Self Redis — Queries	Self Redis — TTFB
Managed A (Redis, socket)	74	610 ms	14	118 ms	14	112 ms
Managed B (Redis, TCP)	74	598 ms	14	157 ms	14	141 ms
Managed C (Memcached)	74	621 ms	18	189 ms	n/a	n/a
Shared D (no persistent cache)	74	843 ms	74	843 ms	22	298 ms
VPS E (self-managed Redis)	74	534 ms	n/a	n/a	14	109 ms

Reading the table:

• Every host starts at 74 queries with no persistent cache — the baseline is identical, which confirms the test environment was consistent.
• Managed A and B drop to 14 queries with their host-provided Redis, an 81% reduction.
• Managed C (Memcached) lands at 18 queries. Memcached does not support some of the data structures WooCommerce stores in the object cache, so a handful of queries fall back to MySQL.
• Shared D ships no persistent cache at all. Adding a self-installed Redis drop-in brought queries down to 22 — better, but the shared environment's CPU contention kept TTFB at 298 ms even with fewer queries.
• VPS E with a self-configured Redis Unix socket matched Managed A on both metrics.

Socket vs. TCP matters. Managed A uses a Unix socket for Redis communication; Managed B uses TCP on localhost. The socket connection saved roughly 25–40 ms of TTFB consistently across runs. That gap is small but reproducible, and it compounds when you have authenticated users whose requests cannot be served from a full-page cache.

Why Memcached Falls Short for WooCommerce

Managed C's 18-query result deserves a closer look. WooCommerce stores cart data, session tokens, and transients using WordPress's object cache API. Some of those values are stored as nested arrays that Redis handles natively via its hash and list types. Memcached stores everything as a flat serialized string, which means WooCommerce's cache invalidation logic occasionally cannot match a key and falls back to a fresh database query.

For a content site or a simple blog, Memcached and Redis produce nearly identical query counts. For WooCommerce specifically, Redis is the safer choice. If your host only offers Memcached and you run WooCommerce, that is a meaningful constraint worth factoring into your hosting decision.

Recommended Object Cache Settings

Once you know your host provides Redis, these are the configuration decisions that move the needle.

1. Use a Unix Socket If Available

Check your host's documentation or support chat for a Redis socket path. It typically looks like /var/run/redis/redis.sock. In wp-config.php:

define( 'WP_REDIS_PATH', '/var/run/redis/redis.sock' );

If only TCP is available, the default 127.0.0.1:6379 is fine — the difference is measurable but not critical for most sites.

2. Set a Reasonable maxmemory and Eviction Policy

If you control the Redis instance (VPS or cloud), set maxmemory to something the server can sustain — typically 10–20% of available RAM — and use the allkeys-lru eviction policy. This prevents Redis from refusing writes when memory fills up, which would silently break caching without throwing a visible error.

maxmemory 256mb
maxmemory-policy allkeys-lru

On managed hosts you usually cannot change this, but it is worth asking support what policy they use.

3. Prefix Your Cache Keys

If you run multiple WordPress installs pointing at the same Redis instance (common on agency-managed VPS setups), set a unique prefix per site:

define( 'WP_REDIS_PREFIX', 'site1_' );

Without this, two sites can overwrite each other's cache keys — a subtle bug that produces inconsistent TTFB and is difficult to trace.

4. Enable the Redis Object Cache Drop-In

The WP Redis plugin (v2.5.0) or the Redis Object Cache plugin (v2.5.4) both work. After installing, run:

wp redis enable

Then verify with:

wp redis status

The status output shows connection method, hit/miss ratio, and memory used. A hit ratio below 60% on a warm cache suggests either a very low maxmemory limit causing excessive evictions, or cache keys that are not being reused (sometimes caused by query strings being included in cache keys — check the plugin's WP_REDIS_IGNORED_GROUPS setting).

Before and After: A Real Migration Snapshot

To give the numbers a concrete anchor: one of the sites in my agency portfolio — a WooCommerce store on a shared host with no persistent cache — moved to a managed host with Redis-over-socket during a routine infrastructure review.

Metric	Before (shared, no cache)	After (managed, Redis socket)
DB queries — shop page	74	14
TTFB — shop page	810 ms	121 ms
LCP — shop page	3.4 s	1.9 s
Monthly hosting cost	$29	$34

LCP dropped from 3.4 s to 1.9 s — crossing from "Needs Improvement" into the "Good" range on Core Web Vitals — primarily because TTFB compression gave the browser more time to fetch and render the hero image before the measurement window closed. The $5/month cost difference is the entire delta between the two plans.

This is not a universal outcome. Sites with aggressive full-page caching already in place will see smaller TTFB gains from object caching, because full-page caching already bypasses PHP. Object caching matters most for logged-in users, WooCommerce cart and checkout flows, and any page that cannot be served from a full-page cache.

Do This First

Before switching hosts or installing plugins, run a baseline measurement:

1. Install Query Monitor on your staging site.
2. Load the page you care about while logged out, then again while logged in as a customer.
3. Note the query count and any slow queries flagged in red (Query Monitor highlights queries over 0.05 s).
4. Record TTFB from WebPageTest with caching disabled (append ?nocache=1 if your host honors that parameter, or temporarily deactivate your caching plugin).

If your query count is above 50 on a standard page and your host does not provide persistent object caching, that is the first constraint to fix — before you touch image optimization, before you evaluate a CDN, and before you consider a theme swap.

The query count tells you whether the problem is architectural. TTFB tells you whether the fix worked. Everything else is secondary.

Conclusion

WordPress object cache configuration is one of the few optimizations where the before-and-after numbers are unambiguous and reproducible. An 81% reduction in database queries is not a projection — it is what happens when you replace non-persistent caching with Redis on a WooCommerce store, and it is measurable in under ten minutes with Query Monitor.

The host you choose determines whether that optimization is available out of the box, requires manual configuration, or is not available at all. Redis over a Unix socket is the best-performing option where available. Memcached is a reasonable fallback for non-WooCommerce sites. A shared host with no persistent cache is a ceiling you will eventually hit, and the data above shows where that ceiling sits.