Quick answer
Choose vCPU from the work the server performs at the busiest moment, not from a vague site-count or traffic figure. One vCPU can be enough for a light, single-purpose project. Two vCPU is a more comfortable starting point for many WordPress, small application and development workloads. Four or more vCPU becomes relevant when the server handles CPU-heavy page generation, background workers, busy WooCommerce or membership tasks, software builds, APIs, or several genuinely active services. Check CPU, RAM and storage behaviour together before resizing.
What a vCPU actually represents
A vCPU is a virtual processor presented to a virtual server. It is not a promise that the number printed on a plan is identical to a physical CPU core, and it is not enough on its own to predict website speed. The result depends on the virtualisation platform, the resource policy, the operating system, the applications you run, the database behaviour and what happens at busy times.
For planning, think of vCPU as the amount of concurrent compute work your server can handle before CPU becomes the bottleneck. A PHP request that builds a dynamic WordPress page needs CPU. So does a database query, image-processing task, cache rebuild, backup compression, cron job, queue worker, Node.js process, Python task or software build. When several of those tasks happen together, a one-vCPU server must queue more work than a server with more available compute capacity.
That does not mean every project should start large. An idle website does not gain a visible benefit from extra CPU just because the plan has a bigger number. The useful aim is enough vCPU for normal activity, a sensible amount of headroom for short bursts, and a straightforward upgrade route once monitoring says the workload has changed.
Practical starting points for VPS vCPU
The examples below are starting points, not guarantees. They assume a Linux server that you or your developer can administer, with sensible caching, updates and monitoring. A badly configured plugin, a slow database query or a backup task can make a large server feel slow; a carefully configured static or cached site can run comfortably with far less.
| Starting point | Usually reasonable for | Watch for |
|---|---|---|
| 1 vCPU | A single low-traffic website, a small static site with a simple application, a lightweight test server or a narrowly scoped service. | Long-running tasks, simultaneous admin activity, uncached dynamic pages, CPU spikes during cron jobs and any database workload that has little headroom. |
| 2 vCPU | Many small WordPress sites, a typical business site with background tasks, a modest application, a small API, or a development/staging server. | Plugins that generate pages dynamically, WooCommerce requests, multiple workers, cache misses, traffic bursts and backups run at the same time as visitors arrive. |
| 4 vCPU | Busier WordPress or WooCommerce workloads, membership sites, multiple active applications, API/worker combinations, developer environments and custom stacks with regular concurrent work. | Whether RAM and database tuning are now the real limitation. More CPU does not solve swapping or slow storage. |
| 6+ vCPU | CPU-bound processing, frequent builds, several sustained workers, heavier application traffic, data work or a server that has already shown a stable CPU bottleneck under real load. | Whether dedicated CPU resources, a VDS, service separation or application optimisation is the next sensible step. |
For a WordPress project, start by separating the visitor-facing work from the maintenance work. A cached page view can be light. Editing a page, running a plugin update, processing images, sending a batch of email, rebuilding a search index and running WooCommerce scheduled tasks can be much heavier. A configuration that looks fine on a quiet day can become uncomfortable when several of those jobs overlap.
For an application or API, ask how many processes run continuously. A web server, application runtime, database, queue worker, scheduler, cache and monitoring agent all compete for the same server resources. A service that has one small process and occasional requests is very different from one that handles persistent workers or multiple background jobs.
Workloads that genuinely benefit from more vCPU
The strongest case for more vCPU is repeatable CPU pressure, not a single slow page seen once. Look for a pattern: traffic arrives, the server load rises, response times become worse, queues grow, workers fall behind or scheduled tasks clash with visitor activity. Once that pattern is clear, additional CPU may help. These are common examples.
Dynamic WordPress and WooCommerce
Cart, checkout, account, search, stock updates and uncached pages create more server work than a cached marketing page. A busy store may need more CPU, but database queries, plugins and object caching must be checked too.
Workers, queues and scheduled jobs
Queue workers, cron jobs, imports, report generation, feeds, webhooks and scheduled backups can run at the same time as normal traffic. That overlap is often the real cause of a CPU upgrade.
Developer and build workloads
Compiling code, running test suites, building front-end assets, processing containers and running multiple local services are CPU-heavy in a way that simple website hosting is not.
Image, video and data processing
Image transformations, document conversion, analytics jobs and data imports can consume CPU for long periods. Consider whether these tasks should run off-peak, on a separate worker or on a separate server.
Do you need more CPU or more RAM?
CPU and RAM problems often look similar from the outside: pages are slow, a task fails or the server becomes unresponsive. They need different remedies. More vCPU helps when the server has ready work waiting for compute time. More RAM helps when applications cannot keep useful data in memory, when the operating system starts swapping to disk, or when processes are killed because memory has run out.
Before changing a plan, inspect what is actually happening. In Linux, top or htop can show which process is consuming CPU and memory. Load average is useful only when read alongside CPU count and process state. Check database activity, PHP-FPM workers, application logs and the timing of scheduled jobs. A high load average caused by disk waits or memory pressure will not necessarily improve because you add CPU.
A simple decision rule
- CPU upgrade: CPU is consistently saturated during normal peak activity, and the busy processes are doing useful compute work.
- RAM upgrade: swap grows, out-of-memory events occur, database/application memory use is constrained, or caches cannot remain resident.
- Storage or query fix: the server is waiting on disk or repeatedly running inefficient database work.
- Architecture change: one server is mixing too many jobs that should be separated, such as web traffic, backup compression and long-running workers.
How to measure vCPU needs before you resize
Do not judge the requirement from a single synthetic benchmark. Observe a normal week, then capture a real busy period. Note when traffic peaks, when cron jobs run, when the database is busiest and whether alerts occur at the same time. The aim is to find the workload that is limiting the server, not to chase a permanently low CPU percentage.
- Establish a baseline. Record average CPU, peak CPU, memory use, swap, database response and page or API response time during a normal day.
- Identify the slow period. Tie the symptoms to actual events: checkout traffic, an import, a plugin backup, a marketing email, deployment, a report or a scheduled task.
- Find the busy process. Is it PHP, MySQL/MariaDB, a queue worker, Node.js, a build process, a crawler or a backup command? A vCPU upgrade should target a known workload.
- Change one meaningful variable. Optimise a query, move a backup, enable appropriate caching, increase worker capacity or resize CPU. Do not change everything at once, or you will not know what solved the issue.
- Measure again. Confirm that the actual symptom improved at the same time and under the same kind of load.
This method is especially important for self-managed VPS hosting. The server is flexible, but the flexibility also means you are responsible for knowing what is installed and how it uses resources. A larger server can hide a configuration problem temporarily; it cannot remove it.
One fast task versus many simultaneous tasks
vCPU requirements are often misunderstood because a server can complete one short request quickly and still struggle when several requests arrive together. A single cached page view may barely use CPU. At the same moment, however, an editor may save a post, WooCommerce may calculate a checkout, PHP may run a scheduled task and a backup process may be compressing files. The issue is concurrency: how many pieces of useful work need CPU at once.
This is why an occasional burst does not automatically justify a larger server. First check whether the burst is expected and whether it can be moved. Backups, image processing, imports and report generation are often better scheduled away from peak visitor time. When the work cannot be moved—such as checkouts, API calls or queue processing—the server needs enough CPU capacity to handle it without forcing customer-facing activity to wait.
A useful test is to record what is happening during the slow period, then repeat it after the background work has been rescheduled or optimised. If CPU pressure remains during normal visitor activity, more vCPU is a better-supported decision. If the problem disappears, the right solution was workload timing rather than a permanent larger server.
When a VDS is a better CPU choice than a VPS
A standard VPS is often the sensible choice where Linux root access and a flexible server environment are the requirements. Move toward VDS Hosting UK when dedicated CPU resources and a more predictable CPU profile matter to the workload. That can be relevant for a sustained production application, regular compute-heavy jobs, a busy store with known CPU pressure or a development workload that needs more consistent compute capacity.
The change should be based on an observed need. “Dedicated” is not automatically better for every website, and a VDS does not remove the need to tune databases, caches, workers or application code. It is a resource decision for a workload that has outgrown a more general VPS profile.
For a practical starting point, use the VPS Hosting UK configuration for the expected current workload, leave capacity to monitor and grow, and choose VDS where the CPU requirement is already clear. The better question is not “what is the biggest server I can buy?” It is “which limitation will stop this project working properly first?”
Related VPS and VDS pages
Use these pages after identifying the constraint. They explain the available server routes and the related resource decisions.
Frequently asked questions
How many vCPU do I need for a VPS?
Use one vCPU for a light single-purpose workload, two vCPU for a typical small website or application with some headroom, and four or more vCPU when CPU-bound work, higher concurrency, worker processes or multiple demanding services make one or two cores a constraint. Measure the actual workload after launch rather than treating any starting point as permanent.
Is a vCPU the same as a physical CPU core?
No. A vCPU is a virtual processor allocated to a virtual server. How it behaves depends on the virtualisation platform, the resource model and the workload. It should not be treated as a guaranteed one-to-one equivalent of a physical core.
Should I upgrade CPU or RAM first?
Upgrade CPU when CPU utilisation, load or CPU-bound queues are consistently the limiting factor. Upgrade RAM when memory pressure, swapping or out-of-memory events are present. Check both before resizing.
Does WordPress need more than one vCPU?
A small WordPress site can run on one vCPU, but plugins, page generation, cache misses, scheduled jobs, WooCommerce and traffic bursts can make two or more vCPU a more comfortable starting point. The site and stack matter more than WordPress alone.
When should I use VDS instead of VPS?
Use VDS when dedicated CPU resources and more predictable CPU performance are a clear requirement. A standard VPS is often sufficient when flexibility and root access matter more than dedicated compute resources.
Can I change vCPU later?
Plan for an upgrade path rather than trying to predict the final specification perfectly. Before any resize, take a backup and confirm how the change affects the installed operating system, disk layout and services.
