iPhone Web Optimization, Lesson 1: The Thin Pipe

With the global iPhone 3G launch less than a week away, iPhone-optimized web content might become even more important than it already is, especially if the assumption that iPhone users make up for the largest chunk of mobile surfing holds internationally as well.

While there are lots of great resources about how to design web content for the iPhone and MobileSafari's unique capabilities, information about how to optimize content is scarce. For this reason I decided to write a couple of posts about the topic.

As a first step, it is important to understand in which ways the iPhone is different from other web browsing platforms. At a glance, we see that its screen is comparatively small and that it has multitouch browsing capabilities that are unique to it at the moment. However, harnessing this knowledge falls into the field of "design", not "optimization". Obviously, successful iPhone web content must be formatted to fit the screen nicely and must be usable with multitouch (i.e. no fancy javascript drag&drop coolness, etc.).

From the perspective of content optimization, it's more interesting to take a look at some technological properties: The iPhone's performance in processing web content for display and the way it accesses the internet, namely wireless LAN and GPRS/EDGE.

The rendering performance will only take a secondary priority here, since most of its limitations are already overcome implicitly by designing for the small screen, which means that we have to keep websites simple enough. Websites whose loading times are bound by rendering performance issues on the iPhone are usually those that are heavily overloaded and clearly not designed for a mobile browsing experience anyway.

Therefore, let's take a closer look at the networking hardware now: Since we're optimizing, we gain most by embracing the worst case. If the worst case scenario works fine, all the others will work fine too.

The Thin Pipe
"But EDGE and GPRS are just slow, so if we keep everything small, the site will load fast. And once the iPhone 3G comes out, this won't be an issue anymore at all!", you might think. Well, is it true? And what exactly do you mean by "slow"?

The thing is that there are actually multiple dimensions of "network speed", the three most important to us being "bandwidth", "propagation delay" and "packet loss".

Bandwidth refers to the overall amount of data that can be pushed through the pipe within a given period of time. For EDGE networks, this is 230-something kbps, with around 100 kbps being the average case. Plain GPRS bandwidths are an order of magnitude smaller than that, typical 3G/HSDPA bandwidths are an order of magnitude larger. Note that these are not insanely small measures or anything (a couple of years ago, having GPRS bandwidths over wired telephone lines was considered to be normal!). Therefore, bandwidth only plays only a limited, though important, role in making mobile surfing feel "slow".

Propagation delay is the important property that is often overlooked. It refers to the amount of time that passes between the signal being transmitted from one endpoint and it being received at the other one. Note that this is not referring to theoretical physical limits (like the speed of light), but to plain simple technical limits such as wait times due to timesharing protocols, time spent processing at the endpoints, etc. Wireless networks such as GPRS, EDGE and even 3G/HSDPA have very large propagation delays when compared to wired links such as ADSL lines. This has to do with the way data is being sent over the air (I don't want to go into detail here since it's not really important for our purposes, but it has to do with the timesharing necessary so that multiple clients can be connected to the same cell, as well as the modulation algorithms).

Typically, GPRS links have propagation delays of about 500ms (often much more), EDGE falls somewhere between 200ms and 500ms, and 3G can theoretically be much faster, but often also exhibits delays above 100ms. By comparison, the propagation delay of an ADSL link between your home network and your ISP's router is usually only a couple of milliseconds!

Note that propagation delay and bandwidth are independent properties. For example, there are some links that have insanely large bandwidths, but also huge propagation delays: Satellite links! Similarly, a link can have a rather meager bandwidth while having a fast propagation delay, such as ISDN links. In any case, the two properties do not influence each other.

The last property, packet loss, refers to the amount of (random) data packets being lost during flight. This has to do with link quality and is often not even noticeable for wired links. For cellular networks, however, we have to keep the possibility of a large packet loss ratio in mind that can be caused by bad reception.

The Real World
Now let's look at the interaction of these properties in a real-world theoretical example (heh!): Let user A download 100KB of web content from server B, say, an image file. A uses her iPhone over an EDGE connection with good reception and a bandwidth of 100 kbps. It takes 250ms for the request sent by her iPhone to reach the first router (the propagation delay) and 250ms again for the reply to be sent back from the last router to her iPhone. The rest of the packet flight time (within the internet) takes about 100ms, whereas server B needs about 50ms to actually dispatch the request and start serving the file. Summing up all these delays (propagation delays and the server's processing time), we see that user A will only receive the first bit of data (and start to see something "appearing" in her MobileSafari window) after 250+100+50+100+250 = 750ms. Then it will take 8-10 seconds for the 100 kilobyte file to be downloaded over the 100 kilobit/s EDGE connection (8 seconds minimum, but it might take longer due to packet loss).

In this scenario, the largest chunk of time (8-10 seconds) is taken up by the file actually downloading. To contrast this, though, assume user A now downloads a tiny 1 kilobyte file, say, a snippet of text, from the same server over the same connection. Pushing 1 kilobyte over a 100 kilobit/s link takes only 80ms (packet loss not factored in), but the waiting time caused by the various delays, especially EDGE's slow propagation delay, remains constant: Still 750ms! So in this case, the majority of time is actually spent waiting rather than downloading!

This might come as a surprise to those who equate perceived network speed with bandwidth, but as we have seen, sheer content size (and consequently EDGE/3G bandwidth) might not even be the most limiting factor in an iPhone-optimized website. It might be the slow propagation delay. Even worse, 3G, while being considerably better than EDGE in this departement, also has a large propagation delay compared to wired links.

Seeing that the bandwidth (especially if EDGE or 3G is available) isn't even that bad, but propagation delay is (or can be), we can rephrase the intuitive conclusion of "having to keep everything small" to something along the lines of

  1. Minimize the amount of individual web requests
  2. If 1. is satisfied, minimize the byte count of your content

Thusly, there are, surprisingly, many many scenarios in iPhone web content optimization where serving a slightly larger amount of data with fewre individual requests is preferable over serving less data, but via more requests!

Now that we have a better understanding of why surfing over cellular networks feels slower than over wired links, my next post on this subject will introduce some useful techniques to minimize the amount of web requests in your iPhone-optimized web application or site.

UPDATE: Next lesson now online

3G on Wikipedia
GPRS on Wikipedia
EDGE on Wikipedia