Web Hosting Server Hardware Explained: CPU PassMark, NVMe vs SSD, and Why Specs Lie

Why Hardware Specs Actually Matter (And Why Most People Read Them Wrong)

A hosting plan with 4 vCPU, 4 GB RAM, and "SSD storage" sounds solid on paper. The same plan at a different host with 4 vCPU, 4 GB RAM, and "NVMe SSD storage" on a server with 10 tenants outperforms it by a measurable margin. A third host with 2 vCPU, 4 GB RAM, and NVMe storage but on a server with 50 tenants and no resource isolation may be worse than the first at peak hours.

The spec numbers are inputs. The outcome you care about is what those specs deliver under your specific workload, with your specific neighbor tenants, in your specific traffic pattern. Most hosting guides stop at the spec definition. This guide goes to the performance outcome — because that is the only number that matters when your site is under load and visitors are waiting.

The Three Scenarios Where Hardware Becomes the Problem

Hardware is invisible when it is sufficient. You notice it in three scenarios: a sudden traffic spike from a viral post or product launch where the server cannot absorb the concurrent load, a slow WooCommerce checkout that no plugin fixes because the database is on HDD and queries take 80ms instead of 2ms, and a site that performs fine at 9 AM but degrades every day at 2 PM because a neighbor on the shared server runs a scheduled task that consumes available CPU.

Each scenario has a different hardware cause and a different solution. Conflating them leads to buying more of the wrong thing. Buying extra CPU when the database is the bottleneck wastes money and solves nothing. The web servers guide covers the software stack that runs on this hardware. This guide covers the physical layer that determines the ceiling on everything above it.

CPU: Cores, Clock Speed, IPC, and What WordPress Actually Uses

Most hosting pages show a core count and stop there. That single number hides three separate performance dimensions that affect WordPress differently: core count (how many PHP requests can run at once), clock speed (how fast each individual request executes), and IPC or instructions per clock (how efficiently the CPU architecture uses those clock cycles). They are not interchangeable, and optimizing one without the others produces diminishing returns.

Core Count and Concurrent Requests

PHP is single-threaded per request. One PHP-FPM worker handles exactly one request at a time. When 20 visitors hit your WordPress site simultaneously, 20 PHP-FPM workers execute in parallel. If you have 4 vCPU and 20 workers, those workers share 4 vCPU. Each worker gets roughly 0.2 vCPU of time. When all 4 vCPU are busy, new requests queue behind them and wait.

Core count therefore determines your concurrent request ceiling. More cores means more PHP workers can run simultaneously without queueing. A 1 vCPU server running 10 PHP-FPM workers starts queueing requests at 10 concurrent visitors. A 4 vCPU server running 40 workers handles 40 concurrent visitors before queueing starts. This is the number that determines whether your site handles a traffic spike or falls over during it.

Clock Speed and PHP Execution Time

Clock speed (measured in GHz) determines how fast each individual PHP request executes. A 3.5 GHz vCPU executes the same PHP code faster than a 2.2 GHz vCPU of the same architecture. For WordPress, PHP execution time per uncached request typically ranges from 50ms to 400ms depending on plugin complexity. A 3.5 GHz CPU executes that same workload in roughly 60-70% of the time a 2.2 GHz CPU takes.

Clock speed matters most for WooCommerce checkout and other non-cacheable operations. A product page that executes PHP for 300ms at 2.2 GHz takes around 200ms at 3.5 GHz. That 100ms difference shows up directly in TTFB and perceived page speed. I have seen WooCommerce checkout TTFB drop from 450ms to 280ms purely from moving to a provider with higher clock speed CPUs at the same core count.

IPC: The Spec Hosting Companies Never Show You

IPC stands for instructions per clock. Two CPUs running at 3.0 GHz can complete dramatically different amounts of work per second if one architecture executes 30% more instructions per clock cycle. IPC is why modern AMD EPYC and Intel Xeon processors from 2023-2025 outperform 2018-era processors at the same GHz. The hosting spec sheet never shows IPC because it requires knowing the CPU generation and architecture, not just the headline frequency.

