How to Run a Proper Speed Test on Your Hosting (Tools and Benchmarks)

Why Most Hosting Speed Tests Are Misleading

The internet is filled with "fastest hosting" reviews that rank providers based on a single PageSpeed Insights screenshot or one GTmetrix test run. These tests are almost always misleading because they conflate front-end optimization (image compression, CSS minification, JavaScript deferral) with actual hosting performance (server response time, I/O throughput, concurrent request handling). A beautifully optimized static HTML page will score 100 on PageSpeed Insights regardless of whether it is hosted on a $2/month shared server or a $200/month dedicated machine.

To genuinely evaluate your hosting performance, you need to isolate the server-side factors from the client-side factors. You need to measure under realistic conditions, not just with a single request to an empty site. And you need to understand what the numbers mean in the context of your specific workload. This guide provides the tools, methods, and benchmarks you need to run a proper hosting speed test.

The Metrics That Actually Measure Hosting Performance

Time to First Byte (TTFB)

TTFB measures the elapsed time between sending an HTTP request and receiving the first byte of the response. It encompasses DNS resolution, TCP connection, TLS handshake, and server processing time. When measured from a location near the server (same data center or same city), TTFB primarily reflects server processing speed. When measured from a distant location, network latency is a significant component.

For hosting evaluation purposes, TTFB should be measured from multiple locations. A good hosting server should deliver TTFB under 200ms from the nearest location and under 500ms from distant locations for a dynamic WordPress page. With server-level caching (LiteSpeed Cache), cached TTFB should be under 50ms from the nearest location. For deeper analysis, see our dedicated TTFB optimization guide.

Server Response Time (Server Processing Time)

Server processing time is the portion of TTFB that occurs on the server itself, excluding network transit. It measures how long the server takes to receive the request, execute PHP, query the database, and begin sending the response. This is the purest measure of hosting performance because it removes network variability from the equation.

To isolate server processing time, measure TTFB from within the server itself using tools like curl or ab run from the server's command line. The difference between local TTFB and remote TTFB reveals the network latency component.

Requests Per Second (RPS) / Throughput

RPS measures how many concurrent requests your server can handle per second while maintaining acceptable response times. This is critical for understanding how your hosting will perform during traffic spikes, sales events, or viral content surges. A server that delivers fast TTFB for a single request but collapses under 50 concurrent requests is not suitable for any site that expects variable traffic.

I/O Performance (IOPS and Throughput)

Storage I/O directly affects database query speed, PHP file loading, and static file serving. Measuring IOPS and throughput reveals the storage tier your hosting provider uses and whether it is adequate for your workload. Sites on NVMe SSD storage will show dramatically higher I/O numbers than those on SATA SSD or HDD.

Database Query Latency

For dynamic websites, database performance is often the bottleneck. Measuring the time to execute representative queries (simple SELECTs, JOINs, and INSERTs) reveals whether the database server is properly configured and has adequate resources.

Essential Tools for Hosting Speed Testing

1. curl (Command-Line TTFB Testing)

The simplest and most reliable way to measure TTFB is with curl. From your server's SSH terminal or your local machine:

curl -o /dev/null -w "DNS: %{time_namelookup}s\nConnect: %{time_connect}s\nTLS: %{time_appconnect}s\nTTFB: %{time_starttransfer}s\nTotal: %{time_total}s\n" -s https://yourdomain.com

This breaks down the request into its component phases: DNS lookup, TCP connection, TLS handshake, TTFB, and total transfer time. Run this 10 times and calculate the average to account for variability. The time_starttransfer value is your TTFB.

2. Apache Bench (ab) for Concurrency Testing

Apache Bench (included with most Linux distributions) tests how your server handles concurrent load:

ab -n 1000 -c 50 https://yourdomain.com/

This sends 1,000 requests with 50 concurrent connections. Key outputs to examine:

