Considerations for Mobile Design (Part 1): Speed

This article is a part of a series:

1. Part 1: Speed
2. Part 2: Dimensions
3. Part 3: Behavior

How do traditional screen web designs translate on handheld devices? This series aims to identify constraints in mobile web design so we can better serve our users.

I remember when I first dabbled in Mobile Web Design. The year was 2006, and hype for the recently announced “.mobi” top level domain (TLD) was strong. Armed with my new BlackBerry Pearl 8100, I was ready to try my hand at building a mobile experience on its whopping 240x260px display.

That part of my life was short-lived. Between the sudden emergence of media-rich sites such as YouTube and Facebook, and the ensuing browser wars (that year marked the launch of both Firefox 2 and IE 7), my excitement for Mobile Web quickly diminished. To me, mobile wasn’t web on the go; it was the web of last resort.

Fast-forward five years and mobile had begun to gain traction. Competition in the mobile broadband market resulted in pretty decent download speeds. Furthermore, top-of-the-line devices boasted higher resolutions (and even came with color spaces that rivaled desktop monitors). The icing on the cake? Support for web standards across these devices matured greatly, which meant that design wasn’t as much a shot-in-the-dark as it used to be. Cameron Moll even wrote a book on the subject.

As it turns out, the Mobile Web is no longer the web of last resort. It’s the web of accommodation. Adapting to our busy lifestyles, it’s ready at the touch of a button.

Let’s get considerate

This series—Considerations for Mobile Design—aims to help experience designers understand how the transition to mobile affects their audience and, in turn, their designs. In the beginning, we’ll take a look at the rules governing today’s mobile sites. In part two, we’ll discuss how expectations might change as the underlying technology continues to improve. Along the way, we’ll cover mobile-specific interaction design, mobile device constraints, and building websites that are responsive, working well on both handheld devices and traditional screen displays. Ready? Let’s get started.

Speed. It’s important.

Let’s begin with an exposition.

Two trains leave from the same points of origin, traveling towards the same destination. They are identical in every way except one: the first train travels twice as fast as the second. Except for the occasional passenger who’s out to see the scenery, it’s obvious that the first train is the better choice when it comes to reaching your destination.

This illustration is more or less straightforward (especially in our case when users are watching a progress bar instead of some beautiful scenery), but it’s still an important concept. Our users use the web to get things done. As a consequence, time is of the essence. The choice of which specific tool (sites) they use is heavily influenced by just how quickly that tool accomplishes their goals. Therefore, optimize your websites to load as quickly as possible.

In the past, we’ve gone over some important ways to minimize load times for faster user experiences. We’ve also shown you how you can optimize your images for the web. I won’t spend too much time here explaining basic concepts for improving a web page’s load time. If you’d like to explore this concept further, be sure to check out Steve Souder’s book, High Performance Web Sites.

Because mobile devices transmit data at slower rates of speed, the weight of a website is even more critical. While many mobile devices are now offering packages with even faster transfer rates, it’s not uncommon for users to have sub-256Kbps connections, which means we need to make every bit count.

Since we’re talking about some pretty nuanced stuff here, let’s take a second to address some of the basics.

Kbps vs. KBps vs. Mbps

The following are some common units of measurement with regards to data transfer online.

• Kb: Kilobit (128 bytes)
• KB: Kilobyte (8 Kilobits)
• Mb: Megabit (128KB or 1024Kb)
• MB: Megabyte (8Mb or 1024KB or 8192Kb)

People often get confused when working with Kilobytes vs. Kilobits, and misunderstand how fast download speeds are as a result. If your download rate is 256Kbps (Kilobits per second), you will not download a 256KB (Kilobyte) file in 1 second. Since there are 8 Kilobits in 1 Kilobyte (there are 8 bits in a byte), a 256Kbps download rate take about 8 seconds to download a 256KB file.

To convert Kbps to speeds you may be more comfortable working with, you could do the following:

• Kbps to KBps: Kbps / 8 = KBps
• Kbps to Mbps: (Kbps / 8) / 128 = Mbps

Speeds change but expectation is constant

