Marketing pages love big numbers. "99.9% uptime," "Blazing fast NVMe drives," "Global CDN." They sound good. But if your site feels sluggish, those adjectives don't help. You need data. As a support engineer, I see the same pattern in tickets: users blame plugins when the root cause is a saturated shared server or a misconfigured cache layer. You can fix a slow theme, but you can't code your way out of a CPU-throttled VPS. Today, we skip the fluff. We run five specific, technical tests to verify if your host delivers what they promise. These checks take about ten minutes. No fancy lab equipment needed. Just a terminal and a browser dev tool.
Test 1: Measure Time to First Byte (TTFB)
TTFB is the single most important metric for server-side speed. It measures the time between a browser sending a request and receiving the first byte of the response. This includes DNS lookup, TCP handshake, TLS negotiation, and server processing time. If TTFB is high, no amount of client-side optimization will save you. The server is too busy.
Open your browser’s Developer Tools (F12), go to the Network tab, and reload your site. Look for the main HTML document. Click it. In the Timing pane, you will see a breakdown. Focus on "Waiting (TTFB)." For a healthy, optimized WordPress site on a decent host, this should be under 200ms. If you see 500ms or more, the server is struggling. If it’s over 1 second, your host is likely overselling capacity or your site is hitting resource limits.
To get a consistent reading, run this test three times. Take the median. One-off spikes happen due to garbage collection or temporary load. But a consistent high TTFB is a red flag. In shared hosting environments, this is often caused by noisy neighbors. In VPS or dedicated setups, it usually points to CPU saturation or disk I/O bottlenecks.
Test 2: Check CPU and Memory Limits
WordPress is PHP-based. PHP processes are CPU-hungry. If your host doesn’t give you enough CPU, your site will crawl. How do you know if you’re hitting limits? You need to look at the server logs or use a monitoring tool.
If you have SSH access, log in and run this command to see the current load average:
uptime
The output will show three numbers: 1-minute, 5-minute, and 15-minute load averages. Compare these to your CPU core count. If you have a 2-core VPS and the 1-minute load is 4.5, you are oversubscribed. The system is waiting for CPU cycles. This causes direct TTFB spikes.
For memory, check your usage:
free -h
Look at the "used" column. If memory is nearly full and swap is being used, your server is swapping. Swapping is slow. It’s like moving files from a fast SSD to a slow USB stick. Your PHP workers will hang while the kernel pages memory in and out. If you see high swap usage on a lightweight WordPress site, your VPS is undersized. You need more RAM, not a better theme.
On shared hosting, you can’t see the whole server. But you can check your own resource usage via cPanel or your host’s control panel. Look for "Resource Usage" or "Metrics." If your CPU usage spikes to 100% during normal traffic, you’re hitting the host’s per-account limit. This is a common reason for intermittent slowdowns. The host isn’t broken; you’re just sharing the pie with someone who’s eating more than their share.
Test 3: Verify Cache Hit Ratio
Caching is the difference between a snappy site and a sluggish one. But only if it’s working. A cache that misses every request is worse than no cache, because it adds overhead without benefit. You need to verify that your cache is actually serving hits.
If you use a plugin like WP Rocket, LiteSpeed Cache, or W3 Total Cache, check the dashboard. Look for the "Cache Hit Ratio." A healthy ratio for a content-heavy site is above 80%. If it’s below 50%, something is wrong. Are you using dynamic elements that bust the cache? Are you not purging the cache when you update posts? Or is the cache plugin conflicting with your server-level cache?
For server-level caching (like LiteSpeed or Nginx FastCGI Cache), you can check the cache status in the response headers. Open your browser’s DevTools, go to the Network tab, and look for the X-Cache header. It should say HIT. If it says MISS, the server is generating the page from scratch. Do this after a page has been loaded once. If it still says MISS, your cache configuration is broken.
In support tickets, I often find that users have two caches enabled: a plugin cache and a server cache. They conflict. One purges, the other doesn’t. The result is a cache that never stabilizes. Pick one. Usually, server-level cache is faster. Disable the plugin cache if you have a good server cache. Then monitor the hit ratio for a day.
Test 4: Test Database Query Speed
WordPress is database-heavy. Every page load can trigger dozens of SQL queries. If your database is slow, your site is slow. How do you test this? You can’t easily run EXPLAIN on every query from the front end, but you can measure the time it takes to execute a simple query.
If you have SSH access, connect to your MySQL/MariaDB instance:
mysql -u root -p
Then run this query to check the status of your database engine:
SHOW STATUS LIKE 'Innodb_buffer_pool_read%';
Look at Innodb_buffer_pool_read_requests and Innodb_buffer_pool_reads. The ratio between them tells you how effective your buffer pool is. If Innodb_buffer_pool_reads is high relative to Innodb_buffer_pool_read_requests, your buffer pool is too small. It’s reading from disk instead of memory. Increase the innodb_buffer_pool_size in your MySQL configuration. A good rule of thumb is to set it to 50-75% of your available RAM if MySQL is the main workload.
If you don’t have SSH access, use a plugin like Query Monitor. It shows the execution time of each SQL query. Look for queries that take more than 100ms. These are your bottlenecks. Often, they’re caused by missing indexes. Check your wp_options table. It’s frequently queried. If it’s large and unindexed, every page load suffers. You can add indexes manually, but be careful. A bad index can slow down writes.
Test 5: Monitor Disk I/O Wait
Disk I/O is the silent killer. Even with NVMe drives, if your I/O wait is high, your server will feel slow. I/O wait is the percentage of time the CPU spends waiting for disk operations to complete. If it’s high, your storage is the bottleneck.
On Linux, you can check I/O wait using top or htop. Run htop and look at the CPU bar. The green section is user time, the blue is system time, and the red is iowait. If the red section is consistently above 20%, your disk is struggling. For a WordPress site, this is unusual unless you’re doing heavy backups, large image processing, or running a resource-heavy plugin.
To get a more detailed view, use iostat:
iostat -x 1 5
Look at the %util column for your main disk. If it’s near 100%, your disk is saturated. No amount of CPU or RAM will help. You need faster storage or a different hosting plan. On shared hosting, you can’t control this. If you see high I/O wait, it’s likely due to other accounts on the same server. This is a strong reason to migrate to a VPS or dedicated server if your site is growing.
What to check first
Start with TTFB. It’s the fastest test and gives you the clearest signal. If TTFB is low, your server is fine. Focus on client-side optimization. If TTFB is high, dig into CPU, memory, and disk. Check your cache hit ratio. If it’s low, fix your cache configuration. Then look at database query times. Finally, monitor I/O wait. This order saves time. You don’t need to run all five tests every day. Run them when you suspect a problem. Keep a log of your TTFB readings. Compare them over time. If they’re creeping up, you have a warning. Your host’s performance is degrading. It’s time to talk to support or plan a migration. Don’t wait until your site is unusable. The data is there. You just have to look for it.