The practical test: run a PHP benchmark (like php -r "echo number_format(sqrt(1000000), 2);" 1000 times and measure total time) on any hosting you evaluate before committing. PassMark scores are a useful starting point for CPU generation comparison, but they measure multi-threaded throughput. For WordPress, single-threaded performance scores (Cinebench single-core equivalents, or PHP single-process benchmarks) are more representative. A server running 2024-generation AMD EPYC processors at 2.8 GHz will outperform a server running 2018-generation Intel Xeon at 3.2 GHz for most PHP workloads because the IPC advantage more than compensates for the clock speed difference.

Burst vs Sustained CPU Performance

Burstable CPU instances are a legitimate product category at AWS, Google Cloud, and some VPS providers. You get full vCPU allocation for short periods but are throttled to a fraction of that for sustained load. A T3.micro on AWS has 2 vCPU but earns CPU credits at a rate that allows only 10% of a single vCPU when credits are exhausted. A WordPress site that gets a traffic spike drains credits fast. Once drained, PHP execution slows to a crawl and TTFB spikes from 200ms to 3+ seconds.

Cloudways uses dedicated vCPU allocation — the vCPU on their plans is not burstable. ScalaHosting's managed VPS plans also guarantee dedicated vCPU allocation. If you are evaluating a cloud provider directly (DigitalOcean, Linode, Vultr), choose their standard Dedicated CPU plans over Basic/Standard plans for any production WordPress site above 10,000 monthly visits. The price difference is modest. The performance consistency difference is significant.

RAM: The Resource That Determines Whether Your Server Accelerates or Crawls

RAM is not storage for your files. It is the active workspace where every layer of your hosting stack operates simultaneously. MySQL keeps recently accessed database rows in RAM. PHP-FPM holds compiled bytecode in OPcache. Redis keeps object cache entries in RAM. The web server process runs in RAM. Every connection your site handles requires RAM somewhere. When demand exceeds supply, the operating system starts writing RAM contents to disk — a process called swapping. Swap is where server performance goes to die.

How RAM Is Actually Used on a WordPress Server

Add those up for a minimal, properly configured WordPress server: InnoDB buffer pool (512 MB) + PHP-FPM four workers at 60 MB each (240 MB) + OPcache (128 MB) + Nginx (30 MB) + Redis (128 MB) + OS (300 MB) = approximately 1.3 GB. That is the minimum for comfortable operation on a single-site WordPress server. With 1 GB total RAM, something is undersized. With 512 MB total RAM, multiple components are fighting each other and swap becomes a constant.

The Swap Problem

Swap is disk space used as overflow RAM. Modern SSDs can read swap at 400-550 MB/s with 0.1ms latency. RAM reads at 25,000-50,000 MB/s with 0.00001ms latency. When the OS starts swapping, RAM access operations that should take nanoseconds start taking milliseconds. A single database query that reads 10 pages from an InnoDB buffer pool sitting in swap instead of RAM takes 100x longer than the same query from actual RAM. MySQL on a swapping server is not slow. It is effectively non-functional.

Check for swap activity right now on any VPS you manage: vmstat 1 5 and look at the si (swap in) and so (swap out) columns. Any non-zero values mean your server is swapping. Even occasional swap activity indicates your RAM allocation is below what the workload needs. I have seen hosting migration cases where moving from a 2 GB shared hosting account to a 2 GB VPS delivered no improvement because the VPS had the same four tenants sharing the same physical RAM pool, while shared hosting had throttled the site before swap started.

OPcache: Free Performance You Should Never Leave Disabled

PHP OPcache is the single highest-impact performance setting on any WordPress server and requires no code changes. Without OPcache, every page view causes PHP to open and read every .php file in WordPress core and all active plugins, parse the PHP syntax into tokens, compile those tokens into bytecode, and then execute the bytecode. WordPress core alone has 1,500+ PHP files. Loading, parsing, and compiling them on every request takes 30-80ms.

With OPcache enabled, the compiled bytecode is stored in shared memory after the first request. Every subsequent request skips reading, parsing, and compiling entirely and jumps directly to execution. The 30-80ms compilation overhead becomes effectively zero. Check your OPcache status at any time by creating a temporary file with phpinfo() and searching for "opcache" — look for Opcache Hit Rate above 90% on a warm server. Below 90% usually means opcache.max_accelerated_files is too low for the number of PHP files in your WordPress installation.

