WP Server-side Caching Explained

Server-side caching is the single highest-leverage performance intervention available to a WordPress site. Unlike client-side optimisations — image compression, script minification, lazy loading — server-side caching operates before the browser is involved at all, eliminating the most expensive parts of the WordPress request cycle at the origin. A correctly configured caching stack reduces time to first byte from hundreds of milliseconds to single digits, allows a modest virtual server to absorb traffic that would otherwise require significant infrastructure scaling, and removes the database server from the critical path for the vast majority of page requests.

1. Full-Page Cache

   Full-page caching is the most impactful layer in the WordPress server-side stack. After the first request for a given URL, the fully rendered HTML response is stored — either on disk or in memory — and served directly to all subsequent visitors without invoking PHP or querying the database. The result is a response time determined almost entirely by disk read or memory retrieval speed, not application execution time.

   Implementation varies by web server: LiteSpeed uses LSCache, a tightly integrated module with WordPress-aware cache invalidation; NGINX uses FastCGI cache, configured via fastcgi_cache_path directives and activated per location block; Apache typically relies on Varnish or a plugin-based page cache writing to disk. Each approach has different trade-offs in invalidation granularity, memory overhead, and compatibility with dynamic WordPress features. Cache vary rules — the logic determining which requests bypass the cache — must account for logged-in users, active sessions, WooCommerce cart and checkout pages, and query-string parameters. Misconfigured exclusions either break dynamic functionality or eliminate the cache benefit entirely.

2. Object Cache: Redis and Memcached

   WordPress has a built-in object cache API that stores the results of expensive database queries and computed values in memory for reuse within the same request. By default this cache is non-persistent — it is discarded at the end of every request. A persistent object cache backend extends it across requests, so values computed for one visitor remain available for the next without hitting the database again.

   Redis is the standard choice for WordPress persistent object caching. It supports data structures beyond simple key-value pairs, atomic operations, and optional persistence to disk — making it well-suited to WordPress transients, user session data, and WooCommerce session management. Memcached remains a viable alternative on simpler stacks but lacks Redis’s persistence and data structure richness. Activation on either backend requires the WP_CACHE constant set to true in wp-config.php and a drop-in object-cache.php file in wp-content/. Without this drop-in, the persistent backend is installed but WordPress never uses it.

3. OPcache: PHP Bytecode Caching

   Every PHP file WordPress loads — core files, plugin files, theme files — must be parsed and compiled into bytecode before execution. On a busy site without OPcache, this parsing overhead is incurred on every request for every PHP file in the stack. OPcache eliminates this by storing compiled bytecode in shared memory after the first compilation, making subsequent requests skip the parse-and-compile step entirely.

   OPcache is complementary to full-page caching rather than a substitute for it. On a full-page cache HIT, PHP does not run at all — OPcache is irrelevant. On a cache MISS, OPcache significantly reduces the execution time of that uncached request, directly improving TTFB for the user who triggered the miss. Key configuration values — opcache.memory_consumption, opcache.max_accelerated_files, and opcache.revalidate_freq — should be tuned to the size of the WordPress installation and the server’s available resources.

4. Transient Cache and Database Query Caching

   WordPress transients are a built-in API for storing arbitrary cached data with an expiry time in the database. Plugins use transients extensively to cache external API responses, computed menus, widget output, and expensive query results. Without a persistent object cache, transients are read from and written to the wp_options table on every request — adding database overhead rather than removing it. With Redis active, transients are stored in memory and retrieved without a database round-trip, which is the correct behaviour.

   MySQL’s own query cache — deprecated in MySQL 8.0 and removed entirely — was historically used to cache the results of identical SQL queries at the database engine level. Modern WordPress stacks rely on Redis object caching and full-page caching to achieve the same outcome at a higher and more effective layer. On high-traffic sites, a read replica database absorbs SELECT query load independently of the write primary, providing database-level scaling that caching alone cannot replace.

5. CDN and Edge Caching

   A Content Delivery Network extends caching beyond the origin data center to edge nodes distributed geographically close to visitors. For WordPress, CDN caching operates at two levels. Static asset caching — images, CSS, JavaScript, fonts — is always appropriate, has a near-100% cache hit rate, and requires no special configuration beyond pointing asset URLs at the CDN. Edge-level HTML caching is more complex: it requires cache invalidation logic tied to WordPress content publication events, and careful exclusion rules for authenticated requests and dynamic pages.

   Cloudflare’s cache rules allow full WordPress HTML pages to be cached at the edge, effectively relocating the full-page cache from the origin web server to the CDN network — dramatically reducing origin CPU and bandwidth consumption and improving response times globally without additional infrastructure. Cache purge on publish — triggered via Cloudflare’s API or a WordPress plugin — ensures visitors always receive current content after updates.

6. Cache Invalidation and Warm-Up

   A caching layer is only as useful as its invalidation logic. A cache that holds stale content indefinitely is as harmful as no cache at all — it serves outdated pages after content updates, breaks WooCommerce stock and pricing, and erodes visitor trust. Correct invalidation purges only the affected URLs when a post, page, or product is updated — not the entire cache — preserving the performance benefit for unaffected content while ensuring freshness where it matters.

   Cache warm-up addresses the cold-start problem: immediately after a full cache purge or server restart, all requests trigger cache misses until the cache is rebuilt through organic traffic. On high-traffic sites, this cold period can cause a temporary spike in CPU and database load. Proactive cache warm-up — crawling the site’s sitemap programmatically after a purge — rebuilds the cache before real visitors encounter misses, maintaining consistent server performance through content publication cycles and restoration events.