WordPress Caching Strategy: Redis & Page Cache

What this prompt does

This prompt makes the model a WordPress performance engineer designing a multi-layer caching strategy for a [site_type] serving [monthly_visitors] monthly visitors. It works through six layers: Redis object cache, full-page cache, fragment caching, invalidation rules, browser/CDN caching, and monitoring.

Object caching connects WordPress to Redis via [redis_plugin] with [redis_memory] under an LRU policy and a [key_prefix] so multiple sites can share one instance. Page caching uses [page_cache_plugin] with a [page_cache_ttl] TTL, excluding logged-in users, [excluded_pages], and [excluded_cookies]. Fragment caching covers [fragment_count] dynamic sections ([dynamic_fragments]) on their own TTLs. The invalidation map is the centerpiece: it purges only affected URLs on each content event rather than nuking everything.

The layering matters because each tier handles what the others cannot. Full-page caching serves complete HTML to anonymous visitors at a [page_cache_ttl] TTL, fragment caching keeps frequently changing sections fresh without a full purge, and Redis object caching accelerates the dynamic pages that can never be fully cached. Browser and [cdn_provider] CDN headers push static assets out to the edge with long lifetimes, while HTML stays under server control. The monitoring layer ties it together, tracking hit ratios toward [hit_ratio_target], Redis memory and eviction rate, and alerting when things slip, so the strategy stays measurable rather than hopeful.

When to use it

• A high-traffic site needs layered caching, not a single plugin toggle.
• You want Redis as a persistent object cache via [redis_plugin].
• Full-page caching must exclude carts, checkouts, and logged-in users.
• Parts of a page change often but should not trigger a full purge.
• You need precise invalidation so content updates appear without dumping the whole cache.
• You want hit-ratio monitoring against [hit_ratio_target] with alerts.

Example output

Expect a layered implementation plan: Redis object-cache config via [redis_plugin] with [key_prefix] and [redis_memory], full-page rules in [page_cache_plugin] at [page_cache_ttl] excluding [excluded_pages] and [excluded_cookies], fragment caching for [dynamic_fragments] with TTLs from [min_fragment_ttl] to [max_fragment_ttl], an event-to-purge invalidation map, browser and [cdn_provider] CDN headers, and a monitoring setup tracking hit ratio toward [hit_ratio_target] with alerts below [alert_threshold].

Pro tips

• Set [redis_memory] with an allkeys-lru policy so the cache evicts gracefully instead of erroring under pressure.
• Always exclude [excluded_pages] and [excluded_cookies] from page cache, or logged-in and cart states will leak.
• Use a [key_prefix] if Redis is shared, so sites do not collide on keys.
• Map each content event to the minimum set of URLs to purge; whole-cache flushes tank your [hit_ratio_target].
• Tune fragment TTLs between [min_fragment_ttl] and [max_fragment_ttl] per fragment rather than using one global value.
• Watch eviction rate alongside hit ratio; a high eviction rate means [redis_memory] is too small, not that caching failed.
• Preload the cache from the sitemap after a purge so the first visitor does not pay the cold-cache cost on a [monthly_visitors]-scale site.
• Gate the cache-debug query parameter to [dev_environments] only, so production responses never leak cache internals in their headers.