The homepage is the part of a store that everyone tests and almost nobody buys from. The catalog is cacheable, the product images can live at the edge, and a static page can survive a traffic spike on a small server. Checkout is different. It starts a session, validates a coupon, calculates shipping and tax, writes an order, and talks to a payment provider. It cannot be cached, and it is where the hosting bill is either justified or wasted.
This playbook separates the two workloads, sizes the stateful path, and maps order volume to a host model. It is written for a store owner or agency that already knows WooCommerce and needs the infrastructure decision to be explicit.
- Cache the catalog; bypass the cart. The page cache is for anonymous catalog and content, not checkout.
- Size workers for stateful traffic. Checkout holds a PHP worker for the whole request.
- Watch write latency. Order creation, Action Scheduler, and session writes are the database load that page tests miss.
- Test with a purge. A product import or deploy during peak is a capacity event.
- Buy headroom for the campaign, then scale down after the season.
The workload, in two halves
| Path | Cacheable? | Primary resource | Failure symptom |
|---|---|---|---|
| Homepage / catalog | Yes, anonymous | Edge cache, image delivery | Slow LCP, cache stampede |
| Product page | Yes, with variation care | Edge cache, object cache | Stale price or stock |
| Search / filters | Often uncacheable | Database read, PHP workers | Slow results, worker queue |
| Cart / add-to-cart | No | Sessions, Redis, PHP workers | Lost cart, 502 |
| Checkout | No | Workers, DB writes, gateway | Timeout, duplicate order |
| My account / subscriptions | No | Workers, DB, cron | Slow login, renewal backlog |
The practical consequence: a host benchmark that only measures cached pages tells you almost nothing about checkout. The WooCommerce load test exists because the revenue path needs its own percentile.
The architecture that keeps checkout alive
The edge protects the catalog. Workers and the database protect the checkout. They are separate capacity plans.
Keep the cache boundary explicit. A catalog page may be cached for anonymous visitors, but a logged-in customer with a cart must bypass it. Use cookie-based bypass for WordPress login and WooCommerce session cookies, and test the boundary with two browsers: one logged in, one private. If customer A's cart appears in customer B's window, stop and fix the rule before anything else.
Match the host model to order volume
| Volume | Typical model | Watch | Shortlist |
|---|---|---|---|
| Under 100 orders/day | Managed entry plan or a 4 GB cloud server | Checkout p95, restore time | Cloudways, Kinsta, Pressable |
| 100–1,000 orders/day | Managed production tier or 4–8 GB cloud server | Workers, DB writes, cache purge recovery | Rocket.net, Kinsta, WP Engine |
| 1,000+ orders/day | Managed enterprise tier or multi-server cloud | Peak concurrency, queue depth, gateway latency | Rocket.net, WP Engine, enterprise platforms |
| Campaign spikes | Any model with 1.5–2× headroom and a scale-up path | Worker ceiling, database connections, Redis memory | All; confirm the upgrade path |
Volume is a starting point, not a rule. A store with 200 orders a day and a heavy subscription renewal batch can need more capacity than a store with 2,000 simple orders. Model the workload, not just the order count.
Where the shortlist fits
Rocket.net is the performance pick: it recorded the lowest checkout p95 in our load test and includes an enterprise edge. It is a strong fit for a store where speed is a competitive advantage and the team wants the platform to own more of the stack. The trade-off is a narrower platform surface and less root-level control.
Kinsta is the managed hand-off: slightly slower than Rocket.net at the tail in our test, but with excellent support, staging, and restore workflows. Choose it when the team does not want to tune PHP-FPM or debug Redis at midnight.
Cloudways is the value/control pick: the lowest hosting cost in the cohort, but the operator owns updates, cache rules, and application incidents. It is a strong fit for an agency or a store with an in-house developer.
WP Engine is the institutional pick: a mature platform, broad agency relationships, and strong brand fit for procurement-sensitive clients. Its EverCache layer handles repeated anonymous traffic well; test the authenticated and cart paths against your own catalogue before committing.
The peak-season playbook
Peak readiness is a sequence, not a purchase. Start 30 days out, baseline the checkout, forecast concurrency, load-test the full journey, and buy capacity for 1.5–2× the forecast. Warm the cache after the final deploy, write the kill list, and rehearse the rollback. Freeze code a week before the sale.
On the day, watch checkout p95, error rate, worker utilization, database write latency, and payment-provider latency. If a threshold is crossed, disable the first non-essential feature on the kill list before adding infrastructure. A social feed is not worth a checkout queue.
A cache purge is a capacity event. A product import, price update, or plugin deploy can turn every catalog request into a PHP request. Schedule it outside peak, warm the cache afterward, and keep the origin below 70% utilization while it happens.
The commerce dashboard
- Checkout p95 and p99 — the primary service-level metric, measured end to end including the gateway.
- Checkout success rate — a host can be fast and still lose orders to a broken payment callback.
- PHP worker utilization and queue depth — saturation shows here before CPU.
- Database write latency — order creation and session writes.
- Redis hit ratio and evictions — a cold or undersized cache shifts load to MySQL.
- Cache hit ratio and purge frequency — a low ratio means the origin is doing work it should not.
- Payment-provider latency and error rate — outside the host's control, inside the customer's experience.
Five ways a good host still produces a bad store
- Caching checkout. A security incident disguised as a performance win.
- Buying visits instead of workers. The plan limit that matters is concurrency, not page views.
- Leaving a heavy plugin on every page. A recommendation widget can add more latency than the host saves.
- Never testing a restore. A backup that has not been restored is a hope, not a plan.
- Scaling up without scaling down. Campaign headroom becomes a permanent line item if nobody owns the follow-up.