Most VPS marketing pages look identical. Big numbers. Flashy icons. "Unlimited" bandwidth. It’s noise. You don’t need unlimited. You need consistency. When your site spikes, you need the server to hold up. That depends on five specific hardware metrics. Ignore the rest. Focus on these five, and you’ll avoid 90% of hosting regrets. I’ve migrated clients from cheap providers to better ones. The difference wasn’t the brand. It was the underlying hardware spec sheet. Let’s break down what actually moves the needle.
1. CPU Cores and Clock Speed
This is the engine. If your application is PHP-heavy, like WordPress, CPU speed matters more than core count in the early stages. A single fast core handles a burst of requests better than two slow ones. But if you’re running a database or a Node.js app, cores matter. More cores mean more parallel processes. Don’t just look at the number. Check the type. Shared CPU resources are a trap. If the provider oversells, your CPU time gets throttled when your neighbor runs a backup. Ask for dedicated vCPUs. It’s not just about speed. It’s about predictability. A dedicated core is yours. It doesn’t vanish at 2 PM on a Tuesday.
How to test it
Before you commit, ask for a trial or a short-term plan. Run a simple load test. Use ab (Apache Bench) or wrk against a static file on your server. Watch the response times. If they spike when you increase concurrent connections, the CPU is the bottleneck. Check the CPU model in the control panel or via lscpu. Know what you’re buying. Intel Xeon E3 v4 is different from AMD EPYC. The latter often offers better single-thread performance for the same price. But verify. Specs change. Models change. Don’t trust the marketing name. Trust the benchmark.
2. RAM: Static vs. Swapped
RAM is where your OS and apps live. If you run out, the server starts swapping to disk. That’s where speed dies. A 1-second response becomes a 10-second response. The metric isn’t just total RAM. It’s headroom. If you allocate 2GB, you need at least 500MB free for the OS and buffers. Otherwise, you’re living on the edge. Check how the provider counts RAM. Some include the OS overhead. Some don’t. Ask specifically: "Is this RAM dedicated or shared?" If it’s shared, you’re renting a seat in a crowded bus. You might get bumped. Use free -h on your server. Look at the available column, not free. available accounts for cache. It’s the real number. If available drops below 20% of total RAM under load, you need more. Don’t wait for the crash. Scale up before the user does.
The swap trap
Some providers offer huge swap space. It looks like a bonus. It’s not. Swap is slow. If you’re relying on swap, your site is already broken. Swap should be a safety net, not a primary storage layer. Keep it small. 1-2GB is enough for most LAMP stacks. If you need more, upgrade RAM. Don’t hide the problem with swap. Monitor your swap usage with vmstat 1. If si and so columns show high numbers, you’re swapping heavily. That’s a red flag. Fix the RAM. Not the swap.
3. Disk Type and I/O Performance
This is the most common point of failure. HDDs are dead for web hosting. If a provider offers HDD-based VPS, walk away. SSDs are the baseline. NVMe is the standard. But not all SSDs are equal. Some use cheap, low-endurance NAND. Others use enterprise-grade. The difference shows up in IOPS (Input/Output Operations Per Second). A high IOPS disk handles random reads and writes faster. Databases live and die by IOPS. If your WordPress site uses a large database, disk I/O is critical. Check the provider’s IOPS guarantee. If they don’t list it, ask. "What is the average IOPS for a 40GB SSD plan?" If they hesitate, they don’t know. And if they don’t know, you’re in trouble. Run fio or dd to test write speeds. A simple dd if=/dev/zero of=testfile bs=1M count=1024 oflag=direct will show you raw write speed. If it’s under 100MB/s, you’re on slow storage. Upgrade. Don’t gamble with your database integrity.
Filesystem matters
Ext4 is standard. XFS is faster for large files. Btrfs has compression. Choose based on your workload. If you store logs, XFS is better. If you store small files, Ext4 is fine. But don’t overlook the disk type. Filesystem is a detail. Disk type is the foundation. Get the foundation right. Everything else is tuning.
4. Network Bandwidth and Latency
Bandwidth is how much data you can transfer. Latency is how fast it travels. Most providers advertise "unlimited" bandwidth. That’s a lie. They mean "fair use." They throttle you if you exceed a soft limit. Check the fine print. Look for "burstable" or "shared" network ports. A 1Gbps port shared among 100 users is not a 1Gbps port. It’s a 10Mbps port on a good day. Ask for dedicated bandwidth. Even if it costs more. It’s worth it. Latency is equally important. If your server is in Singapore and your users are in New York, you’re fighting physics. No amount of bandwidth fixes that. Pick a data center close to your audience. Use ping to test latency from your location to the server. Under 50ms is good. Over 100ms is noticeable. Over 200ms is painful. If you can’t get low latency, use a CDN. Cloudflare or similar. But the origin server should still be reasonably close. Don’t rely on a CDN to fix a bad location. It masks the problem. It doesn’t solve it. Test from multiple locations. Use mtr to trace the route. If the path is long and winding, latency will spike. Choose a provider with good peering. Ask about their upstream providers. If they use a major backbone, you’re safe. If they use a small regional ISP, you’re gambling.
Burst vs. Sustained
Some plans offer "burst" bandwidth. You get 1Gbps for a short time. Then it drops to 100Mbps. If your traffic is spiky, this is fine. If your traffic is steady, you need sustained bandwidth. Know your traffic pattern. Look at your analytics. If you have a steady drip, sustained matters. If you have spikes, burst is enough. Don’t pay for sustained if you don’t need it. But don’t assume burst is enough if you’re streaming video. Match the spec to the workload. It’s not one-size-fits-all.
5. OS Choice and Kernel Tuning
The OS is the interface between your app and the hardware. Linux is the standard. Windows is rare for VPS. Stick with Linux. But which distro? Ubuntu is safe. Debian is stable. CentOS is dead. RHEL is enterprise. Alpine is lightweight. Choose based on your team’s comfort. If you know Ubuntu, use Ubuntu. Don’t switch to Alpine just because it’s "modern." You’ll spend time learning new tools. That’s time lost. But the OS choice isn’t just about familiarity. It’s about kernel tuning. Linux kernels can be tuned for low latency. For high throughput. For high I/O. Most providers use a generic kernel. That’s fine for 90% of cases. But if you’re running a high-traffic site, ask if they offer kernel tuning. Some providers allow you to change kernel parameters. Others lock them down. If they lock them down, you’re stuck with their defaults. That might be slow. It might be fast. You won’t know until you test. Check if they use sysctl defaults that favor network performance. Look for net.core.rmem_max and net.core.wmem_max. If they’re low, your network throughput is capped. Ask to increase them. If they refuse, they’re not flexible. That’s a red flag. A good provider lets you tune the kernel. A bad one doesn’t. Choose flexibility. It pays off when you need to optimize.
Security patches
The OS also handles security. If the provider doesn’t patch quickly, you’re exposed. Check their patch policy. Do they patch within 24 hours? 48 hours? A week? If it’s a week, you’re at risk. Zero-day exploits don’t wait. Ask about their security team. Do they have a dedicated team? Or is it an afterthought? Read their security page. If it’s vague, they’re vague. If it’s detailed, they’re serious. Choose a provider who treats security as a priority. Not a checkbox. It’s part of the OS choice. A fast OS that’s insecure is worthless. Balance speed with safety. Don’t sacrifice one for the other.
What to check first
Start with the disk. If the disk is slow, nothing else matters. A fast CPU on a slow disk is a waste. Check the IOPS. Then check the RAM. Make sure you have headroom. Then check the CPU. Ensure it’s dedicated. Then check the network. Ensure it’s not shared. Finally, check the OS. Ensure it’s patchable and tunable. That’s the order. Disk first. RAM second. CPU third. Network fourth. OS fifth. It’s a hierarchy. Respect it. Don’t skip steps. Don’t assume. Test. Run the commands. Check the logs. Verify the specs. Don’t trust the marketing. Trust the metrics. You’ll save money. You’ll save time. And your site will be fast. That’s the goal. Not the cheapest price. The best performance per dollar. Find that balance. And you’ll sleep better. Your users will notice. They’ll stay. That’s the real win. Not the spec sheet. The user experience. Build for that. Everything else is detail. Focus on the five metrics. Ignore the rest. You’ll make the right choice. Every time.