Network latency affects load test accuracy because every response time your test records includes the round trip between the load generator and your server. A generator in the same data center as the target sees almost none of it, so the test looks fast. A generator on another continent sees all of it, so the same server looks slow. Neither number is wrong; each one describes a different route. To get results you can trust, run the test from the regions your users are in, and report network time separately from server time.
Key takeaways
- Latency between the load generator and your servers is added to every measurement.
- Generate load from the regions your users are in, or the numbers describe a route nobody takes.
- Report latency separately from server processing time so you can tell them apart.
How does network latency affect cloud load testing results?
Network latency is the time a packet needs to travel from one machine to another. Round-trip time (RTT) is the there-and-back version, and it is the part that lands in your results: a response time measured by a load generator is network time plus server time. If the RTT between generator and server grows, response times grow with it even though the server did nothing different.
Two mistakes follow from this. Testing from the same cloud region as the target hides the network entirely, so results are optimistic compared with what distant users see. Testing from a far-away region without knowing it blames the application for delay that belongs to the route. The fix in both cases is to know the RTT of each test location and read results with it in mind.
How much latency does distance add?
Light in optical fibre travels at roughly two thirds of its speed in a vacuum, about 200,000 km per second. That works out to around 1 ms of one-way delay per 200 km of cable, or 1 ms of round trip per 100 km. Real routes are longer than the straight line and add equipment delays, so measured RTTs are higher than these floors.
| Route (approximate great-circle distance) | Round-trip floor from physics | What to expect in practice |
|---|---|---|
| Same data center or region | under 1 ms | 1 to 2 ms |
| New York to London (about 5,600 km) | about 56 ms | higher; measure it |
| Frankfurt to Singapore (about 10,000 km) | about 100 ms | higher; measure it |
The floors are arithmetic from the fibre speed above, not measurements. Measure your own routes with ping, mtr or the connection timings in your load testing tool, because cable paths, peering and congestion can double the floor.
Why does a new connection cost more than the first byte?
Latency is paid more than once per request. Before the first byte of an HTTPS response arrives on a brand-new connection, the client needs one round trip for the TCP handshake, one for a TLS 1.3 handshake (two for TLS 1.2), and one for the request and response itself, plus a DNS lookup. With keep-alive, later requests skip the handshakes and pay one round trip.
A worked example with an RTT of 120 ms and 80 ms of server processing:
| Connection state | Round trips before the first byte | Time to first byte |
|---|---|---|
| New connection, TLS 1.3 | 3 (TCP, TLS, request) | 3 x 120 + 80 = 440 ms |
| Reused connection | 1 (request) | 1 x 120 + 80 = 200 ms |
| Generator in the same region (RTT 2 ms) | 3 | 3 x 2 + 80 = 86 ms |
The server took 80 ms in all three rows. The test setup alone moves the result from 86 ms to 440 ms. This is why a load test that opens a new connection for every request, which some scripts do by accident, reports far slower numbers than a browser that reuses connections.
Does network latency really hurt conversion?
Speed does affect business results, but be careful with the often-repeated “100 ms costs 7% of conversions” figure. It comes from Akamai’s Spring 2017 State of Online Retail Performance report, which found that a 100 millisecond delay in website load time can hurt conversion rates by 7 percent. It measured page load time on retail sites, not the network latency of an API, and secondary coverage reports different splits by device. Treat it as one retail data set from 2017, not a law, and measure the effect on your own funnel.
How do I find out whether a slowdown is network or server?
The cleanest method is to break each request into its phases and compare them across regions. Most tools do this:
- k6 records
http_req_connecting(TCP),http_req_tls_handshaking,http_req_waiting(time to first byte, the server think time plus one round trip) andhttp_req_duration, which k6 defines as sending plus waiting plus receiving and which excludes the initial DNS lookup and connection time. - JMeter records Connect Time and Latency. Its glossary defines latency as the time from just before sending the request to just after the first response, so it includes server processing, and connect time is not subtracted from it automatically.
- LoadFocus reports response time and latency, with 50th, 90th and 99th percentiles, per test run, and shows when errors appeared against the number of virtual users running at that moment.
Then run two controlled comparisons:
- Same test, different regions. Run the same script at the same load from a generator near the server and from one far away. The difference between the two medians is roughly the extra RTT times the number of round trips per request. If the far run is slower by about that amount at every load level, the cause is the network.
- Same region, rising load. Hold the location and raise virtual users. If time to first byte stays flat and then climbs sharply at a certain load, the server is saturating, and no amount of network work will fix it.
| What you see | Likely cause | First thing to check |
|---|---|---|
| Slower from far regions by a steady amount at every load | Distance and round trips | Keep-alive, CDN or a closer region |
| Connect and TLS times high, server wait normal | Network or handshake cost | Connection reuse, TLS version |
| Server wait climbs only as load rises | Backend capacity | CPU, database, thread pool |
| Erratic spikes unrelated to load | Congestion, routing or jitter | Repeat at different times of day |
For the metric definitions, see the posts on response time and percentiles. Averages hide a long network tail, so read p90 and p99 per region, not one global mean.
What else makes latency vary between runs?
Distance sets the floor. On top of it, results move because of the carrier and peering path (two ISPs in the same city can take different routes), congestion at busy hours, routing changes between runs, and whether the path crosses the public internet or stays inside a cloud provider’s private network. A test from inside the provider’s network to a service in the same provider often runs on a faster path than any real user gets, so test from outside it when you want a user’s view.
The fix is to repeat key tests at different times of day and compare the spread, not a single run. Variation inside a run is its own topic, covered in the post on network jitter.
How do I simulate real network conditions in a load test?
There are two approaches, and they answer different questions.
Use real distance. Run generators in the regions your users are in. This captures real routing and peering, and no emulation is needed. LoadFocus runs tests from 25 cloud regions, so you pick the location per test (loadfocus.com/load-testing, read 2026-10-23). The product page does not describe network emulation such as bandwidth throttling or injected delay, so use regions for realism.
Emulate a slow network. To model a poor mobile connection or a fixed extra delay, add it on the generator or a proxy in front of the target. On Linux, tc with netem adds delay, jitter and loss:
# add 100 ms of delay with 10 ms of jitter on eth0
tc qdisc add dev eth0 root netem delay 100ms 10ms
# remove it again
tc qdisc del dev eth0 rootThe netem manual notes that the delay applies to packets leaving the device and advises placing it on the receiving host for realistic TCP behaviour. Emulation is for controlled experiments such as “what happens to checkout at 250 ms RTT”, not a substitute for testing from the real locations.
Is lower latency always worth chasing?
No. Latency matters most for interactive and real-time work: pages with many sequential requests, chatty APIs, games, video calls and trading. A batch job that runs overnight is limited by throughput and reliability, and adding 100 ms of RTT barely changes how long it takes. Decide how latency-sensitive each user journey is before deciding how much of your test plan to spend on it.
Edge computing and CDNs reduce RTT by serving from closer to the user, which is why a test from a far region can look very different before and after a CDN is turned on. If you use one, test both cached and uncached paths. The posts on edge computing and load testing and multi-region deployments go into that, and the glossary entry on CDNs explains the basics.
Best practices for latency-aware load tests
- Record the RTT of each test location before the run and put it in the report next to the results.
- Match locations to your users. Pick the regions where most of your traffic comes from, not the one nearest your office.
- Reuse connections the way real clients do unless you are deliberately testing connection setup.
- Report time to first byte and total time separately, per region, with percentiles.
- Set thresholds per region. A 600 ms p95 may be fine from a distant region and a failure from a nearby one. LoadFocus lets you set a maximum p95 and p99, a maximum error rate and a minimum throughput as pass/fail thresholds (loadfocus.com/load-testing, read 2026-10-23).
- Repeat at different times of day to see congestion, and check the generator itself is not the bottleneck (high CPU on the load generator inflates response times just as latency does).
You can try this by running the same test from two regions on LoadFocus load testing and comparing the per-run percentiles.
Frequently Asked Questions
How does network latency impact cloud load testing accuracy?
It adds the round-trip time between the load generator and the server to every response time. A test from the same region as the target hides it, and a test from far away shows all of it. Neither is inaccurate, but they answer different questions, so you need to know the RTT of each location to interpret the results.
What causes network latency to fluctuate during load tests?
Distance sets a floor, and on top of that carrier routing, peering, congestion at busy hours and route changes move the number from run to run. Heavy load can also raise latency when queues build on shared links or on the load generator itself.
How do edge computing and 5G affect load testing?
Edge nodes and CDNs shorten the path between user and content, so response times from distant locations drop when they are in use. 5G lowers last-mile delay for mobile users. Both mean you should test from several locations and with cached and uncached paths, rather than assuming one latency for everyone.
Should every application be tested at the lowest possible latency?
No. Real-time applications such as video calls, games and trading are very sensitive to latency. Batch jobs and delayed reports mostly are not. Test at the latencies your actual users have, and spend extra effort where the user journey is chatty or interactive.
How do I measure network latency in a load test?
Use the per-phase timings your tool records: connect and TLS time, time to first byte, and total time. In k6 these are http_req_connecting, http_req_tls_handshaking, http_req_waiting and http_req_duration; in JMeter they are Connect Time and Latency. Outside the tool, ping and mtr give the raw RTT for a route.
How can I tell if a slow response is the network or the server?
Run the same test from a nearby and a distant region, and run it again at rising load from one region. A steady extra delay that does not change with load points to the network. A time that stays flat and then climbs sharply as load rises points to the server running out of capacity.
Sources
- Akamai, “Akamai Online Retail Performance Report: Milliseconds Are Critical”, press release, April 2017 (the akamai.com newsroom page needs JavaScript, so the wording was checked on a trade-press copy dated 24 April 2017 (ecommercenews.co.nz); read 2026-10-23).
- Grafana k6 documentation, built-in HTTP metrics (grafana.com/docs/k6/latest/using-k6/metrics/reference, read 2026-10-23).
- Apache JMeter user manual, glossary: Elapsed time, Latency, Connect Time (jmeter.apache.org/usermanual/glossary.html, read 2026-10-23).
- Linux
tc-netem(8)manual page (man7.org, read 2026-10-23). - LoadFocus load testing page (loadfocus.com/load-testing, read 2026-10-23).
Published with PostNext
