WordPress Server Caching: Redis, OPcache, and CDN Tips

If your WordPress site feels like it sprints sometimes and crawls other times, you’re probably feeling the limits of dynamic rendering. The good news: you don’t need to rebuild your stack to go fast. Caching is the pragmatic middle ground that turns the same hardware into a noticeably quicker experience. Think of it as putting your most-used snacks on the counter instead of in the pantry: fewer steps to get what you want.

In this guide, we’ll cover three layers that reliably move the needle in 2024–2026-era WordPress stacks: Redis object caching, PHP OPcache, and smart CDN configuration for edge caching. You’ll get practical settings, gotchas to avoid, and the why behind each layer—so you can ship speed with confidence and keep Core Web Vitals (including INP, which replaced FID in 2024) in a happy place.

Where Caching Fits in the WordPress Request

A typical WordPress page render touches several components:
– PHP loads WordPress and your theme/plugins.
– WordPress queries MySQL/MariaDB.
– PHP compiles scripts and executes them.
– The server sends HTML plus assets (CSS/JS/images) to the browser.

Caching attacks the expensive parts:
– OPcache keeps PHP code precompiled in memory (skips recompiling on each request).
– Redis stores data that WordPress repeatedly asks the database for (options, queries, transients).
– A CDN caches assets—and even full HTML for anonymous users—near your visitors to cut network latency and TTFB.

These layers don’t replace each other; they stack.

Redis Object Caching: Cut Database Trips

What it is and why it matters

WordPress is chatty with the database. Object caching stores frequently requested results (like wp_options, query results, transients) in memory so subsequent requests don’t touch MySQL. This is especially impactful for:
– Logged-in traffic (admins, membership sites, LMS).
– WooCommerce stores (cart, product loops, search).
– API endpoints and wp-admin.
– Sites with complex themes/plugins that trigger many queries.

WordPress itself nudges you here: in Site Health, many installs see a recommendation to use a persistent object cache.

How to implement

– Install Redis server (Redis 6+ recommended; Redis 7 adds better ACLs and IO threading).
– Use the PHP extension:
– phpredis (widely available), or
– Relay (a high-performance alternative for PHP by cachewerk; particularly fast under concurrency).
– Add a WordPress plugin to wire it up:
– Redis Object Cache (by Till Krüss) is the popular choice; supports diagnostics, compression, and igbinary serialization.

Basic checklist:
– Bind Redis to localhost or a private interface; avoid exposing it publicly.
– If using TCP, enable a password/ACL. Prefer a Unix socket for performance and simplicity on the same host.
– Give Redis enough memory for your working set (start around 256–512MB for small sites; scale up for WooCommerce or large catalogs).
– Choose an eviction policy:
– allkeys-lru is a safe default if you want Redis to evict least-recently-used keys automatically.
– volatile-lru if you only want keys with TTLs eligible for eviction.
– Enable igbinary serialization if supported; it reduces payload size and CPU overhead vs PHP serialize().
– Set reasonable TTLs for cached items to avoid stale data. Many plugins handle this; you can also set WP_REDIS_MAXTTL in wp-config.php.

Monitoring:
– Watch keyspace_hits vs keyspace_misses in Redis INFO.
– Track memory usage and evictions. If evictions rise during peak traffic, increase memory or tune TTLs.
– For larger setups, export metrics to Prometheus/Grafana with the Redis Exporter.

Current landscape (industry notes):
– Managed Redis (AWS ElastiCache, Azure Cache for Redis, GCP Memorystore, Upstash) offloads ops. Latency matters—co-locate it with your web server or use a private network to minimize round trips.
– Relay can materially outperform phpredis in PHP-heavy WordPress stacks; worth testing if you’re CPU-bound.

Pitfalls to avoid:
– Publicly exposed Redis is a security incident waiting to happen—lock it down.
– Don’t run Redis and your database starved on the same tiny VM; they’ll compete for RAM and swap, which kills performance.
– Avoid cache stampedes on hot keys; ensure plugins set TTLs and consider a small jitter where supported.

OPcache: Stop Recompiling PHP on Every Request

OPcache ships with PHP and stores compiled PHP bytecode in memory. Without it, each request re-parses and compiles the same code—wasteful and slow.

Why it matters now:
– With PHP 8.2 and 8.3, WordPress performance improved notably, but the gains depend on a warm OPcache.
– INP-focused Core Web Vitals put pressure on server response time (TTFB is still a key driver). OPcache reduces CPU time per request, freeing headroom for concurrency.

Recommended settings (php.ini):
– opcache.enable=1 (ensure it’s on for FPM/CLI as needed)
– opcache.memory_consumption: 256–512 (MB). Heavier plugin stacks or multisite may need more.
– opcache.max_accelerated_files: 100000 (or higher for big codebases).
– opcache.interned_strings_buffer: 32–64 (MB).
– opcache.validate_timestamps:
– 1 in development with opcache.revalidate_freq=2 (seconds).
– 0 in production if your deploy process restarts PHP-FPM (safer, faster).
– opcache.jit: For WordPress, leave at 0 or a conservative setting; JIT rarely helps IO-bound CMS workloads.