• Requests per second: Your server's throughput capacity.
• Time per request (mean): Average response time under load.
• Percentage of requests served within a certain time: The distribution shows whether some requests are much slower than others (indicating resource contention).
• Failed requests: Any non-zero value indicates your server is struggling at this concurrency level.

3. wrk (Advanced Load Testing)

wrk is a more modern and capable load testing tool that uses multiple threads and event-driven I/O:

wrk -t12 -c400 -d30s https://yourdomain.com/

This runs a 30-second test with 12 threads and 400 connections. wrk provides latency distribution (average, standard deviation, max) and throughput. It is particularly useful for finding the breaking point of your hosting, the concurrency level where response times begin to degrade significantly.

4. Siege (Realistic User Simulation)

Siege simulates real user behavior by requesting multiple different URLs with configurable delays between requests:

siege -c 25 -t 60s -f urls.txt

Where urls.txt contains a list of representative pages on your site. Siege reports transaction rate, response time, throughput, concurrency, and availability percentage. This is more realistic than single-URL testing because real traffic hits different pages with different resource requirements.

5. fio (Storage I/O Benchmarking)

If you have SSH access, fio measures the raw storage performance of your hosting:

# Random read test (simulates database queries)
fio --name=randread --ioengine=libaio --iodepth=32 --rw=randread --bs=4k --direct=1 --size=256M --numjobs=4 --runtime=30 --group_reporting

# Random mixed read/write (simulates web application workload)
fio --name=randrw --ioengine=libaio --iodepth=32 --rw=randrw --rwmixread=70 --bs=4k --direct=1 --size=256M --numjobs=4 --runtime=30 --group_reporting

Compare your results against the benchmarks in our NVMe SSD performance guide to determine whether your hosting uses HDD, SATA SSD, or NVMe storage.

6. WebPageTest (Multi-Location Real Browser Testing)

WebPageTest (webpagetest.org) runs real browser tests from locations worldwide. For hosting evaluation, focus on:

• First Byte Time: Measured from the test location to your server.
• Waterfall diagram: Shows the timing of every resource, revealing where time is spent.
• Repeat view: Compares first visit (cache-miss) and repeat visit (cache-hit) performance.
• Multiple locations: Test from locations near and far from your server to understand network latency impact.

7. Google PageSpeed Insights (Core Web Vitals Field Data)

While PageSpeed Insights mixes front-end and hosting metrics, its field data section shows real-user Core Web Vitals collected from Chrome users. This is the data Google actually uses for ranking. The TTFB shown in the diagnostics section, combined with the LCP value, reveals how much of your page load time is consumed by server response.

How to Run a Proper Benchmark: Step-by-Step

Step 1: Establish a Baseline

Before making any changes, measure your current performance across all metrics. Use curl for TTFB from at least 3 locations, ab or wrk for concurrency testing, and WebPageTest for a full browser-based test. Record all results with timestamps.

Step 2: Test Dynamic and Cached Separately

If your site uses caching, test both scenarios:

• Cached test: Request the same URL twice. The second request should show cached TTFB.
• Uncached test: Purge the cache before each test, or append a unique query string (?nocache=timestamp) to bypass cache. This measures your server's true dynamic performance.

The cached test tells you what most visitors will experience. The uncached test reveals how the server performs when it must generate a fresh response, which happens after cache purges, for logged-in users, and for long-tail pages with infrequent traffic.

Step 3: Test Under Realistic Load

Single-request TTFB is important but insufficient. Your server needs to maintain performance when multiple visitors are active simultaneously. Use Siege with a URL list that includes your homepage, key landing pages, blog posts, and any dynamic pages (search results, product filters):

# Create a URL list
echo "https://yourdomain.com/" > urls.txt
echo "https://yourdomain.com/about/" >> urls.txt
echo "https://yourdomain.com/blog/" >> urls.txt
echo "https://yourdomain.com/contact/" >> urls.txt

# Test with 25 concurrent users for 60 seconds
siege -c 25 -t 60s -f urls.txt

