A WordPress brochure site is a page-caching problem. Nearly every visitor is anonymous, nearly every response is identical, and a full-page cache (Varnish, NGINX FastCGI cache, or the host’s edge layer) can absorb most traffic before PHP ever runs. A modest origin server behind a good cache serves heavy traffic because the origin rarely works.

WooCommerce breaks that model at exactly the moments that earn money. A visitor with items in the cart carries a session. Cart, checkout, and account pages are personalized per visitor, so they bypass the page cache and execute PHP plus MySQL on every request. The practical consequence: a store’s capacity is set by how much uncached traffic the origin can handle concurrently, not by how well the cache performs. Sizing a store on brochure-site assumptions is the most common mistake we find in environments we take over, and it stays invisible until a promotion or a busy season pushes concurrent checkouts past what the origin can execute.

Two PHP decisions matter, and the version is the easy one. WooCommerce and WordPress core both support modern PHP 8 releases, and each major PHP 8 version has brought measurable execution-speed gains over its predecessor, so we provision the newest PHP 8 release the site’s plugin set passes testing on. The constraint is rarely core; it is usually one aging payment or shipping plugin, which is worth flagging to the client as a risk in its own right.

Worker count is the decision that actually sets capacity. Under PHP-FPM, each uncached request occupies one worker for its full execution time. A checkout submission can hold a worker for several seconds while it validates the cart, talks to the payment gateway over an external API call, writes the order, and fires confirmation email. When all workers are busy, new requests queue, and queued checkouts are where stores lose orders. The sizing logic is arithmetic: estimate peak concurrent uncached requests, multiply by typical execution time, and provision workers plus the RAM to back them (each worker holds its own memory footprint, commonly in the low hundreds of megabytes on a plugin-heavy store). Hosts that advertise “unlimited traffic” while capping PHP workers at a single-digit number are advertising brochure-site capacity.

A brochure site’s database stops growing when the content stops. A store’s database grows with every order, and the growth lands in awkward places. In WooCommerce’s legacy storage, orders lived in wp_posts with their details spread across wp_postmeta, a key-value table that gains many rows per order and is expensive to query at scale because it indexes poorly for that access pattern. High-Performance Order Storage (HPOS), now the default for new installations, moves orders into dedicated, properly indexed tables and is worth enabling on any store whose plugin set is compatible; on older stores, the postmeta growth curve is often the quiet reason the admin gets slower every quarter.

Provisioning follows from that: enough InnoDB buffer pool to hold the working set (products, active orders, sessions) in memory, and attention to the tables plugins create. Session rows, action scheduler logs, and abandoned-cart records all accumulate, and a store that has never had its database reviewed typically carries tables that a scheduled cleanup would shrink substantially. We treat a database review as part of onboarding, not an incident response.

WordPress asks the database for the same options, term, and meta lookups on nearly every request. A persistent object cache backed by Redis holds those results in memory across requests, which cuts repeated query load dramatically on exactly the traffic a store cannot page-cache: carts, checkouts, and logged-in accounts. On uncached-heavy workloads it is the single most effective addition to the stack, and we consider it standard on any store, not an upgrade.

Its limits are just as important to state plainly. Redis does not make slow PHP fast: a plugin that runs an expensive loop still runs it. It does not cache page output, so it does not reduce worker occupancy the way a page cache does; it shortens each request rather than eliminating it. And a misconfigured object cache (undersized memory limit, stale drop-in file after a migration) can serve outdated data in ways that surface as baffling cart bugs. When an MSP hands us a “Redis made it worse” ticket, the drop-in file and the eviction policy are where we look first.

Three WooCommerce behaviors generate load that a spec based on pageviews misses. Cart fragments: the widget that shows cart contents in the header updates through an AJAX call that bypasses every cache layer, and in default configurations it can fire on ordinary page loads, converting cacheable traffic into PHP executions. It can be constrained or disabled, and on high-traffic stores it usually should be.

Webhooks: a store wired to an ERP, a fulfillment service, or an email platform fires outbound HTTP requests on order events. Under load, those deliveries occupy workers and can back up the Action Scheduler queue, which also runs subscription renewals and stock syncs. The scheduler deserves monitoring on any integrated store, because its failures are silent until a client asks why renewals stopped.

Payment gateway round-trips: every checkout blocks on an external API. When a gateway has a slow day, checkout execution time stretches, worker occupancy climbs, and a server that was fine at nine in the morning queues at noon. Headroom in the worker budget is what absorbs a third party’s bad day.

Treat these as working starting points, not guarantees; catalog size, plugin weight, and traffic shape move every number.

• Small store (a few hundred orders a month): 2 CPU cores, 4 GB RAM, current PHP 8, MariaDB or MySQL 8 with a right-sized buffer pool, Redis object cache, page cache for anonymous traffic, roughly 10 to 15 PHP workers.
• Mid-size store (steady daily orders, marketing-driven spikes): 4 cores, 8 to 16 GB RAM, 20 to 40 workers, Redis with a dedicated memory allocation, HPOS enabled, Action Scheduler and gateway latency under monitoring.
• Heavy store (large catalog, integrations, promotions): separated database server or managed MySQL, autoscaling or generously overprovisioned worker pools, and load testing of the checkout path before each major sale, because at this size the bottleneck is found by measurement rather than predicted by spec.

The revisit triggers are observable: sustained worker saturation, buffer pool misses climbing, checkout p95 latency stretching, or a promotion calendar that outgrows last year’s peak. We review specs against those signals on a schedule rather than waiting for a slowdown ticket.

MSPs: Boston Web Group shares this hosting spec in full and handles the WooCommerce layer under a non-solicitation agreement, so your client relationship stays yours. If you run stores on different numbers, compare notes with us; the spec gets better every time it survives contact with someone else’s production traffic.