NVMe vs SSD vs HDD: The Spec That Changed WordPress Hosting Performance

Sequential read speed is the number hosting companies advertise. NVMe at 3,500 MB/s sounds impressive versus SATA SSD at 550 MB/s. For WordPress, sequential read speed is almost completely irrelevant. WordPress database operations are random, small I/O: fetching a 4 KB row from a MySQL table, reading a 2 KB option from the wp_options table, writing a 1 KB cache key. Sequential speed measures how fast the drive reads a continuous block of data, like copying a 10 GB file. Random I/O performance — measured in IOPS — is what actually determines WordPress database query speed.

IOPS: The Number That Determines Database Performance

A WordPress site with a primed cache (Redis object cache hitting, OPcache warm, page cache serving most requests) issues very few storage I/O operations. Turn off the cache layer for a moment: every page view executes 30-80+ MySQL queries, each requiring one or more storage reads. On a busy WooCommerce store with 100 simultaneous non-cached requests, that is potentially 3,000-8,000 storage I/O operations per second.

HDD at 100-200 IOPS handles 100 of those operations per second. The remaining 2,900-7,900 queue. Queue depth grows. Every queued operation adds latency. TTFB spikes from 200ms to 4+ seconds. The same workload on SATA SSD at 50,000 IOPS has 99% headroom. On NVMe at 500,000 IOPS, the storage layer is never the bottleneck. This is the practical difference. Not the sequential speed number. The IOPS ceiling and the queue behavior under load.

Queue Depth and Latency Under Load

