WordPress
How to size hosting for WooCommerce
Size WooCommerce from concurrent dynamic actions, catalogue queries, imports and checkout reliability rather than page views alone.
By AppLaunch Editorial · Reviewed 2026-08-25
Direct answer
Cart, account and checkout requests are personalized and usually exercise PHP and the database. Measure concurrent shoppers, catalogue/filter complexity, background jobs and import peaks, then protect checkout correctness before optimizing anonymous cache throughput.
What this means in plain English
WooCommerce includes pages that cannot simply be shared from a public cache. Carts, accounts and checkout run PHP and database work for each shopper. Product filters, stock updates, payment calls and background jobs add more load.
Size from simultaneous shoppers and the heaviest real actions, not only monthly page views. Test a complete browse-to-checkout journey on staging with realistic products and plugins.
Which traffic cannot be served as a simple cached page?
| Dynamic concurrency | Simultaneous cart, account and checkout work |
|---|---|
| Database | Catalogue filters, orders and plugin queries |
| Background | Webhooks, mail, stock sync and scheduled actions |
A simple example
A shop gets many cached product-page visits without trouble but slows when 25 shoppers check out during a sale. The important capacity number is the concurrent dynamic checkout work, not the much larger total of simple page views.
What to do, step by step
1. Load-test a realistic browse-to-checkout journey in staging.
Start here before buying anything or changing several settings at once. It gives you a clear starting point based on dynamic concurrency: simultaneous cart, account and checkout work. Write the result down so you can compare it later.
2. Profile slow queries and external gateways.
Use the same files, versions and settings that the real project will use. A quick test with an empty or different setup can look successful while completely missing the problem you are trying to solve.
3. Exclude private routes from public cache.
Try the busiest realistic situation, not the easiest one. Include the people, data, traffic or background work you genuinely expect, then watch for slowdowns and errors rather than relying on a single headline number.
4. Verify backup and payment idempotency.
Finish by checking the result against background: webhooks, mail, stock sync and scheduled actions. Keep the old setting or release available until you know the change works and can be reversed safely.
One more useful tip
Run big imports and catalogue updates away from peak sales where possible. They can compete with customer queries and scheduled order work.
Common mistakes and how to avoid them
Sizing from monthly visits.
This gives a misleading or unsafe result because it leaves out dynamic concurrency. A better approach is to load-test a realistic browse-to-checkout journey in staging, then check the result before making the change permanent.
Caching carts across users.
This gives a misleading or unsafe result because it leaves out database. A better approach is to profile slow queries and external gateways, then check the result before making the change permanent.
Running massive imports during peak sales.
This gives a misleading or unsafe result because it leaves out background. A better approach is to exclude private routes from public cache, then check the result before making the change permanent.
Words explained
- plugin
- An add-on that gives WordPress extra features. Every plugin also adds code that must be updated and checked.
- cache
- A saved copy of work or a page that can be reused instead of generating it again.
- staging
- A private copy of a website used to test updates before changing the live site.
Quick checklist
- Load-test a realistic browse-to-checkout journey in staging.
- Profile slow queries and external gateways.
- Exclude private routes from public cache.
- Verify backup and payment idempotency.
Common questions
What is the simple answer?
Cart, account and checkout requests are personalized and usually exercise PHP and the database. Measure concurrent shoppers, catalogue/filter complexity, background jobs and import peaks, then protect checkout correctness before optimizing anonymous cache throughput.
What should I check first?
Start with dynamic concurrency: simultaneous cart, account and checkout work. That is usually more useful than choosing from a marketing label or copying somebody else’s setting.
How can I make the change safely?
Load-test a realistic browse-to-checkout journey in staging. Then change one thing at a time, keep a backup or old version, and use the same real-world test after each change.
What is the easiest mistake to avoid?
Sizing from monthly visits. Avoiding that one mistake makes the rest of the comparison much more trustworthy.