Step 4: Compare Against Benchmarks

Use these benchmarks to evaluate your results:

Step 5: Test During Peak Hours

Shared hosting performance varies based on the activity of other accounts on the same server. Run your tests at different times of day, including peak hours (typically 10am-2pm in the server's timezone). Consistent performance throughout the day indicates a well-managed server with proper resource isolation. Performance that degrades significantly during peak hours suggests oversold infrastructure.

Common Pitfalls in Speed Testing

• Testing from only one location. Network latency varies dramatically by geography. A server in New York will show excellent TTFB when tested from the US East Coast and poor TTFB from Singapore. Always test from locations that represent your actual audience.
• Testing only the homepage. Homepages are often the most optimized and most frequently cached page on a site. Test representative interior pages, blog posts, product pages, and search results to get a complete picture.
• Confusing Lighthouse scores with hosting speed. Lighthouse scores incorporate dozens of factors, most of which are front-end. A poor Lighthouse score does not necessarily mean poor hosting, and a good score does not necessarily mean your hosting is fast.
• Testing immediately after deployment. Caches need time to warm up. DNS needs time to propagate. Test at least 24 hours after any major change to get stable results.
• Ignoring variability. A single test result is anecdotal. Run each test at least 10 times and look at the median (50th percentile) and 95th percentile. The 95th percentile reveals worst-case performance that affects 1 in 20 visitors.

What to Do With Your Results

If your TTFB is consistently above 500ms for uncached requests, the issue is almost certainly server-side. The most common causes, in order of impact:

1. No server-level caching: Enable LiteSpeed Cache or equivalent.
2. Slow storage (HDD or SATA SSD): Migrate to NVMe-based hosting.
3. Outdated PHP version: Upgrade to PHP 8.x.
4. Unoptimized database: Tune MySQL/MariaDB configuration.
5. Oversold server: Migrate to a hosting provider with proper resource isolation, such as MassiveGRID's high-availability cPanel hosting.

If your TTFB is under 200ms but overall page load is slow, the issue is front-end: unoptimized images, render-blocking CSS/JS, excessive third-party scripts, or lack of compression. These are solvable through application-level optimization without changing hosts.

Frequently Asked Questions

How often should I run speed tests on my hosting?

Run a comprehensive benchmark monthly to track trends. Set up automated monitoring (tools like UptimeRobot, Pingdom, or New Relic) for continuous TTFB tracking. Sudden TTFB increases often indicate server issues (resource contention, disk degradation, or traffic spikes from neighboring accounts on shared hosting) that need immediate attention.

Can I trust hosting review sites that publish speed benchmarks?

Be cautious. Many hosting review sites use affiliate revenue models that create conflicts of interest. Look for reviews that publish their methodology, test dynamic content (not just static pages), test over extended periods (not just one-time snapshots), and measure from multiple locations. Synthetic tests on a freshly installed WordPress site with no content do not represent real-world performance.

Is a lower TTFB always better?

For cached pages, yes. For uncached pages, TTFB below 100ms may not provide meaningful user-perceived benefit over 200ms. The practical threshold is around 200ms for uncached and 50ms for cached. Below these numbers, other factors (network latency, browser rendering) dominate the user experience. That said, headroom is valuable. A server with 100ms uncached TTFB has more capacity to handle traffic spikes without degradation than one at 400ms.

Why does my TTFB vary between tests?

TTFB variability is normal and caused by network routing changes, server load fluctuations, cache warm/cold states, and DNS resolution timing. Variability of 10-20% is typical. Variability above 50% suggests unstable hosting (inconsistent server resources or network quality). Always use the median of multiple tests rather than a single measurement for decision-making.

Should I test from my own location or from where my visitors are?

Both, but prioritize your visitors' locations. Use Google Analytics or similar tools to identify where your traffic originates geographically, and run tests from those regions. Your personal experience browsing the site may not represent what your audience experiences if you are in a different location from most of your visitors.