HomeMethod

Knowledge

Web VitalsTechniquesSnippetsAnswersImpactsBottlenecks

Object Cache (Redis)

Cache WordPress database queries in RAM so repeated lookups take microseconds instead of milliseconds.

Overview

WordPress executes 30–100+ database queries per page request for options, user data, post metadata, and transients. Without an object cache, every query hits MySQL on every request — even if the result is identical every time. Redis or Memcached stores query results in RAM and serves them in under 1 ms, compared to 5–50 ms per MySQL query. On a high-traffic WordPress site, the object cache is the single most impactful server-side optimisation after a full-page cache.

Impact grade, A+ to D: how much of the Lighthouse score this technique can move. Unaffected: TBT, CLS.

The Problem

WordPress’s default in-memory object cache lives only for a single PHP request — nothing persists across page loads. Each new request rebuilds the same option lookups, widget queries, and post meta fetches from scratch. On pages with complex queries — WooCommerce product listings, ACF meta fields, membership checks — PHP wait time (TTFB) can reach 500–2000 ms entirely from database round trips.

Performance Impact

LCP

100–500ms

faster HTML delivery means browser starts fetching LCP image sooner

FCP

100–600ms

TTFB drops directly reduce time to first byte of HTML

SI

100–400ms

all content visible sooner when HTML generation is faster

TTFB

repeated database queries served from memory; PHP execution time drops from hundreds of milliseconds to single digits

Risk: Low

stale data risk is low — WP object cache invalidates automatically on save

How it works

  1. 01

    Install Redis on the server

    Install Redis via the OS package manager (apt install redis-server). Redis runs as a background service on localhost port 6379. No external network exposure needed — WordPress and Redis communicate over a local Unix socket for minimum latency.

  2. 02

    Drop in the WordPress object cache plugin

    Install the Redis Object Cache plugin (Till Krüss) or wp-redis. The plugin drops an object-cache.php file into wp-content/ — WordPress loads this file automatically and all wp_cache_*() calls go to Redis instead of the in-memory array.

  3. 03

    Configure persistence and eviction

    For WordPress, use Redis in LRU eviction mode (maxmemory-policy allkeys-lru) with enough RAM to hold the working set — typically 64–256 MB. WordPress handles cache invalidation itself; Redis only needs to evict when memory is full.

  4. 04

    Verify cache hits

    Install Query Monitor or use redis-cli monitor to observe cache activity. On a warm cache, you should see mostly SET operations on first page load and GET hits on repeat loads. The number of database queries should drop from 50–100 to 5–15 on cached pages.

Limitations

  • Redis requires server access to install and configure — not available on all shared hosting plans.
  • Multisite WordPress installations need per-site cache key prefixes to prevent data leakage between sites.
  • If Redis runs out of memory and eviction is misconfigured, it can return stale or empty data — monitor memory usage and set an appropriate maxmemory limit.

Common Mistakes

Installing the object cache plugin without configuring Redis maxmemory

Without a memory limit, Redis grows unbounded and can exhaust server RAM. Set maxmemory to 128–256 MB and maxmemory-policy to allkeys-lru in redis.conf so eviction is orderly.

Using object cache as a substitute for a full-page cache

Object cache reduces PHP/DB time per request but still executes PHP on every request. Combine it with a full-page cache (page-cache technique) for logged-out users — the combination reduces TTFB from 300ms to under 20ms.

Test this techniqueCache AnalysisRun the tool

Need help applying this to your site?

Targeted fixes, not guesswork. We identify which techniques move the needle for your specific WordPress stack.

Start an Engagement
Support our family now