Optimising WordPress for High-Traffic Sites

A WordPress site that feels fast with 50 visitors can fall over completely with 5,000. The difference is rarely the theme or the hosting brand. It comes down to how many requests reach PHP and MySQL, and how much work each of those requests creates. Every optimisation worth doing for a high-traffic site answers one question: can we stop this request earlier, or make it cheaper?

This guide walks through the full stack as it stands in August 2026, from edge caching down to database tuning, with the actual tools, versions, and settings we use on client sites. It also covers the part most guides skip: what breaks first on community and WooCommerce sites, where logged-in users make classic page caching far less useful.

Understand the Request Path Before You Optimise It

When a visitor requests a page, the request can be answered at one of four layers, each more expensive than the last:

• CDN edge: the response is served from a server near the visitor. WordPress never sees the request.
• Page cache: your server returns a stored HTML file. PHP boots minimally or not at all.
• Object cache: PHP runs, but repeated database queries are answered from Redis or Memcached.
• Database: the full stack runs. WordPress core alone fires dozens of queries; a WooCommerce product page can run well past a hundred.

Your goal is to push as many requests as possible up this list. A site handling a traffic spike well is usually serving 90 percent or more of its requests from the first two layers.

Page Caching: Your First and Biggest Win

Full-page caching stores the rendered HTML of a page and serves it to the next anonymous visitor without touching PHP. On a busy blog or marketing site, this single change can take server load down by an order of magnitude.

The main options in 2026:

• LiteSpeed Cache 7.9 (updated August 2026): free, server-level caching if you run LiteSpeed or OpenLiteSpeed. The cache lives in the web server itself, so hits never reach PHP at all. Includes ESI (Edge Side Includes) for punching holes in cached pages, which matters for cart widgets and login states.
• WP Rocket 3.23.x: the strongest option on Nginx and Apache stacks where you cannot use server-level caching. Handles preloading, delayed JavaScript execution, and critical CSS alongside page caching.
• Nginx FastCGI cache: configured at the server level, no plugin needed for serving. Fastest raw option on Nginx, but cache invalidation needs a helper plugin such as Nginx Helper.

We compared the two most popular plugin options in detail in our WP Rocket vs LiteSpeed Cache breakdown if you want help choosing.

Two settings deserve attention regardless of which tool you pick. First, set sensible cache lifetimes: 10 to 12 hours for content sites, shorter for stores with frequent stock changes. Second, review your cache exclusion rules. Every excluded URL pattern is a page that hits PHP on every request, and bloated exclusion lists are one of the most common problems we find in performance audits.

Object Caching: Redis for Everything Dynamic

Page caching does nothing for logged-in users, carts, or REST API calls. That is where a persistent object cache earns its keep. WordPress already caches query results and options in memory during a single request; a persistent object cache keeps those values between requests, so a query that ran on the last page load is answered from RAM on this one.

Redis is the standard choice. The free Redis Object Cache plugin (2.8.0) supports PhpRedis, Relay, replication, Redis Sentinel, and clustering. For sites where object cache performance is critical, Object Cache Pro adds compression, async flushing, and much better observability, and the Relay PHP extension keeps a partial copy of the cache in PHP’s own memory, cutting round trips to the Redis server. If your host has moved to Valkey (the open-source Redis fork many providers adopted after the Redis licensing changes), it is protocol-compatible and works with the same plugins.

Memcached still works and remains a reasonable pick in multi-server setups where you want a flat, distributed cache with no persistence. But Redis’s richer data types, persistence options, and far better WordPress tooling make it the default recommendation.

One warning: an object cache amplifies whatever you put in it. A plugin that generates thousands of cache keys with poor expiry will fill Redis and trigger evictions. Set maxmemory (256 MB is a sane floor for a busy WooCommerce site) and use the allkeys-lru eviction policy so Redis discards the least-recently-used keys instead of refusing writes.

CDN and Edge Caching

A CDN does two jobs. The obvious one is serving images, CSS, and JavaScript from locations near your visitors. The bigger one for high-traffic sites is edge HTML caching: serving whole pages from the CDN so traffic spikes never reach your origin at all.

