How Much CPU, RAM and Bandwidth Does a New Website Need?

Why Sizing CPU, RAM and Bandwidth by Monthly Visitors Matters

When you launch a new website, one of the first practical questions is very simple: how much CPU, RAM and bandwidth do I really need? Order too small and you risk slow pages, errors and frustrated visitors. Order too big and you waste budget on idle resources. At dchost.com, we spend a lot of time helping customers find the sweet spot between stability, speed and cost, especially in the first 6–12 months of a project.

In this guide, we’ll walk through a realistic way to size your hosting based on monthly visitors and a few other factors: what kind of website you’re running (blog, corporate site, WooCommerce shop, SaaS app), how heavy your pages are, and how much caching you use. We’ll translate that into practical recommendations for CPU cores, RAM and monthly bandwidth, and show you when it’s time to move from shared hosting to VPS, or from VPS to a dedicated server or even colocation.

Everything here is written from the perspective of how we actually plan capacity with customers at dchost.com, not theory. Use it as a checklist when you’re choosing a shared hosting plan, a VPS, a dedicated server or a growth path for a project that’s just starting to attract real traffic.

The Three Resources That Actually Matter: CPU, RAM and Bandwidth

Hosting plans expose lots of limits and metrics, but for sizing a new website you mainly care about three server-side resources:

CPU (vCPU / cores)

The CPU handles every dynamic operation: PHP execution for WordPress and Laravel, Node.js requests, database queries, image resizing, API calls and more. In shared hosting you usually see CPU described as a percentage of a core or as a limit inside cPanel. On VPS and dedicated servers you’ll see vCPUs or physical cores.

More CPU helps with:

• Handling more simultaneous visitors
• Reducing response time for dynamic pages
• Absorbing short traffic spikes (campaigns, social media hits)

But throwing CPU at a badly written or uncached application won’t magically fix it. A small site with solid caching can often serve tens of thousands of visitors on modest CPU.

RAM (Memory)

RAM is where your web server, PHP engine, database and caching layer keep frequently used data in memory. When RAM is too low, your server starts swapping to disk, which is drastically slower and can make the whole site feel stuck.

More RAM helps with:

• Keeping database caches in memory (query cache, buffer pools)
• Running PHP-FPM, Node.js, background workers and cron jobs simultaneously
• Running in-memory caches like Redis or Memcached

For simple brochure sites or small blogs, CPU limits usually show up before RAM limits. For e‑commerce, SaaS or database-heavy apps, RAM becomes critical much sooner.

Bandwidth (Traffic / Data Transfer)

Bandwidth (or monthly traffic) is the total data transferred between your server and visitors: HTML, CSS, JavaScript, images, video, downloads and APIs. Hosting plans usually show this as GB per month.

Bandwidth is driven by:

• Number of visitors
• Pages viewed per visitor
• Average page weight (in MB)
• How much you offload to a CDN (if any)

Underestimating bandwidth leads to surprise overage fees or throttling. Overestimating it slightly is cheap insurance, especially for media-heavy sites. If you want to dig deeper into how traffic and storage impact your bill, our guide on cutting hosting costs by right‑sizing VPS, bandwidth and storage walks through the cost side in more detail.

What Actually Changes Your Resource Needs?

Two websites with the same monthly visitors can require very different hardware. Before we size by visitor counts, we need to understand the main factors that change the picture.

1. Type of Website

• Static or mostly static sites (landing pages, documentation, some corporate sites): Very light on CPU and RAM if properly cached. Bandwidth is the primary concern.
• Blogs and content sites (WordPress, etc.): Moderate CPU and RAM needs, especially during publishing or when using heavy page builders. Caching can reduce load dramatically.
• E‑commerce (WooCommerce, Magento, custom shops): Heavier CPU and RAM usage due to cart logic, checkout, search and logged‑in users. Needs more conservative sizing and better storage/IO.
• Web apps and APIs (SaaS, dashboards, internal tools): Highly variable. CPU and RAM depend on logic complexity, background jobs and database usage.

If you’re specifically planning a WooCommerce store, our WooCommerce capacity planning guide goes much deeper into CPU, RAM and storage IOPS calculations.

2. Technology Stack and Caching

The same visitor count can be easy or heavy on a server depending on your stack and whether you cache effectively:

