Website Server Sizing: CPU, RAM, and Storage Budgets by Monthly Traffic in 2026

Sizing a web server is the difference between a site that survives a traffic spike and one that falls over at the worst moment. Most buying guides lead with brand names and marketing claims; this one walks through the numbers that actually matter, tier by tier, so you can match CPU, RAM, storage, and bandwidth to your real monthly traffic.

Start With a Traffic Tier, Not a Spec Sheet

Hardware requirements scale with concurrent users and request patterns, not with page count. A WooCommerce store with 5,000 monthly visits needs a fraction of the resources of a media site with the same traffic but heavy image and video delivery. The table below is a practical starting point for typical WordPress and CMS workloads in 2026, assuming a properly cached stack.

Monthly visits	Peak concurrency	CPU	RAM	Storage	Bandwidth
Up to 10,000	~50	4 cores	16 GB	500 GB NVMe	1 Gbps unmetered
10k–50,000	~150	6–8 cores	32 GB	1 TB NVMe	1 Gbps unmetered
50k–150,000	~400	8–12 cores	64 GB	1–2 TB NVMe	1–10 Gbps
150k–500,000	~1,000+	16+ cores	128 GB	2–4 TB NVMe	10 Gbps

These figures assume full-page caching (Redis or Varnish), a CDN in front of static assets, and a database that is not running on the same disk as the web root. If any of those three assumptions is missing, move up one tier. If you run WooCommerce with frequent sales events, add 25–50% to the RAM figure — checkout sessions and the object cache are the first things to exhaust memory during a discount campaign.

CPU: Cores Handle Concurrency, Clock Speed Handles Latency

Two rules cover most decisions. First, PHP and database queries are mostly single-threaded, so per-core performance matters more than core count for a typical site. Second, the number of concurrent requests is what pushes core utilization up. A 6-core processor with high single-thread performance will serve a 50,000-visit/month site comfortably; a 16-core chip with weak single-core speed will still feel sluggish on uncached requests. When comparing plans, check the PassMark single-thread score of the actual CPU model, not the marketing name.

A useful way to think about it: every PHP-FPM worker is a process waiting on CPU time, and each worker handles one request at a time. If your peak concurrency is 150 and each request takes 200 ms of CPU work, you need roughly 30 workers running at any moment. Multiply that by the fact that each worker consumes a full core while active, and you can see why a 4-core box struggles at 150 concurrent uncached requests even when the dashboard says CPU is only 60% utilized — queueing is already happening.

RAM: Budget for the Three Consumers

On a typical LAMP/LEMP stack, memory is consumed by three things: the web server and PHP-FPM pools, the database cache, and the object cache. A useful heuristic is 512 MB to 1 GB of PHP-FPM memory per 10 concurrent uncached requests, plus 2–4 GB for MySQL/MariaDB buffer pools, plus 1–2 GB for Redis. That is why 32 GB is the realistic floor for any site doing meaningful business in 2026 — 16 GB works only for low-traffic brochure sites with aggressive caching.

OOM (out-of-memory) kills are the most common silent cause of downtime on under-sized servers. When Linux runs out of RAM it starts killing processes, and the OOM killer frequently targets the database or the web server first because they hold the most pages. If you see “killed process” entries in dmesg after an incident, the fix is usually more RAM or a stricter cache eviction policy — not a faster CPU.

Storage: NVMe and the 20% Headroom Rule

Disk I/O shows up in database query times, backup windows, and admin panel responsiveness. NVMe drives deliver 5–10x the random I/O of SATA SSDs, which is exactly what database workloads need. Whatever tier you pick, add 20% headroom on top of your current usage for logs, staging copies, and database growth — and never let backups share the same physical drive as production data. If you are comparing configurations across providers, review web server hardware options side by side before committing.

Bandwidth: Estimate From Page Weight, Not Pageviews

A quick calculation: average page weight in MB × average pageviews per month gives a baseline transfer figure. A 2 MB page served 50,000 times is 100 GB/month before you add backups, bot traffic, and API calls. Unmetered 1 Gbps connections are standard on quality plans and remove the guesswork; metered plans at 5–10 TB will generate overage bills quickly if you host video or large files. Read the fair-use policy before signing.

Two traffic sources are almost always underestimated: search engine crawlers and security scanners. A popular site can receive 10–20% of its total transfer from bots, and a single aggressive scraper can burn through gigabytes in an afternoon. Budget for bot traffic, rate-limit aggressively, and check your provider’s policy on abuse-triggered throttling before you need it.

Managed or Unmanaged: Match It to Your Team

Unmanaged plans cost $30–$80/month less but put patching, monitoring, and incident response on your shoulders. Managed plans add a predictable fee and include proactive maintenance, which is worth it when a single hour of downtime costs more than the monthly management charge. If you have no one on the team who can recover a broken boot volume from rescue mode, buy managed.

A Five-Point Pre-Purchase Checklist

• Verify the CPU model — ask for the exact processor and check its single-thread benchmark.
• Confirm the storage tier — NVMe in writing, not just “SSD”.
• Check the RAM upgrade path — can you add memory without re-provisioning?
• Read the bandwidth policy — unmetered vs. metered, and what happens on overage.
• Test support before buying — send a pre-sales question at 3 a.m. and measure the response.

Size to your traffic tier, verify the hardware in writing, and keep caching, CDN, and backups in place from day one. Do that and the server becomes infrastructure you stop thinking about — which is exactly what it should be.