Cloudflare APO (Automatic Platform Optimization) caches full HTML at the edge and understands WordPress cookies well enough to bypass the cache for logged-in users and carts. Bunny CDN is a strong value pick for asset delivery, and both LiteSpeed Cache (via QUIC.cloud) and WP Rocket (via RocketCDN) ship integrated CDN options. If you are on a managed host, check what is already included before paying twice: most managed platforms now bundle an edge layer.

Database Tuning and the Autoload Trap

Under load, the database is usually the first backend component to saturate. Three areas matter most.

Autoloaded options

Every option in wp_options with autoload set to yes (or the newer on/auto-on values WordPress uses since 6.6) is loaded on every single request, cached or not at the PHP level. Years of installing and removing plugins leave orphaned rows behind. Check your total with:

SELECT SUM(LENGTH(option_value))/1024 AS kb FROM wp_options
WHERE autoload IN ('yes','on','auto-on','auto');

Under 800 KB is healthy. We regularly find sites carrying 3 to 10 MB of autoloaded data, which means megabytes deserialised on every request. WordPress 6.6 and later refuses to autoload new options larger than 150 KB by default, but it does not clean up existing bloat; that is a manual job with WP-CLI or a plugin such as Advanced Database Cleaner.

Server configuration

On a dedicated database server (MySQL 8.4 LTS or MariaDB 11.4/11.8 LTS), the setting that matters most is innodb_buffer_pool_size. Set it large enough to hold your working set, typically 60 to 70 percent of the RAM on a dedicated DB box. Turn on the slow query log with a one-second threshold and review it after any traffic event.

Table growth

Watch wp_postmeta, wp_usermeta, and session or log tables from plugins. A postmeta table with 5 million rows and unindexed meta queries will produce full scans that lock up the site under concurrency. Expired transients also accumulate in wp_options when no object cache is present; clear them with wp transient delete --expired on a cron.

PHP Workers and OPcache

PHP workers are the number of requests your server can execute simultaneously. Every request that misses the page cache occupies a worker for its full duration. When all workers are busy, requests queue, and queued requests are how a slow site becomes a down site: response times climb until upstream timeouts return 502 and 504 errors.

The maths is worth doing. If a dynamic request takes 400 ms and you have 10 workers, your ceiling is roughly 25 dynamic requests per second. You can raise that ceiling two ways: add workers (more CPU and RAM) or make each request faster (better caching, faster PHP). Do the second first.

Run PHP 8.4 or 8.5. PHP 8.5 shipped in November 2025 and both branches are in active support through at least the end of 2026; PHP 8.2 is security-fixes only and 8.1 is end of life. Each 8.x release has brought measurable throughput gains for WordPress workloads, so the upgrade is free performance. WordPress 7.1 (released 19 August 2026) runs cleanly on both.

Confirm OPcache is on and sized properly: opcache.memory_consumption=256, opcache.max_accelerated_files=20000, and opcache.validate_timestamps=0 on servers with controlled deployments (remember to reset OPcache on deploy). OPcache means PHP files are compiled once, not on every request, and it is the single most important PHP-level setting.

What Breaks First on Community and WooCommerce Sites

Here is the uncomfortable truth: everything above assumes most visitors are anonymous. On a BuddyPress community, a membership site, or a WooCommerce store at checkout time, they are not. Logged-in users and visitors with items in their cart bypass the page cache, so every one of them consumes PHP workers and database time.

In our experience the failure order under load looks like this:

1. PHP workers saturate. Logged-in traffic that would be a non-event on a blog exhausts a typical worker pool quickly. Symptoms: rising TTFB, then 502s.
2. admin-ajax and Heartbeat pile up. WooCommerce cart fragments and the WordPress Heartbeat API generate uncacheable POST requests from every open tab. Throttle Heartbeat and consider disabling cart fragments on non-shop pages.
3. The database locks up. Activity streams, notification queries, and meta-heavy checkout writes create contention exactly when traffic peaks.
4. Search dies. Default WordPress search is a LIKE query against wp_posts. Under load it is a denial-of-service you built yourself. Offload it to Elasticsearch (via ElasticPress) or a hosted service.

