Why the mobile web is so slow
Published by Martin Kleppmann on 23 Nov 2007.
On the “desktop/laptop web” (in contrast to the mobile web), we’ve become used to a page loading in
about a second. On mobile phones, we are still far from seeing anything near that responsiveness –
for most people, the mobile web experience is still agonisingly slow. Personally, I start to get
irritated after about five seconds, and after as little as ten seconds there is a strong chance that
I will go away and do something else. And currently it’s still a challenge to get a page to load
within that timeframe on a mobile.
Ever wondered why it is so slow? Yesterday I was reading a few
articles, and I repeatedly came across people who made a very simplistic assumption: namely that the
available network bandwidth is fully used. For example, they will say: on a standard 3G/UMTS
connection, each subscriber can transfer 384 kbit/s, therefore a 24 kB web page (text and a few
small pictures) will load in 0.5 seconds. Honestly, if you’ve ever tried to access even a simple
web page from a phone you know that this figure is just laughably wrong. It is never that
Finally, after lots of searching, I found
this paper by
Sarit Mukherjee and Sampath Rangarajan. And they give some
good reasons why this is the
- The round-trip time for packets is between 400 and 1000 ms in a typical 3G cell.
- Packets loss is inevitable in wireless transmissions because of radio interference.
There are two approaches to packet loss: either let TCP deal with retransmission (in which case it
thinks the network is congested, and reduces the transfer rate), or to retransmit lost packets in a
low-level protocol (in which case the round-trip times observed by TCP can vary wildly, which
confuses TCP and also reduces the transfer rate).
In a nutshell, TCP is really not up to
the job, but it’s so widely used that there is basically no chance that it is going to be replaced
anytime so on. (WAP included a layer called the
Wireless Transaction Protocol, which attempted to be a
better replacement for TCP. But we know what happened to WAP – nobody wants to use it.) In their
paper, Rodriguez et al. go on to describe a method for partially getting round the problem by
rewriting DNS and HTTP responses – it’s not ideal, but at least it removes some of the worst
The real problem here is that round-trip time though. On a normal broadband connection
I’d expect a round-trip time between 25 ms (within the UK) and 125 ms (across the Atlantic). On 3G,
even though the bandwidth is not that much lower than broadband, we’ve got a round-trip time 8 to 15
times higher. And this time really becomes noticeable every time you click on a
- Send a DNS request for the hostname we want to contact, and wait for the response.
(Unless we’ve cached the DNS record on the
- Send a TCP SYN packet to the server we want to contact, and wait for the response.
- Send the HTTP query over the established TCP connection.
that every time we click a link, we have to wait 2 or 3 round trip times – i.e. between 0.8 and 3.0
seconds – until we get the very first few bytes of the page we requested. That’s assuming that none
of those first few packets got lost (because if one of them was lost, there would be no way of
telling – all you can do is wait for a timeout and try again). And then we still have to transfer
the whole page, and have all the TCP issues to deal with.
I just hope that mobile phones nowadays use
persistent HTTP connections or
pipelining which would remove some of the overheads.
Does anybody know if they do? I’d like to hear from you.
PS. I thought I had accidentally deleted
this post – fortunately I managed to find it again, hidden away in a binary mess, in the MySQL log