• Cached WordPress or Laravel (full-page caching, object cache) can often serve 5–10x more users on the same hardware than an uncached setup.
• Node.js, Django, Rails, etc. can be very efficient if you tune worker counts and use HTTP-level caching plus a CDN.
• Database-heavy pages (search, filters, personalized dashboards) consume more CPU and RAM per request.

If you’re curious how much difference server‑side tuning makes, our article on Core Web Vitals and hosting shows how better CPU, RAM and caching translate directly into TTFB and LCP improvements.

3. Media and Page Weight

A lightweight landing page might be 0.5–1 MB. A modern home page with big hero images, fonts and JavaScript bundles can easily reach 2–4 MB. Video, large images and file downloads push this further.

As a quick rule of thumb for initial planning:

• Simple text pages: 0.5–1 MB per page view
• Typical marketing/WordPress pages: 1–2 MB per page view
• Image/video‑heavy pages: 3–5+ MB per page view

Optimising images (WebP/AVIF) and static assets can cut your bandwidth in half or more. Our guide on serving WebP/AVIF without breaking your site or SEO is a practical starting point if you want to reduce both bandwidth and load times.

4. Logged‑In Users, Bots and Background Jobs

Three factors often underestimated in capacity planning:

• Logged‑in traffic: Dashboards, checkout and account pages bypass many caching layers and hit the application + database more heavily.
• Bots and crawlers: Search engines, uptime monitors and scraping bots can easily double your effective request count if not managed with rate limiting and sensible robots.txt.
• Cron jobs and queues: Scheduled tasks (backups, imports, report generation) consume CPU and RAM alongside normal visitor traffic.

Estimating Bandwidth by Monthly Visitors

Let’s start with bandwidth, because it’s the easiest to estimate numerically from monthly visitors.

Here’s a simple formula you can plug into a spreadsheet or even a calculator:

• Total Pageviews per Month = Monthly Visitors × Pages per Visit
• Total Data (MB) = Total Pageviews × Average Page Size (MB)
• Bandwidth (GB/month) = Total Data (MB) ÷ 1024

Now let’s apply this to some common scenarios for a typical WordPress or marketing site.

These numbers include some headroom. If you heavily use a CDN and optimise images, actual usage might be 30–50% lower. If you host downloads or video directly, it can be much higher.

Practical rule: For a new site, choose a plan where your expected bandwidth is at most 50–60% of the limit. That leaves space for growth and occasional traffic peaks without stressing about overages.

CPU and RAM Sizing by Monthly Visitors

Unlike bandwidth, CPU and RAM don’t scale linearly with visitors. Caching, application code and peak concurrency all play a role. Still, we can give sane starting points for typical modern setups (WordPress, small Laravel apps, basic Node.js sites) and explain when to move up.

Below, we assume:

• HTTP caching (plugin or reverse proxy) enabled for public pages
• A reasonably optimised theme and limited heavy plugins
• No extreme background jobs or reporting tasks

If you know your stack will be heavier (complex WooCommerce, large Magento, analytics‑heavy SaaS), treat these as minimums and be more conservative.

Up to 5,000 Monthly Visitors

This is typical for very new projects, personal sites, small blogs and simple corporate pages.

• Recommended hosting: Quality shared hosting or entry‑level VPS
• CPU: Equivalent of 1 vCPU (shared) or 1 vCPU on a small VPS
• RAM: 512 MB–1 GB (VPS) or typical shared hosting limits
• Bandwidth: Plan for 5–20 GB/month depending on page weight

On a good shared hosting platform with LiteSpeed or Nginx and caching, a simple WordPress site at this scale will rarely hit resource limits. If you start seeing “Resource Limit Reached” errors in cPanel, it’s worth reading our guide on understanding cPanel resource limits to see whether you need optimisation or a small upgrade.

5,000–20,000 Monthly Visitors

At this level, your site is starting to get real usage: consistent blog traffic, a small online catalog or a local business website with some marketing campaigns.

• Recommended hosting: Higher‑tier shared hosting or small VPS
• CPU: 1–2 vCPU
• RAM: 1–2 GB
• Bandwidth: Plan for 20–80 GB/month

For WordPress:

• With a caching plugin and optimised images, 1 vCPU / 1 GB RAM can easily handle 20k visitors/month.
• If you run WooCommerce or many logged‑in users, start with 2 vCPU / 2 GB RAM to keep checkout and account pages smooth.

