A 60-second speed test measures one response path at one moment. It cannot separate provider performance from region distance or routing. It also cannot isolate cache state or shared CPU limits.
One speed test cannot rank hosting providers
A short test shows one server response, one route, and one workload. It cannot show behavior during a traffic spike or noisy-neighbor event.
Time to first byte (TTFB) combines network distance, TLS setup, app work, database calls, and server queue time. CPU tools like sysbench measure processor work. Disk tools like fio measure storage speed. Network tools like iperf3 measure transfer paths.
None of these tools predicts checkout or API tail latency. Compare equal-sized instances in the same region and hour. Use the same software image for every test.
p95 latency shows the time reached by 95% of requests. P99 captures the slowest 1% of requests. A store can average 180 ms while p95 reaches 1.4 seconds. Averages can hide customers most likely to abandon carts.
Rank providers by tail latency, errors, and saturation together. Do not rank them by average response time alone.
Load tests find capacity, synthetic tests find reach
Synthetic checks measure external reachability. Load tests show capacity under concurrent demand. You need both because an HTTP 200 probe can hide queued checkout requests.
| Tool | Public entry price | Best test length | Decision it supports |
|---|
| k6 OSS | $0 software license | 10 to 30 minutes | HTTP capacity, p95/p99, errors |
| Apache JMeter | $0 software license | 30 to 120 minutes | Complex sessions and API flows |
| UptimeRobot | Free plan, paid plans from $7/month | Continuous probes | Availability and outage timing |
| Datadog Synthetics | From $5 per 10,000 test runs | Continuous probes | Multi-step user journeys |
Synthetic monitoring runs scripted requests from known locations. It records availability, DNS failures, TLS errors, and response time. A probe usually acts like one user. It does not act like 200 shoppers sending requests together.
Monitor from at least two US locations. Record incident duration, frequency, HTTP status, and failed transaction steps. An SLA is a target, not proof of observed availability.
Load testing applies expected concurrent demand. Stress testing finds the failure point. Spike testing imitates launches. Soak testing exposes leaks over 6 to 24 hours.
Record p95, p99, errors, resource use, saturation, and queue growth. A server at 70% CPU can still cause painful delays. Use synthetic monitoring for reachability questions. Use k6 or JMeter for concurrent transaction capacity.
For web hosting performance testing, pair synthetic monitoring with real-user monitoring (RUM). Do this when the site has meaningful production traffic. Synthetic checks give a repeatable baseline from fixed locations.
RUM shows what browsers actually experienced across device types and ISPs. It also includes cached pages, uncached pages, and real network conditions. Compare both signals by route.
If synthetic checks stay green, RUM may still show rising p95 checkout time. Check CDN routing, DNS resolution, third-party scripts, or regional packet loss.
RUM should validate customer impact, not replace controlled load tests.
A Seven-Step test makes hosts comparable
A fair comparison keeps region, instance shape, stack, traffic profile, and time window identical. It also uses the same duration and measurement method.
Keep the test bed identical
Create the same 2 vCPU, 4 GB RAM instance at every provider. Put each instance in the same region, such as Northern Virginia. Match the operating system, web server, app runtime, database, and cache.
Match TLS settings, CDN state, disk size, and HTTP settings too. Compare cost against useful work. A cheaper instance may need two replicas to keep p95 below one second.
In that case, the setup may cost more than one larger node.
Ramp traffic and record the server
Warm the cache for 5 to 10 minutes. Then raise traffic in stages. Use 25, 50, 100, and 150 virtual users. Hold each stage for 10 to 15 minutes.
Record successful transactions and requests per second. Record p95, p99, and HTTP errors. Also record CPU steal time, memory pressure, and disk queue depth.
Track database connections, packet loss, and jitter. Repeat matching test windows in the morning, afternoon, and evening.
Comparable US host test flow
1. Same region
Ashburn or Ohio
2. Same stack
CPU, RAM, disk, app
3. Warm up
5 to 10 minutes
4. Ramp load
25 to 150 users
5. Rank p95, p99, errors, cost
Do not use this as the main decision rule for sites with minimal traffic or without response-time needs. Avoid it on fully managed platforms where you cannot control settings or repeat load. Never run aggressive production tests without written approval, safety limits, live monitoring, and a rollback plan.
Define HTTP capacity by the workload your service must sustain. For example, sustain 80 completed checkout requests per second. Keep p95 below 800 ms and p99 below 2 seconds. Keep the error rate below 1%.
Virtual users are useful, but they may not create a stable request rate. Slow responses make each user send fewer requests. Run a staged virtual-user test and a constant-arrival-rate test.
Use realistic think time, request mixes, logged-in sessions, and cache states.
Server saturation starts when added load sharply worsens tail latency, queue growth, or errors. Successful throughput will not rise by the same amount.
Validate the load generator before you rank providers. One small machine running k6 or JMeter can hit its own limits. It may run out of CPU, sockets, bandwidth, ports, or TLS capacity.
Monitor generator CPU, memory, network speed, dropped connections, and achieved request rate. Do this during every run. For higher loads, use several generators and combine their results.
Use the same test region and network profile for each provider.
If visitors come from several regions, repeat a separate scenario from each region. Do not combine regional results into one capacity score. Label the traffic source for every result.
Common questions
Should i use k6 or apache JMeter?
Use k6 for code-based HTTP tests and JMeter for complex sessions or older protocols. Both are free to run locally.
How long should a soak test run?
Run a soak test for 6 to 24 hours to find leaks or slow resource loss. Short tests mainly show immediate limits.
Is 99.9% uptime good enough?
99.9% uptime permits about 43 minutes of downtime in a 30-day month. Verify outages from two locations instead of trusting an SLA alone.
Can synthetic tests measure real users?
Synthetic tests measure a scripted path, not all real-user conditions. Pair them with real-user monitoring when possible.
What p99 latency should i accept?
Set p99 by user action, often under two seconds for a key transaction. Compare providers at identical throughput.
Choose the host with the safer p99
Choose the provider with lower p95 and p99 latency, fewer errors, and enough capacity at your required load. Pick it even when its listed price is higher. A low-cost virtual machine can still be a sound choice.
The provider must show stable tails in three test windows. It must also avoid CPU-steal and disk-queue problems.
- One isolated speed result describes one moment and route. It does not show a provider's full capacity.
- Synthetic checks show reachability. Controlled load tests show saturation and error behavior.
- Use equal US regions, matching stacks, staged traffic, and three time windows. This gives a fair comparison.
- Choose with p95, p99, errors, observed availability, and cost per successful transaction.
