Running WordPress at Scale: Object Cache, Edge Caching, and Database Hygiene

WordPress Can Scale — If You Cache Properly

The claim that WordPress cannot handle high traffic is a myth. The reality is that uncached WordPress cannot handle high traffic. Out of the box, every page request triggers PHP execution and multiple database queries. At a few hundred concurrent visitors, an uncached WordPress site starts struggling. Add the right caching layers, and the same site can handle thousands of concurrent visitors without breaking a sweat.

This guide covers the caching strategies that make WordPress performant at scale: full-page caching, Redis object cache, CDN edge caching, and the database hygiene practices that keep everything running smoothly as your content and traffic grow.

Full-Page Caching

Full-page caching is the most impactful performance improvement you can make. Instead of generating every page from scratch on each request (running PHP, querying the database, rendering the template), a caching layer stores the complete HTML output and serves it directly. Subsequent requests for the same page skip PHP and the database entirely.

How It Works

When a visitor requests a page for the first time, WordPress generates the HTML normally. The caching layer stores this HTML. When the next visitor requests the same page, the cache serves the stored HTML in microseconds instead of the hundreds of milliseconds that WordPress needs to generate it. Cache entries expire based on a configured TTL, and they are purged when content is updated.

Implementation Options

• Server-level caching: Nginx FastCGI cache or Varnish sit in front of WordPress and cache responses at the web server level. This is the fastest option because WordPress is never invoked for cached requests.
• Plugin-level caching: WordPress caching plugins (WP Super Cache, W3 Total Cache, WP Rocket) generate static HTML files or store cached pages in memory. These are easier to configure than server-level caching but slightly less performant.

What to Exclude from Cache

Not every page should be cached:

• Logged-in user pages (the WordPress admin bar, personalized content)
• Shopping cart and checkout pages (user-specific data)
• Pages behind authentication
• POST request responses

Configure cache bypass rules for these cases. The standard approach is to skip caching when WordPress login cookies or WooCommerce cart cookies are present.

Redis Object Cache

While full-page caching handles the majority of traffic, dynamic pages — logged-in user dashboards, admin panels, WooCommerce account pages — cannot be full-page cached because they contain personalized content. These pages still need database queries, and this is where the object cache helps.

What the Object Cache Does

WordPress has a built-in object cache API that stores the results of database queries and computations in memory for the duration of a page request. By connecting this API to Redis (a persistent in-memory data store), cached objects survive across requests. The second visitor who triggers the same database query gets the result from Redis in under a millisecond instead of waiting for a database round-trip.

What Gets Cached

WordPress automatically caches frequently accessed data through its object cache: options, user metadata, post metadata, term data, and transients. Plugins and themes that use the WordPress object cache API benefit automatically. The effect is a dramatic reduction in database queries per page — from dozens or hundreds down to a handful.

Setup

Install Redis on your server, install a Redis object cache plugin for WordPress (the most common is the Redis Object Cache plugin), and configure the connection. Verify that it is working by checking the object cache status in the WordPress admin and monitoring Redis key counts and hit rates.

Sizing Redis

For most WordPress sites, Redis uses between 50 MB and 500 MB of memory, depending on the amount of cached data. Start with 256 MB allocated to Redis and monitor usage. Set a maxmemory policy (LRU eviction is standard) so Redis does not consume unbounded memory.

CDN Edge Caching

A CDN caches your static assets (images, CSS, JavaScript, fonts) and optionally your HTML pages on edge servers distributed globally. For a WordPress site, a CDN provides two benefits: reduced latency for visitors far from your server, and reduced load on your origin server because the CDN handles the majority of requests.

Static Asset Caching

Configure your CDN to cache static assets with long TTLs (one year for fingerprinted assets, one day for non-fingerprinted ones). WordPress's media library, theme assets, and plugin assets are all candidates. Use the CDN's URL or configure a subdomain (e.g., cdn.example.com) that points to the CDN.

Full-Page Edge Caching

Some CDN providers support caching the full HTML page at the edge. Combined with proper cache-control headers and cookie-based bypass rules, this means most visitors receive the complete page from the CDN — your origin server is only contacted for cache misses and dynamic requests. This is the fastest possible configuration and can handle virtually unlimited traffic for cacheable pages.

Cache Purging

When you publish or update content in WordPress, the CDN cache must be invalidated so visitors see the new content. Most WordPress caching plugins integrate with CDN purge APIs. Configure automatic purging on post publish, update, and delete events.

Database Hygiene

Even with caching, the database is still the backbone of WordPress. Keeping it healthy ensures that cache misses and dynamic pages remain fast.

Remove Post Revisions

WordPress stores every revision of every post indefinitely by default. A frequently edited post can accumulate hundreds of revisions, bloating the wp_posts table. Limit revisions to a reasonable number (5-10) by adding define('WP_POST_REVISIONS', 10); to wp-config.php. Clean up existing excessive revisions with a database optimization plugin.

Clean Up Transients

Transients are temporary cached values stored in the database. When Redis is configured as the object cache, transients are stored in Redis instead. But if you previously ran without an object cache, expired transients may linger in the database. Clean them up with a database optimization tool.

Optimize Tables

Run OPTIMIZE TABLE on your WordPress tables periodically to reclaim space from deleted and updated rows. For InnoDB tables (the default in modern MySQL), this rebuilds the table and defragments the data file. Schedule this during low-traffic periods, as it locks the table temporarily.

Index Analysis

Large WordPress sites with WooCommerce, custom post types, or complex queries may benefit from additional database indexes. Use the slow query log to identify queries that scan large numbers of rows, and add indexes on the columns used in WHERE, JOIN, and ORDER BY clauses. Be conservative — each index adds write overhead.

Monitoring Performance at Scale

As your WordPress site grows, monitor these metrics continuously:

• Cache hit ratio: Both full-page cache and Redis object cache. A healthy site has hit ratios above 90%. Low ratios indicate misconfigured cache rules or insufficient cache memory.
• Database query count per page: Monitor with a debug plugin in staging. Increasing query counts over time indicate plugin bloat or missing object cache integration.
• TTFB for uncached pages: This is your baseline performance. If uncached TTFB degrades over time, investigate database performance, PHP execution time, and external API calls.
• CDN bandwidth and cache status: Monitor how much traffic your CDN handles versus what reaches your origin. High origin traffic for static assets indicates CDN misconfiguration.

The Stack in Practice

A well-tuned WordPress stack for high traffic looks like this: CDN at the edge serving static assets and cached HTML → Nginx with FastCGI cache serving cached dynamic pages → PHP-FPM handling cache misses → Redis providing object caching → MySQL/MariaDB handling the remaining database queries. Each layer reduces the work for the layers below it, and the result is a WordPress site that handles enterprise-level traffic on mid-range infrastructure.

The Bottom Line

WordPress at scale is a solved problem — the solution is layered caching and database discipline. Full-page caching for the majority of traffic, Redis for dynamic page queries, CDN for global delivery, and regular database maintenance to prevent bloat. Implement these layers, monitor their effectiveness, and your WordPress site will perform well regardless of traffic volume.