VPS for WordPress/WooCommerce: Real Benchmarks & Setup Steps
Most WordPress sites hum on 2 vCPU / 4 GB NVMe. Busy blogs/light stores feel great on 4 vCPU / 8 GB with Redis and a tuned DB. Promo-heavy WooCommerce is safest at 8 vCPU / 16 GB (often with a separate DB). Aim for p95 <100–200 ms on cached pages and p95 <300–600 ms on key dynamic pages (cart/checkout). Start smaller only if your provider supports instant upgrades.
Quiet plug: Tremhost VPS ships NVMe storage, instant resize, snapshots, and optional panels—ideal for WP/Woo stacks without hassle.
Quick Sizing Matrix (Decide in 60 seconds)
Use case | Peak concurrent users | Baseline | Comfortable |
---|---|---|---|
Company site / blog (cached) | <20 | 1 vCPU / 2 GB | 2 vCPU / 4 GB |
WordPress w/ plugins | 20–60 | 2 vCPU / 4 GB | 4 vCPU / 8 GB |
WooCommerce (light) | 10–40 | 2 vCPU / 4 GB | 4 vCPU / 8 GB |
WooCommerce (promo/busy) | 60–150 | 4 vCPU / 8 GB | 8 vCPU / 16 GB |
Multi-site w/ control panel | mixed | 4 vCPU / 8 GB | 6–8 vCPU / 12–16 GB |
Panels add 1–2 GB baseline RAM; plan accordingly.
“Realistic results” targets (to sanity-check performance)
These are practical ranges on clean NVMe VPSs with the setup below. Treat them as targets, not absolutes—themes, plugins, and CDNs matter.
VPS size | Cached pages (req/s) | p95 cached | Woo dynamic (req/s) | p95 dynamic |
---|---|---|---|---|
2 vCPU / 4 GB | 500–900 | 120–200 ms | 30–60 | 500–800 ms |
4 vCPU / 8 GB | 800–1,200 | 90–160 ms | 60–100 | 350–650 ms |
8 vCPU / 16 GB | 1,100–1,800 | 70–140 ms | 90–120 | 300–500 ms |
Good TTFB goals: cached <100–200 ms in-region; dynamic <300–600 ms.
How to test (no scripts needed)
- Run two scenarios:
- Cached: homepage/blog listing with page cache warm.
- Dynamic: product → add-to-cart → cart → checkout (no full-page cache).
- Use simple tools: an online load tester (Loader.io, k6 Cloud, etc.), plus your host’s monitoring for CPU/RAM/disk and HTTP response times.
- What to watch: p95 latency, cache hit rate, CPU saturation (>70%), RAM (>85% with swap activity), and iowait (backup jobs or slow disks).
If numbers are far off: your cache isn’t hitting, DB is slow (missing indexes/autoload bloat), or PHP workers are saturated.
30-Minute Setup That Actually Performs
Core stack (fast + stable):
- Web server + cache: LiteSpeed/LSCache (or NGINX FastCGI cache)
- PHP: 8.2/8.3 with opcache on
- Object cache: Redis for sessions and queries
- DB: MariaDB 10.6+ or MySQL 8, tuned buffer pool
- Transport: HTTP/3 + TLS 1.3
- Storage: NVMe SSD (non-negotiable)
Key switches to flip:
- Full-page cache for all public pages.
- Exclude from cache:
/cart/
,/checkout/
,/my-account/
. - Enable Redis object cache; keep it off the default DB.
- Size the database buffer pool to ~30–50% of RAM (start conservative).
- Replace WP pseudo-cron with a real cron (every 2–5 min).
- Daily backups + weeklies; perform a test restore (file + DB table).
- Security basics: AutoSSL, current WAF rules, rate-limit
/wp-login.php
, restrict/xmlrpc.php
, 2FA for admins.
Tuning That Moves the Needle (and nothing else)
- Caching first: page cache + Redis object cache.
- Trim plugins that run on every request or hammer the DB.
- Images: serve WebP, preload key fonts, lazy-load correctly.
- Email: use a transactional SMTP API for orders/notifications.
- Backups: run off-peak; keep 20–30% free disk for snapshots and logs.
Upgrade vs Split: Clear Rules
Upgrade the VPS when (during peak) two or more are true:
- CPU > 70% sustained or host “steal” time > 5–10%
- RAM > 85% with noticeable swap use
- p95 latency keeps rising despite good cache hit rate
Split roles (web vs DB) when:
- DB slow queries dominate even with spare web CPU
- Imports/reports impact front-end latency
- You need separate maintenance windows
Common path: 4 vCPU / 8 GB → 8 vCPU / 16 GB → separate DB (4 vCPU / 8 GB).
Troubleshooting quick map
- Cached pages slow → cache headers wrong, cookie variance, CDN overrides.
- Woo checkout slow → missing indexes, overloaded options table, heavy payment/webhook plugins.
- High iowait → NVMe missing or backups colliding with traffic; reschedule jobs.
- PHP pegged → too few workers or slow code; modestly raise workers or add vCPU after profiling.
What to promise clients (agency copy you can reuse)
- “LiteSpeed + NVMe + Redis for real-world speed.”
- “Daily backups + on-demand restore, tested monthly.”
- “SPF/DKIM/DMARC set up for better inbox reach.”
- “WooCommerce cut through checkout under load—cart/checkout never cached.”
Hosting multiple sites? Tremhost VPS pairs nicely with Reseller Hosting for white-label, billing, and migrations.
FAQs (People Also Ask)
Is 2 vCPU / 4 GB enough for Woo?
For light stores, yes—if caching and Redis are in place. Promo bursts or complex plugins do better on 4 vCPU / 8 GB.
LiteSpeed or NGINX?
Both are excellent. LiteSpeed + LSCache is turnkey for WordPress; NGINX FastCGI cache is great if you prefer manual control.
Do I need Redis?
For WooCommerce and plugin-heavy sites, yes. It cuts database trips and stabilizes p95 latency.
How often should I test restores?
Monthly. If you haven’t restored, you don’t have a backup—you have files.
Need a VPS that hits these targets and scales in seconds? Tremhost VPS offers NVMe, instant resize, snapshots, and 24/7 support. If you host clients, pair it with Reseller Hosting to add white-label, billing, and zero-drama migrations