Operational tips:
– Warm the cache after deploys (e.g., hit your sitemap with curl or a warmup tool) to avoid a slow first wave.
– Avoid full cache flushes at peak traffic—do rolling PHP-FPM reloads instead.
– Track status with opcache_get_status (hit rate and memory usage). If you see frequent restarts or “OOM,” raise memory or max_accelerated_files.

Compatibility:
– WordPress 6.5+ runs well on PHP 8.2/8.3. Upgrade if you’re on anything older than 8.1; it’s practically free speed with maintained security.

CDN Caching: Move the Site Closer to Your Users

A CDN reduces latency by serving content from edge locations near visitors. Done well, a CDN can cache static assets and even full HTML for anonymous users, slashing TTFB and stabilizing Core Web Vitals across regions.

Providers to consider:
– Cloudflare (broad features, including free tier, APO for WordPress, Workers).
– Fastly (excellent edge logic, strong purge-by-tag support).
– Bunny CDN (cost-effective, smart tiered cache).
– Amazon CloudFront (tight AWS integration).
– Akamai (enterprise reach).
– QUIC.cloud (integrates tightly with LiteSpeed server/page cache).

Edge caching HTML is the big win. But it requires precision.

What to cache, and what to skip

Cache:
– Anonymous HTML responses.
– Static assets: images, fonts, CSS, JS (with long max-age and immutable versions).
– Sitemaps (unless dynamically personalized—rare).

Skip or bypass:
– Logged-in sessions (cookies starting with wordpress_logged_in_).
– WooCommerce cart/checkout, My Account, and any page with session/currency/personalization cookies (woocommerce_items_in_cart, wp_woocommerce_session_, woocommerce_cart_hash).
– wp-admin, wp-login.php, previews (preview=true), and REST endpoints that require auth.

Use headers to control behavior:
– Cache-Control: public, s-maxage=3600, stale-while-revalidate=60
– For HTML at the edge, prefer s-maxage (shared cache) and keep max-age modest if content updates frequently.
– Add a Vary on cookies or use CDN rules to bypass when specific cookies are present.

Purge strategy:
– Purge on update: When you publish or update posts, trigger a targeted purge.
– Cloudflare: WordPress plugin can purge URLs or tags; APO automates much of this.
– Fastly: Use surrogate keys (tags) to purge related pages efficiently.
– Avoid site-wide purges in production unless there’s a global template change.

Modern web features to enable:
– HTTP/3 (QUIC): Improve performance on flaky or mobile networks.
– TLS 1.3 and Brotli compression.
– Early Hints (103): If your CDN supports it, preloads critical CSS/JS faster than standard hints.
– Image optimization at the edge: Convert to WebP/AVIF, resize on demand. This can be a larger real-world improvement than any single code tweak.

UTM parameters and cache keys:
– Many marketing links add query strings. Configure your CDN to ignore common tracking params (utm_*, gclid, fbclid) in cache keys to increase hit rates without serving wrong content.

Common patterns for WordPress:
– “Cache Everything” page rules with cookie-based bypass for Cloudflare.
– Fastly VCL to bypass for specific cookies and add surrogate keys.
– Nginx FastCGI cache at origin plus a CDN in front (use CDN for assets and regional distribution, origin cache for HTML). Just be sure purge logic stays synchronized.

How Redis, OPcache, and a CDN Work Together

– OPcache speeds up PHP itself. You’ll see lower CPU, better concurrency, and faster TTFB under load.
– Redis reduces database load, especially for dynamic, logged-in traffic. Admin pages and WooCommerce catalog pages benefit most.
– A CDN takes pressure off your origin by serving cached HTML to anonymous visitors and all static assets globally.

The combined effect:
– Anonymous users: TTFB can drop from ~500–1200 ms to ~80–250 ms when HTML is cached at the edge and assets are optimized.
– Logged-in/admin/WooCommerce: Redis + OPcache often cuts backend time by 30–70%, which helps INP and overall responsiveness.
– Stability: Reduced variance during traffic spikes (fewer cache misses against your database, less CPU thrash from PHP recompilation).

Short analogy: Think of the CDN as moving your warehouses closer to your customers, OPcache as pre-assembling the shelves, and Redis as keeping a rolling cart of bestsellers at arm’s reach. That’s two analogies—enough said.

Practical Configuration Starters

OPcache (php.ini):
– opcache.enable=1
– opcache.memory_consumption=256
– opcache.max_accelerated_files=100000
– opcache.interned_strings_buffer=32
– opcache.validate_timestamps=0 (production with deploy restarts)
– opcache.jit=0

Redis (redis.conf and tips):
– bind 127.0.0.1 or use a Unix socket (e.g., unixsocket /var/run/redis/redis.sock)
– protected-mode yes
– maxmemory 512mb (adjust to workload)
– maxmemory-policy allkeys-lru
– requirepass or ACLs if not on a private socket
– Enable igbinary in PHP if using phpredis; enable compression in your Redis Object Cache plugin if CPU allows.