This is why community platforms need architecture, not just plugins. We wrote up how we approach this for our own products in Does BuddyNext Scale?, and the short answer to whether WordPress can handle heavy traffic is yes, with the caveats above.

Scaling Patterns When One Server Is Not Enough

Scale vertically first. A bigger server is operationally free compared to a cluster, and a well-tuned single box with 8 cores and NVMe storage carries a surprising amount of traffic. When you do need to scale out:

• Horizontal PHP scaling: multiple application servers behind a load balancer, all pointing at one shared Redis instance and one database. The application servers hold no state, so you can add and remove them freely.
• Offloaded media: move uploads to S3-compatible object storage (Amazon S3, Cloudflare R2, DigitalOcean Spaces) with a plugin such as WP Offload Media, served through your CDN. This keeps application servers stateless and removes file sync headaches entirely.
• Read replicas: a primary database for writes with one or more replicas for reads, wired up with HyperDB or LudicrousDB. Worth it mainly for read-heavy community sites.
• Queue the slow work: emails, webhook deliveries, and image processing belong in Action Scheduler jobs, not in the request that a customer is waiting on.

Reference Table: Layers, Tools, and What They Protect

Layer	Tools (Aug 2026)	What it protects	Helps logged-in users?
Edge / CDN	Cloudflare APO, Bunny CDN, QUIC.cloud	Origin bandwidth and PHP workers	Assets only
Page cache	LiteSpeed Cache 7.9, WP Rocket 3.23, FastCGI cache	PHP workers and database	No (ESI partially)
Object cache	Redis 7/8 or Valkey + Redis Object Cache 2.8, Object Cache Pro, Relay	Database query load	Yes
PHP runtime	PHP 8.4/8.5, OPcache, worker tuning	Request latency and concurrency ceiling	Yes
Database	MySQL 8.4 LTS / MariaDB 11.x, buffer pool tuning, autoload cleanup	The last line of defence	Yes
Search	ElasticPress + Elasticsearch	Database, on search-heavy sites	Yes

Load Test Before Traffic Does It for You

Do not wait for launch day to discover your ceiling. Grafana k6 is the tool we reach for: scriptable in JavaScript, runs from your own machine or CI, and can model realistic user flows rather than hammering one URL. Loader.io covers quick smoke tests.

Three rules for a useful test. Test logged-in flows and checkout flows, not just the homepage, because cached pages tell you nothing about your real ceiling. Ramp up gradually and watch where response times bend upward: that knee is your capacity. And run tests against a staging copy on identical hardware, never against production during business hours.

FAQ

How many PHP workers do I need?

Estimate peak uncached requests per second, multiply by average response time in seconds, and add 20 percent headroom. A store peaking at 30 uncached requests per second at 300 ms needs roughly 11 workers. If your host caps workers at 4 to 6 and you run WooCommerce at scale, the plan is undersized regardless of what the marketing page says.

Redis or Memcached in 2026?

Redis (or Valkey, its drop-in fork) for almost everyone. Better WordPress tooling, persistence, and cluster support. Memcached remains fine where a host provides it and the workload is a straightforward distributed cache.

Does a CDN help if most of my users are logged in?

Yes, but less. It still serves every image, script, and stylesheet, which is most of the bytes on a page. The HTML itself will bypass edge caching for logged-in users, so pair the CDN with a strong object cache and adequate PHP workers.

What should I check first on a site that is slow under load?

In order: page cache hit rate, autoloaded options size, presence of a persistent object cache, PHP version, and the slow query log. Those five checks find the main problem on most sites we audit.

When should I bring in help?

If you have applied the basics and still see 502s at peak, or you are planning a launch, migration, or campaign that will multiply your traffic, an audit beats guesswork. Our WordPress performance optimization service covers the full stack described here, from cache architecture to database tuning, with before and after benchmarks.

Final Thoughts

High-traffic WordPress is not one trick. It is a stack of layers that each stop requests earlier or make them cheaper: edge caching for the crowd, page caching for anonymous visitors, Redis for everyone else, tuned PHP and MySQL underneath, and load testing to prove the numbers before real traffic does. Start at the top of the stack, measure at every step, and treat logged-in traffic as the separate, harder problem it is.