Why Shared Hosting Throttles Your Site: CPU Steal, I/O Limits, and What VPS Benchmarks Show

The most common cause of a slow shared-hosting site is not the website itself; it is the other tenants on the same physical server. On a typical shared plan, a single noisy neighbor can consume most of the CPU capacity and the disk queue, leaving your application with a fraction of the resources you paid for. This article explains how resource sharing actually works, how to measure throttling with standard Linux benchmarks, and what the numbers mean when you compare a shared account with a VPS. If you are shopping for a new host while you run these tests, keep our provider comparison table open to check specs side by side.

How shared hosting allocates resources

Shared hosting providers oversell a physical server across dozens or hundreds of accounts. The mechanisms they use vary, but the practical effect is the same:

• CPU: accounts share cores through time-slicing, and aggressive neighbors push your processes off the CPU.
• RAM: memory is oversold, so the kernel swaps or kills processes when total demand exceeds physical RAM.
• Disk I/O: every account shares the same SSD or NVMe queue, and one backup job or import can saturate it.
• Network: the uplink is shared, so a neighbor running a file-seeding script can starve your TTFB.

A VPS changes the model: the hypervisor carves the physical server into isolated slices with defined CPU shares, guaranteed memory, and capped I/O. Your neighbors can still cause some interference (see CPU steal below), but the isolation is far tighter than on a shared account.

CPU steal: the metric that exposes throttling

Linux tracks how long your virtual CPU waited for the hypervisor to schedule it while another tenant was running. Check it with vmstat 5 12 and read the st column, or with top (the %st field). On a healthy VPS, steal stays below 2%. On an oversold shared account or a badly oversold VPS node, it regularly climbs above 10%, and you will feel it as latency spikes and slow page loads even when your own CPU usage is near zero.

Run the measurement at different times of day for at least a week before drawing conclusions. A single 10-minute sample during off-peak hours will understate the problem.

What real benchmarks show

The numbers below are representative ranges from repeated tests on budget shared accounts and budget VPS plans (fio for disk, sysbench for CPU, and an uncached WordPress page render). Your results will vary, but the ratios are consistent:

Workload	Shared hosting (typical)	Budget VPS (typical)
WordPress page render, uncached	300–900 ms	80–200 ms
Indexed MySQL query, 10k rows	50–250 ms	5–30 ms
fio 4K random read (QD1)	1,000–8,000 IOPS	15,000–60,000 IOPS
sysbench CPU, single thread	500–1,200 events/s	1,500–4,000 events/s

Disk I/O shows the widest gap because it is the resource shared hosts oversell most aggressively. If your site does anything database-heavy, the I/O difference alone justifies the move.

Two notes on methodology. First, run each benchmark three times and use the median; a single run on a busy shared server can be 5x off. Second, shared hosts also cap things that do not show up in CPU or disk benchmarks: maximum inodes, database connections, cron frequency, and background processes. A plan that “allows” 25 MySQL connections will stall a WordPress site with a plugin that opens 40, regardless of how fast the CPU is. Read the plan’s process and connection limits before you compare benchmark numbers across providers.

Detecting throttling on your current host

• Run fio --name=randread --rw=randread --bs=4k --size=256M --iodepth=1 several times a day for a week and log the IOPS.
• Capture steal time with vmstat 5 12 during your peak traffic hours.
• Measure TTFB from a third-party monitoring service every 5 minutes, not just from your own connection.
• Correlate slowdowns with the provider’s status page and maintenance windows.

When the numbers justify moving to a VPS

Use these thresholds as a rule of thumb: sustained steal above 5%, random-read IOPS below 5,000, or TTFB spikes above one second during peak hours all indicate that the shared environment is the bottleneck. When that happens, no amount of caching or code optimization will fix it, because the problem is the resource allocation model itself. Compare the specs of candidate hosts in our provider comparison table before you commit.

What to check after migration

• Re-run the same fio and sysbench tests and compare against your shared-host baseline.
• Watch steal time for the first week; a good provider keeps it under 2%.
• Set up monitoring (Netdata or Prometheus) so a regression is visible before your users feel it.
• Re-check your PHP-FPM and MySQL settings; on a VPS you can finally tune them, unlike on shared hosting.

If your benchmarks confirm that you need dedicated, isolated resources, InterServer’s VPS plans start at $6/month with full root access and no per-core metering. Check current InterServer VPS pricing and run your own benchmarks before you decide.