WordPress object caching: when Redis helps and what to measure first

Establish whether database work is the bottleneck

Measure query count/time on representative uncached PHP requests before adding Redis or another object backend. A slow external API, PHP computation, or large uncached page will not become fast because object caching exists.

Identify repetitive option, metadata, and query patterns that a persistent cache can actually reuse.

Size memory and eviction behavior

Persistent cache data consumes RAM. Choose a maxmemory policy appropriate to ephemeral cache data and monitor used memory, evictions, hit rate, connection count, and latency.

Do not place irreplaceable application state in a cache instance configured to evict keys.

Protect network and authentication

Bind Redis/cache services only where the application needs them; do not expose them openly to the internet. Use authentication/ACLs and firewall/private paths appropriate to the deployment.

If several sites share a backend, use safe key prefixes/database separation supported by the WordPress cache implementation.

Test invalidation and plugin compatibility

Change posts, options, users, products, and plugin settings and confirm updates appear promptly. Keep a documented cache flush procedure for troubleshooting without treating flush-all as the normal solution.

• Measure DB bottleneck first.
• Monitor memory/evictions/hit rate.
• Keep cache private.
• Test invalidation on real changes.