Ten years ago, 256Kbps would have suited most people perfectly. In a world where 150Kbps-1Mbps download rate was considered “normal” for high speed—and a typical webpage weighed in at under 100Kb—256Kbps meant that websites loaded almost instantaneously.

According to researchers from the University of Twente, nearly all web traffic in 2000 was caused by plain ol’ images and text. That number changed dramatically by 2007, though, when most online traffic became dominated by photos, videos, and other binary downloads. As a consequence, the mean response size (size of files transmitted over the web) increased by over 500% in that period of seven years.

So much has changed in how people use the web over the past decade. Today we stream video; present graphically rich interfaces; and use relatively heavy client-side scripts (relative to ten years ago) to tie it all together. But despite all this, the relative speed of the user’s experience has remained constant, or even improved. How could this be?

In 2010, the United States FCC defined “Basic Broadband” as a data transmission speed of at least 4 Mbps downstream. Coupled with the fact that the the average page size that year was 320KB, a typical load time for a web page in 2010 was under 1 second. In other words, we’re still loading modern, richly textured web applications instantly, or at least fast enough that it doesn’t bother anyone.

Whether you’re designing a web application in 2011, or an entirely new experience in 2020, users have come to expect a quick and responsive experience. If a user has a choice between two tools that accomplish the same task, and one does so faster than the other, that’s the one they are more likely to choose.

Translating the experience to mobile devices

If we serve the same heavy weight user experiences to mobile devices that we do on our high-bandwidth devices, we run the risk of causing long load times and unresponsive websites. To demonstrate how detrimental this could be to the potential experience, observe the weight of the following sites, and their approximate load times given a 256Kbps download speed:

Website Load Times

These figures reveal how our expectations of websites have changed. Some of the most visited websites in the world today would have taken 10+ seconds to download on broadband standards of the early 2000’s. These standards are going to continue to change, and we’ll continue to demand more from our web apps as technology improves. It’s important that we scale our experience given the technology available to our users.

If we assume that a user is more accustomed to browsing the web from a desktop, we can use that experience as an “okay” benchmark for how long a user is willing to wait on a mobile device.

So, how long does the same website take to load on a standard mobile broadband speed compared to a basic broadband speed (4Mbps)? The table below details how the same five sites previously examined load their mobile counterparts.

Mobile Website Load Times

According to a study by PCWorld and Novarum Inc in 2009-2010, the avg. download speed between the AT&T, Sprint, T-Mobile, and Verizon 3G networks was 987Kbps. Some providers may throttle users that exceed a monthly data limit to significantly lower data rates (ie: T-Mobile reduces download speeds after customers reach a 5GB limit).

The mobile versions of these sites strive to minimize load time on mobile devices by drastically reducing their total weight. When you compare the results to the default site on a basic broadband connection, you’ll find that there is little difference.

Consider what would happen if Facebook didn’t have a mobile version of their site. How long would the load time be? How much of that load time would be wasted if the device used had a poor resolution? or if it lacked multi-touch ? While devices such as the the iPhone have done an outstanding job of building systems for zooming and panning traditional websites, other devices are still catching up. If users wait a long time for a website they ultimately can’t use, their experience is ruined.

The bottom line is that most Facebook users expect very quick load times on their desktops. Asking those same users to wait 11 seconds for a page to load is simply unacceptable.

Closing thoughts

And on that note, we’re going to close this part of our series. In part 2, we’ll discuss more specific design constraints, how to design for specific mobile devices, and other ways dimensions affect our choices when designing for handheld devices. Before I leave you, though, there are a few resources worth mentioning:

• While not strictly mobile-related, the FCC released a report in 2010 on the Status of Internet Access Services. The document contains lots of very insightful statistics in regards to how speed and access has changed over the past decade for residential users.
• I wasn’t able to find a dedicated calculate for finding page load times given certain connection speeds (if you have one, please leave it in the comments!). However, you can find out the total size of all files loaded on a website pretty easily with Firebug. Plug the total page size into one of the formulas above, and you can get a good idea of how long it should take to download all items on a page. Please note that this system does not take latency into account, so it should not be thought of as an accurate way to find the total time a page will take to load.

Continue to Part 2: Dimensions →