The impact of network packet loss on HTTP latency

Over the course of my involvement [1] in my Indonesian company’s website, the question of how to design a website to deal with slow and bad network links presented itself over several occasions as most of our users surf either over a mobile connection or a similarly dimensioned fixed line. While optimizing design and resources for good response times has been covered [2] extensively, it still remains interesting to see how exactly network attributes affect speed and latency in HTTP.
Attributes of a network affecting its performance is it’s capacity, latency and error rate. In this post I am going to focus on the impact of a network link’s error rate as measured in the percentage of packets lost on the time it takes to request and retrieve a network resource over HTTP such as an image or HTML file.
As we’ll see, even moderate packet loss leads to a greatly increased response time and hence latency. This delay is caused by the lost packets, which are retransmitted by the TCP stack only after a specific timeout has elapsed. The greater the timeout, the longer it takes for the lost packet to be detected and retransmitted.
The test setup
The following tests were conducted by sequentially retrieving three files of different sizes (996B, 25,1KB and 227,2KB) from a tomcat 6 webserver over a 100 MBit Ethernet connection on an Ubuntu 64bit installation.
The tc command was used to induce random, artificial packet loss in the underlying network connection [3].
All tests request the three files 10.000 times sequentially from the webserver and record the individual times, the total times and the averages for these requests.
Test runs
No packet loss

The first test is conducted with the unmodified network link, yielding no surprises. The average times for the payloads are shown below:

Payload size Response time (ms)
996B 1
25,1KB 3
227,2KB 22
0.1% Packet loss
The second run was conducted with a 0.1% packet loss but didn’t produce significantly different results.

1% packet loss

Payload size Response time (ms)
996B 31
25,1KB 41
227,2KB 170

2% packet loss

Payload size Response time (ms)
996B 42
25,1KB 60
227,2KB 190


Even a low, random, packet loss greatly increases the time it takes for a browser to request and load a resource over the web. The charts displayed are capped at 100ms, however the test data shows that as packet loss increases, the frequency of requests with abnormal high durations increases alongside with the maximum delay for these requests.

While the average time to download a resource increases only moderately, the range of delays introduced is quite high, reaching well into the magnitude of seconds. As typical web pages consist of several stylesheets, javascript and images all of which need to have finished loading before the complete impression of the web page stands, the probability of at least one of these resources not loading in time is high with these scenarios.

In line with expectations, the time to lead for large resources is impacted most by a moderate packet loss. On the other hand a further increase in packet loss does not lead to a similar deterioration of the load time for large resources (11% increase for double packet loss) as for small resources (33% increase for double packet loss).


As we’ve seen, even moderate packet loss introduces arbitrary delays in the time required to load resources from the web. While it is important to keep resources small in order to avoid fragmentation of the network payloads and delays due to retransmission, combining multiple resources into fewer, larger ones (such as with image spriting) yields quantifiable benefits.

[1] Bazarooma

[2] Even faster Websites, Steve Souders at Google I/O 2009
[3] Simulating packet loss

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.