Nginx headers for assets (example):
– Cache-Control: public, max-age=31536000, immutable (for versioned CSS/JS)
– For HTML at origin (when not using full edge cache): Cache-Control: public, s-maxage=600, stale-while-revalidate=60. Let your CDN honor s-maxage and purge on updates.

CDN rules:
– Bypass cache if Cookie contains wordpress_logged_in_, wp_woocommerce_session_, woocommerce_items_in_cart, woocommerce_cart_hash.
– Cache Everything for HTML paths otherwise, with an edgeside TTL (e.g., 10–60 minutes) plus automatic purges on publish/update.

Advanced Tips for Busy Sites

– Use page caching at the origin in addition to the CDN when possible (Nginx FastCGI cache, Varnish, LiteSpeed Cache). It provides a safety net if the CDN misses or gets bypassed.
– Consider surrogate keys/tags. Plugins or small middleware can tag content by post ID, category, and template. Fastly natively supports this; Cloudflare can approximate with Workers + KV/Tags.
– Use background purging and staggered warmups to avoid thundering herds after deploys.
– Monitor the whole pipeline:
– Redis: latency, hits/misses, evictions.
– OPcache: memory usage, revalidations, restarts.
– CDN: edge vs origin hit rate, TTFB by region, 499/5xx rates.
– Real-user metrics: INP, LCP, CLS by country and device class (field data beats lab tests).
– WooCommerce specifics:
– Ensure cart/checkout aren’t cached; confirm fragments or block-based cart/checkout are behaving.
– Cache catalog/listing pages for anonymous users at the edge with careful purging on product updates/price changes.
– Use a search service for scale (OpenSearch/Elasticsearch) and still cache result pages when parameters allow.

Mistakes That Kill Performance (or Break Sites)

– Caching wp-admin or logged-in HTML at the CDN. The WordPress admin bar magically appearing for strangers is a red flag you’ve cached the wrong thing.
– Tiny OPcache sizes (64–96MB) on large plugin stacks; you’ll churn and lose the benefits.
– Exposed Redis ports on the public internet.
– Full-site CDN purges for every small edit. Use targeted purges or tags.
– Letting query strings explode cache keys. Normalize or ignore tracking params.
– Staging sites pointing at production CDNs and purging live content by accident.
– Conflicting cache plugins and server caches stepping on each other. Choose one page-caching layer at origin and make sure it’s aware of the CDN’s behavior.

Quick Setup Checklists

Redis (Object Cache):
– Install Redis 6/7 and secure it (localhost/socket, password/ACL).
– Install phpredis or Relay; enable igbinary if using phpredis.
– Install Redis Object Cache plugin; enable persistent caching.
– Set sensible TTLs; monitor hits/misses and memory.
– Avoid eviction storms; size memory properly.

OPcache:
– Enable and allocate enough memory (≥256MB).
– Raise max_accelerated_files and interned_strings_buffer.
– Use validate_timestamps=0 in production with deploy restarts.
– Warm OPcache after deploys; avoid mid-peak flushes.
– Upgrade to PHP 8.2/8.3 for measurable gains.

CDN:
– Turn on HTTP/3, TLS 1.3, Brotli.
– Cache Everything for anonymous HTML with bypass on key cookies.
– Long-lived immutable caching for versioned assets.
– Purge by URL/tag on publish/update; avoid full purges.
– Normalize or ignore tracking params in cache keys.
– Add image optimization (WebP/AVIF) and consider Early Hints.

Field validation:
– Track Core Web Vitals in Search Console and your RUM tool.
– Watch TTFB by geo. If one region lags, validate edge hit rates there.
– Confirm WooCommerce/cart and admin bypass rules with test cookies.

What’s Changed Recently—and Why It Matters

– INP replaced FID as a Core Web Vitals metric (Mar 2024). While INP is a front-end metric, faster TTFB and stable server times reduce main-thread work and help overall responsiveness—especially on slower devices or long round trips.
– PHP 8.2/8.3 is mainstream in managed hosting; WordPress runs well on it. Combined with OPcache, it’s a low-effort upgrade path.
– Cloud providers have improved global footprints and added features like Early Hints, automatic image conversion, and programmable edges (Workers, VCL, Functions). This makes full-page caching safer and smarter.
– Redis 7 brings better security controls and performance characteristics. Managed offerings are broadly available at reasonable price points—object caching isn’t just for enterprise anymore.

Bottom Line

If you want a faster WordPress site without rewriting it, stack these three:
– OPcache to eliminate PHP recompilation.
– Redis to keep database-heavy paths quick, especially for logged-in sessions and commerce.
– A tuned CDN to cache HTML for anonymous users and optimize assets globally.

Measure, iterate, and resist the urge to add five caching plugins when one well-configured layer per tier will do. With a weekend of careful setup and validation, you can turn erratic performance into a predictable, fast baseline that holds up under traffic—and keeps both users and Core Web Vitals happy.