Storage latency compounds with queue depth. A single random read on NVMe takes 0.02ms. When 100 simultaneous reads arrive, NVMe handles them in parallel via its PCIe interface with multiple queues (NVMe supports 64,000 queue pairs vs SATA's 1 queue). SATA SSD handles reads through a single command queue, serializing requests. Under sustained high I/O, SATA SSD latency climbs from 0.1ms to 2-5ms as the queue depth grows. NVMe maintains consistent sub-0.1ms latency even under high queue depth because of its parallel queue architecture.

The real-world test is a WordPress site during a WooCommerce flash sale. Page cache eliminates most reads, but every checkout, every add-to-cart, every order confirmation is a series of non-cacheable database writes and reads. On SATA SSD, a flash sale generates I/O wait times that show up in server monitoring as disk await exceeding 20ms. On NVMe, the same sale generates disk await under 2ms. That difference in await time is the difference between checkout completing in 1.2 seconds and completing in 4.5 seconds.

Testing Your Host's Storage Speed

# Install fio (I/O benchmark tool)
apt install fio -y   # Debian/Ubuntu

# Test random 4K read IOPS (simulates database read pattern)
fio --name=rand-read --ioengine=libaio --rw=randread \
  --bs=4k --numjobs=4 --iodepth=32 \
  --size=512m --runtime=30 --time_based \
  --filename=/tmp/fio-test --output-format=normal

# Look for: "read: IOPS=" in the output
# Good NVMe VPS:    IOPS=100,000-500,000
# Good SATA SSD:    IOPS=20,000-80,000
# HDD:              IOPS=100-300

# Test random write IOPS (simulates database write pattern)
fio --name=rand-write --ioengine=libaio --rw=randwrite \
  --bs=4k --numjobs=4 --iodepth=32 \
  --size=512m --runtime=30 --time_based \
  --filename=/tmp/fio-test --output-format=normal

# Clean up test file after
rm /tmp/fio-test

Run this test on any VPS before committing to a long-term plan. The IOPS number in the output tells you the real storage performance under a WordPress-like I/O pattern. The number on the hosting plan's marketing page tells you sequential speed, which is almost entirely irrelevant to WordPress performance.

Network Interface Cards: The Bandwidth Layer Most Guides Never Mention

The network interface card (NIC) determines the maximum data throughput between the server and the internet. It is the pipe. No matter how fast the CPU and storage are, the server cannot transfer data faster than the NIC allows. For most WordPress sites, the NIC is never the bottleneck. For sites serving large media files, running file downloads, or handling simultaneous video streams, the NIC becomes the limiting factor and the oversubscription ratio determines the real-world ceiling.

Oversubscription: What Shared NIC Really Means

A physical server has one NIC. That NIC connects to the data center network. When 500 shared hosting accounts share one physical server with a 1 Gbps NIC, each account's theoretical bandwidth ceiling is 1 Gbps / 500 = 2 Mbps. In practice, not all 500 accounts send traffic simultaneously, so the real average per-account throughput is higher. But during peak hours, when a significant subset of those accounts are serving concurrent requests, bandwidth contention reduces each account's effective transfer rate.

This matters for sites serving large page sizes, many images, video files, or large CSS/JS bundles. A site with 4 MB of combined assets serving 100 simultaneous visitors needs 400 MB of bandwidth per page load cycle. At 2 Mbps per account (0.25 MB/s), that cycle takes 1,600 seconds. That is obviously unrealistic, which is why shared hosting relies on cache, CDN, and traffic patterns to stay within bounds. The point: shared NIC oversubscription is invisible until it is not, and the hosting page never shows you the oversubscription ratio.

10 Gbps NICs and Why VPS Plans Changed the Calculus

Most modern VPS providers connect their hypervisor nodes to 10 Gbps or higher network ports. Even on a node running 50 VPS instances, each instance has access to 200 Mbps average bandwidth before contention. For any website serving typical HTML, CSS, JavaScript, and images optimized for web delivery (total page weight under 2 MB), 200 Mbps is never the constraint. You would need 12,500 simultaneous full-page loads per second to saturate that. The NIC stops being relevant for VPS customers unless you are running a file hosting service, a video platform, or extremely large asset downloads.

The practical conclusion: for standard WordPress sites, focus on CPU, RAM, and storage. Only revisit NIC specifications if your server monitoring shows network saturation (outbound bandwidth consistently at or near the advertised limit). For sites serving large media, CDN offloads the NIC problem entirely by serving assets from edge nodes, removing that traffic from your origin server's bandwidth budget. The CDN guide explains how Cloudflare and similar services change the effective bandwidth calculation for origin servers.

RAID: What It Does, What It Cannot Do, and Why Hosts Oversell Its Importance

RAID is a technology for combining multiple physical drives to improve either redundancy, performance, or both. Hosting providers frequently mention RAID in their marketing. What they almost never say clearly: RAID protects against exactly one failure scenario — a physical drive dying. It does not protect against any of the much more common data loss scenarios that actually affect WordPress sites.

RAID Is Not a Backup

This is not a technicality. It is the most important thing to understand about RAID in a hosting context. RAID mirrors data between drives in real time. If you delete a file, the deletion replicates to all mirrors immediately. If malware overwrites your WordPress files, the overwritten files replicate to all mirrors immediately. If a bad database update corrupts your tables, the corruption is mirrored to all drives immediately. In every software-level data loss scenario, RAID preserves the corrupted state perfectly across all drives.

The only event RAID protects against is a drive physically failing without a software event preceding it. Drive failure rates are low on enterprise-grade NVMe drives (mean time between failure in the millions of hours). The RAID protection you are paying for protects against a scenario that happens roughly once per decade per drive, while offering zero protection against the scenarios that happen weekly in the WordPress community: accidental deletion, plugin update gone wrong, hacked site with files overwritten, migration error wiping content.

RAID Rebuild Risks

RAID arrays are most vulnerable during the rebuild period after a drive fails. In RAID 5, one drive has failed and the array is running in degraded mode. The controller is rebuilding the parity from the remaining drives. A large NVMe drive rebuild takes several hours. During rebuild, the remaining drives are under sustained stress — read stress for parity calculation, not unlike the stress profile that causes drives to fail. The probability of a second drive failing during the rebuild of the first is meaningfully higher than the baseline failure probability. RAID 5 with drives that have accumulated significant write cycles is the most common scenario for total data loss on a hosting server.

RAID 10 (stripe with mirroring) is the most resilient practical configuration because each drive has a dedicated mirror. A drive failure requires only that one mirrored pair to be replaced and synced, not a full parity rebuild across all drives. Most quality NVMe hosting uses RAID 10. The performance of RAID 10 (double read throughput because both drives in a pair can serve reads) combined with NVMe's already exceptional IOPS is the current standard for high-performance hosting infrastructure. Understanding this tells you what to look for when a host says "RAID storage" — ask whether it is RAID 1, RAID 5, or RAID 10, because the answer has material consequences for both performance and real resilience. For backup strategy that actually protects WordPress data, the backup and restore guide covers what a real recovery plan looks like.

Hosting Tier Hardware Map: What You Actually Get at Each Price Point

Hosting pricing tiers exist because hardware costs money. Understanding what hardware each tier typically provides tells you what performance ceiling you are buying and where the limits will appear under load.

The gap between shared hosting and VPS is not primarily CPU or storage type. It is RAM guarantee and resource isolation. Shared hosting pools RAM across hundreds of tenants without guarantees. A VPS allocates a specific amount to your instance that neighbors cannot consume. This isolation is why the same WordPress site can have dramatically different performance on two plans with identical advertised specs, depending on which tier they are on and how aggressively the provider oversells their physical hardware.

ScalaHosting's managed VPS plans use NVMe storage and provide isolated resource allocation. Cloudways builds on top of DigitalOcean, GCP, Vultr, or AWS infrastructure and provides NVMe-backed VPS with managed stack configuration. The best VPS hosting guide covers the specific hardware configurations across providers with measured performance comparisons.

How to Diagnose a Hardware Bottleneck on Your Hosting

A site is slow. The cause could be PHP (CPU-bound), the database (storage-bound), RAM pressure (swap-bound), or network (geography-bound). Each has a different fix. Misdiagnosing and buying more CPU when the database needs more RAM wastes money and solves nothing. This is the diagnostic sequence I use when reviewing a slow WordPress site, starting from the most common cause.

Step-by-Step Bottleneck Diagnosis (With Commands)

# Step 1: Check overall server load
# load average should be below number of CPU cores
top -bn1 | head -5
# Example output: load average: 3.2, 2.8, 2.5
# On a 4-core server, 3.2 is high but manageable; above 4.0 = CPU saturated

# Step 2: Check RAM and swap
free -m
# Look for: Swap used > 0 = swap is active, investigate further
# If swap > 200 MB in use, your server needs more RAM

# Step 3: Check swap activity in real time (1-second intervals)
vmstat 1 10
# Columns to watch: si (swap in), so (swap out)
# Any non-zero values = active swapping occurring right now

# Step 4: Check disk I/O wait (critical for storage bottleneck diagnosis)
iostat -x 1 5
# Look for: %await column. Above 20ms = disk is queuing I/O requests
# Above 50ms = storage is severely bottlenecked
# Check 'util' column: above 90% = drive is saturated

# Step 5: Check MySQL slow queries
# First, enable slow query log in /etc/mysql/mysql.conf.d/mysqld.cnf:
# slow_query_log = 1
# long_query_time = 1
# slow_query_log_file = /var/log/mysql-slow.log
# Then review: tail -100 /var/log/mysql-slow.log

# Step 6: Check PHP-FPM pool utilization
# If using PHP-FPM, check active workers vs max_children
ps aux | grep -c php-fpm
# Compare output to pm.max_children value in your pool config
# If active workers = max_children, you have hit the pool ceiling

# Step 7: Check OPcache hit rate
php -r "
\$s = opcache_get_status();
\$hits = \$s['opcache_statistics']['hits'];
\$misses = \$s['opcache_statistics']['misses'];
echo 'OPcache hit rate: ' . round(\$hits / (\$hits + \$misses) * 100, 2) . '%' . PHP_EOL;
"
# Target: above 90%. Below 80% means opcache.max_accelerated_files is too low.

Using GTmetrix for External Bottleneck Diagnosis

Server-side tools show the symptom from inside the server. GTmetrix shows it from outside, as your visitors experience it. The key metric for hardware diagnosis is TTFB (Time to First Byte) on the Waterfall tab, specifically for the initial HTML request. A TTFB above 500ms on a cached page means something is wrong with either your cache configuration or your server is throttled. A TTFB above 500ms on uncached pages with all caching disabled tells you the true PHP + database execution time. That number tells you whether you need faster CPU, more RAM for better database caching, or faster storage for better I/O throughput.

Test TTFB with caching enabled versus caching disabled (temporarily rename your page cache directory to break it). The ratio of cached to uncached TTFB shows how much work your cache is doing. A site with 50ms cached TTFB and 800ms uncached TTFB has excellent caching but would benefit from database optimization. A site with 400ms cached TTFB suggests the bottleneck is happening before the page cache layer, which points to PHP execution time or OPcache misconfiguration.

Hardware Requirements Calculator: Find What Your Site Actually Needs

Hosting marketing sells you specs without context. This tool asks about your site's actual workload and outputs a specific hardware configuration recommendation with the reasoning behind it — not a generic plan tier, but the actual numbers to look for in a plan spec sheet.

Hosting Marketing Tricks and What They Actually Mean

Hosting companies sell numbers. They select, present, and frame those numbers to maximize perceived value. Understanding the gap between what is advertised and what is meaningful lets you compare plans accurately rather than being guided by marketing language.

The "Unlimited" Claim

Unlimited storage and unlimited bandwidth are physically impossible. A server has a finite disk. A network port has a finite speed. "Unlimited" in a hosting context always means: we will not actively charge you overage fees, but we will throttle, suspend, or ask you to upgrade if your actual usage significantly exceeds what we priced for. The fair usage policy or acceptable use policy in the terms of service quantifies this — it is usually 10-50 GB of storage and 1-5 TB of bandwidth in practice, regardless of what "unlimited" suggests on the marketing page.

The more important limitation: "unlimited SSD" with no further specification almost always means SATA SSD, not NVMe. A provider genuinely offering NVMe will say "NVMe" specifically, because it is a meaningful differentiator worth advertising. Seeing "SSD" with no additional qualifier is a reasonable signal to ask support: "Is this NVMe or SATA SSD?" The answer tells you more about the host's infrastructure quality than the price does.

CPU Credit Systems and Burstable Instances

Cloud VPS providers (and some managed WordPress hosts built on cloud infrastructure) offer two CPU allocation models: standard and burstable. Standard plans guarantee the vCPU allocation consistently. Burstable plans (AWS T-series, GCP E2, Azure B-series, and similar) provide a baseline CPU percentage (often 5-20% of a vCPU) and allow burst to the full vCPU allocation by consuming pre-accrued CPU credits. Credits accrue when CPU usage is below baseline and deplete when CPU usage is above baseline.

For a WordPress site with consistent traffic throughout the day, burstable instances can be a reasonable option at lower price points. For a WooCommerce store with flash sales, a site that gets unexpected viral traffic, or any site with sustained high PHP execution demand, burstable instances are a trap. The credit pool depletes fast, and the site throttles to a fraction of the advertised speed at exactly the moment when performance is most important. Always check whether a managed hosting plan is built on burstable instances. Cloudways explicitly uses non-burstable compute on DigitalOcean and Vultr underlying infrastructure, which is a meaningful differentiator.

Server Hardware Myths Debunked

Hardware myths circulate in WordPress hosting discussions because the subject is technical, specifications are rarely explained, and vendors have financial incentives to oversimplify. These are the ones that cause the most costly mistakes.

Where to Go Next

Understanding server hardware gives you the foundation to evaluate hosting plans accurately. The next layer up is the software that runs on that hardware. The web servers guide covers how Apache, Nginx, and LiteSpeed use the CPU and RAM resources differently and which stack gets the most out of the hardware underneath. If your performance problem is database-related after running the diagnosis commands above, the MySQL optimization section of the caching guide covers InnoDB tuning and Redis object cache configuration. For sites where geographic network latency is the dominant factor rather than server hardware, the CDN guide explains how edge caching removes origin hardware from the performance equation entirely for cached requests. If you are choosing a managed VPS and want to know which providers deliver the NVMe, resource isolation, and stack configuration this guide describes, the VPS hosting comparison covers tested performance across the main providers with actual TTFB measurements.