A VPS becomes attractive here if you need custom server‑side settings (PHP limits, background workers, specific libraries) or want more predictable performance than on shared hosting. Our article on choosing the best hosting for WordPress (shared vs managed vs VPS) can help you decide which route fits your project.

20,000–100,000 Monthly Visitors

This is where you move beyond “small project” territory. You’re likely running regular campaigns, SEO is working, or you have a growing content or e‑commerce site.

• Recommended hosting: VPS with dedicated resources or entry‑level dedicated server (for heavier apps)
• CPU: 2–4 vCPU
• RAM: 4–8 GB
• Bandwidth: Plan for 100–500 GB/month depending on media

For typical setups:

• Cached WordPress blog or corporate site: 2 vCPU / 4 GB RAM is usually plenty up to ~100k visitors/month.
• WooCommerce shop: 4 vCPU / 8 GB RAM is a safer baseline at this traffic level, especially if you offer filters, search and logged‑in accounts.
• Laravel/Node.js apps: 2–4 vCPU and 4–8 GB RAM depending on how database‑heavy your logic is and how many background workers you run.

This is also where disk performance (IOPS) starts to matter, not just CPU/RAM. For busy databases, consider NVMe‑backed VPS or dedicated servers to avoid slow queries during peak load. We cover this trade‑off in more detail in our NVMe VPS hosting guide.

100,000–500,000 Monthly Visitors

At this point, you’re running a serious property: high‑traffic content site, popular e‑commerce store, or a SaaS app with regular usage. You need predictable performance and room to handle peaks.

• Recommended hosting: Larger VPS, high‑end VPS cluster, or mid‑range dedicated server
• CPU: 4–8 vCPU (or 4–8 physical cores on a dedicated server)
• RAM: 8–16 GB
• Bandwidth: Plan for 500 GB–2 TB/month (and consider a CDN)

Notes:

• Separation of roles: You may benefit from separating the database to its own server for better performance and isolation, especially for WooCommerce and SaaS. Our guide on when to separate database and application servers explains when this becomes worthwhile.
• High cache hit ratio is critical: At this scale, every 1% of extra cache hit rate saves CPU.
• Monitoring and alerting: You should actively monitor CPU, RAM, disk IO and response times; don’t fly blind.

500,000+ Monthly Visitors

Above half a million monthly visitors, individual hardware specs matter less than architecture and scaling strategy. You should be thinking in terms of multiple servers, load balancing, dedicated databases and edge caching.

• Recommended hosting: High‑end dedicated servers, clusters of VPS, or your own hardware in colocation
• CPU: 8–16+ cores across one or more nodes
• RAM: 16–64+ GB depending on database size and caching strategy
• Bandwidth: 2 TB/month and up, usually with a CDN in front

At this level, CPU and RAM planning needs to consider:

• How many concurrent users you expect during true peaks
• How much work each request does (database queries, remote API calls)
• How you handle sudden spikes from campaigns or social media

If you’re operating at this scale, it’s often worth having a structured scaling plan. Our hosting scaling checklist for traffic spikes and big campaigns walks through the playbook we use when customers prepare for big events.

Special Cases: E‑Commerce, Web Apps and APIs

So far we’ve been speaking in generalities. Some workloads consistently need more CPU and RAM than a basic content site for the same number of visitors.

E‑Commerce (WooCommerce, Magento and Similar)

E‑commerce traffic is more expensive in server terms because:

• Most important traffic is logged‑in (cart, checkout, account)
• Pages are more dynamic (stock, pricing, personalised recommendations)
• Checkout can’t be aggressively cached

As a rough multiplier, plan 1.5–2× the CPU and RAM compared to a similar‑traffic content site. For example:

• 20–50k visitors/month shop: 4 vCPU / 8 GB RAM baseline
• 50–150k visitors/month shop: 6–8 vCPU / 16 GB RAM, plus fast storage

We’ve written a full breakdown in our article best hosting for Magento: CPU, RAM, NVMe and Redis requirements step‑by‑step, and the logic largely applies to other heavy e‑commerce platforms as well.

SaaS, Dashboards and Internal Tools

Web apps and APIs are tricky because “visitors” may not be the right metric; concurrent sessions and request rate matter more. As a starting point:

• Small SaaS with a few hundred daily active users: 2–4 vCPU, 4–8 GB RAM
• Medium SaaS with thousands of daily active users: 4–8 vCPU, 8–16 GB RAM plus a separate database node

Background jobs (queues, scheduled tasks, report generation) can consume as much CPU as your main app. Plan a margin of at least 30–40% free CPU at normal load so those jobs don’t slow down the user experience.

API‑Heavy and Mobile Backends

API backends that serve mobile apps often see short, bursty traffic and relatively small responses. Here, CPU and database performance are usually more important than raw bandwidth. If you expect many concurrent requests, size CPU according to peak RPS (requests per second) and response complexity, not just monthly visitor counts.

Monitoring, Tuning and Knowing When to Upgrade (or Downgrade)

All sizing rules are approximations. The safest way to avoid both overpaying and under‑provisioning is to start with a sensible baseline and watch real metrics for a few weeks.

Key Metrics to Watch

• Average and peak CPU usage: Try to keep average under 60–70% and peaks under 90% during normal busy periods.
• RAM usage: Aim to have at least 20–30% free RAM in normal conditions. If you hit swap regularly, upgrade RAM or optimise.
• Disk IO and IOwait: High IOwait suggests your storage is slowing down queries, especially on busy databases.
• Response times (TTFB, LCP): If pages are slow despite low CPU/RAM, you may need application‑level optimisation, not just bigger hardware.

On a VPS or dedicated server, tools like Prometheus + Grafana or even lighter monitoring solutions can give you a clear picture. Our guide on VPS monitoring and alerts shows a practical setup we often deploy.

When to Upgrade

Consider upgrading your plan or server when you see some of these patterns:

• Sustained CPU usage above 70% during business hours
• Frequent memory pressure or swapping
• cPanel resource limit warnings on shared hosting
• Page response times degrading during traffic peaks
• New features planned (e‑commerce, user accounts, search) that will clearly add load

Equally important, don’t be afraid to downgrade if you realise you massively over‑estimated. Right‑sizing a VPS or dedicated server can save meaningful budget that you can redirect to content, marketing or development. Our article on choosing VPS specs for WooCommerce, Laravel and Node.js shares how we approach this in real projects.

How dchost.com Helps You Size and Grow Safely

At dchost.com, we operate across the whole spectrum: domains, shared hosting, VPS, dedicated servers and colocation. That means we see the entire lifecycle of projects—from the first prototype on a tiny shared plan, to multi‑server stacks running high‑traffic e‑commerce and SaaS.

Our general approach is conservative but cost‑aware:

• Start with the smallest plan that comfortably fits your current traffic and realistic near‑term growth.
• Make sure caching, compression and basic optimisation are in place from day one.
• Set up monitoring and alerts early so scaling decisions are driven by data.
• Have a clear upgrade path: from shared hosting to VPS, to dedicated, to colocation if and when it makes sense.

If you expect rapid growth, we can also help you plan from the start for smooth scaling: separating database and application layers, preparing for Anycast DNS, or designing a multi‑server architecture so you can add capacity without downtime. Our blog post on real‑world comparison of web hosting types is a good companion read if you’re still figuring out which platform to build on.

Bringing It All Together

Figuring out how much CPU, RAM and bandwidth a new website needs doesn’t have to be guesswork. Start from a few concrete inputs—monthly visitors, pages per visit, average page size and application type—and you can quickly narrow down a safe starting range:

• Up to ~20k visitors/month: good shared hosting or a small VPS often suffices.
• 20k–100k visitors/month: move to a solid VPS with 2–4 vCPU and 4–8 GB RAM.
• 100k+ visitors/month: think in terms of dedicated resources, NVMe storage and possibly multiple servers.

Layer on top whether your traffic is mostly anonymous or logged‑in, whether you run e‑commerce or complex web apps, and how well you implement caching. Then validate your assumptions by watching real metrics in the first weeks after launch, adjusting up or down rather than locking yourself into an oversized setup from day one.

If you’d like help translating your specific traffic expectations into a concrete hosting plan, the team at dchost.com does this every day. Share your current visitor numbers, tech stack and growth plans, and we’ll suggest a CPU, RAM and bandwidth profile with a clear path to scale—whether that’s staying on shared hosting, moving to a VPS, or planning ahead for a dedicated server or colocation as your project grows.