Simplify your job search
Get 5+ job offers from top companies with 1 application
Get job offers

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
Considerations for Mobile Design: Speed

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.

The choice of what specific site a user chooses to use is heavily influenced by how quicly a site allows them to accomplish a goal.

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.

Between  2005 & 2009, the number of mobile devices with connection speeds over 200kbps increased by nearly 4000x.

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

Website Page Size 256Kbps (32KBps) Download Rate 4Mbps (512KBps) Download Rate 1.07MB 34.2 seconds 2.1 seconds 264.37KB 8.2 seconds .5 seconds 193.49KB 6 seconds .4 seconds 400.42KB 12.5 seconds .8 seconds 360.6KB 11.3 seconds .7 seconds

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

Website Page Size 256Kbps (32KBps) Download Rate 987Kbps (123KBps) Download Rate 77.95KB 2.6 seconds .6 seconds 36KB 1.2 seconds .3 seconds 31.14KB 1 second .3 seconds 21.76KB .7 seconds .2 seconds 17.4KB .6 seconds .1 second

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 →


  • Luke Hinchliffe Reply

    Excellent article and analysis. Especially useful to see the download time site comparison tables. Look forward to part 2!

  • Jack Reply

    I always love it when sites that talk about mobile design don’t have a mobile version :)

    • David Leggett Reply

      Heheh :) We’re working on one for UX Booth actually. It’s something we’re excited about.

      It wasn’t a goal of ours to accommodate mobile users when we were building the current design. We’re starting to see quite a bit more mobile traffic now.

    • Matthew Kammerer Reply

      I add to what David said, I think it’s important to devote your resources to where your users are. For example, we also did not optimize for IE since less than 4% of our users view in IE. When you can’t be good at everything you try to be the best at what’s most important :).

    • Jacob Creech Reply

      Interesting to see your numbers there for IE – currently around 7% for us, which is broadly similar to our number of mobile viewers.

      Curious to know what your mobile percentages are like, and when can we expect to see a mobile version of UXBooth?

      Oh, and really love the article. Thanks David.

    • David Leggett Reply

      Maybe a post regarding UXB specific user capability details (summarized annually) would be an interesting writeup sometime… We’ll see what we can do about that!

      Our mobile user base is still pretty small, but growing quickly. We’re aiming for a mobile version of the site with the release of our next redesign.

      Thanks Jacob :)

  • Bobby Burdette Reply

    Great article.. very timely for some of the current work i’m on… will be looking forward to part 2.

  • Tim Reply

    I love that you kicked off your mobile series with a post on performance – such an incredibly important topic!

    That being said, I did want to make one minor correction.

    “typical load time for a web page in 2010 was under 1 second.”

    I’m afraid that paints a far rosier picture of the state of performance than is actually the case.

    Urs Hölzle, Google’s Senior Vice President of Operation, stated in his Lenore at Velocity last year that the average page size is indeed 320KB. He also states that the average bandwidth was 1.8 Mbps. That should equate to about 1.4s page load, but the average page load time was a brutal 4.9 seconds.

    Why? Because the average site uses 44 resources, makes 7 DNS lookups and doesn’t compress a third of it’s content.

    I know you said you weren’t going to get into how to optimize, but I just wanted to point out that filesize is not enough and that it’s a bit dangerous to estimate load time based on ideal speeds.

    • Tim Reply

      And of course by ‘Lenore’ what I actually meant was ‘lecture’.

      Foiled by auto correct yet again.

    • David Leggett Reply

      That’s exactly right Tim. This is something Andrew Maier has explored in his post “How to Minimize Load Times for Fast User Experiences”, but I failed to really point out in this post.

      Also important: Latency on mobile devices tends to be a bit more sluggish than most basic broadband connections. Factor latency, slower speeds, and high request numbers together, and you have a recipe for disaster on mobile devices!

      Thanks for the insight sir :)

  • Nico Reply

    The units of measurement are incorrect. A kilobit (nowadays) is 1000 bit (not 1024 bit), so 125 bytes (assuming 8-bit bytes).
    Although in computing kilo is often used with a meaning of 1024, this will not be the case for most advertised data-connection speeds, simply because when using the correct meaning of kilo(bit/byte) companies can publish a higher Kbps value.

  • Roy Reply

    I recently worked for a global mobile services provider. They built a mobile version of their website (obviously ;) ). However the site seemed slow. The IT geeks implemented things like Steve Souder’s High Performance Web Sites, but the site did not speed up. It turned out the problem was the rendering/ power of the handsets (most mobile handsets for web browsing are not iPhone or Android).

    It’s important to know what is actually causing the problem rather than assuming, and in the mobile world it may well be the ‘lightweight’ design.

    Thanks for the article.

    • David Leggett Reply

      That’s an excellent point Roy. No time was spent in this article addressing device hardware capability.

      This isn’t something I actually plan on covering in this series. I wonder if there are any useful resources that go into depth on the implications of design based on processing power/memory/etc. Also, while it would certainly change depending on the site, I wonder if there is a correlation between mobile web users and the type of device being used. I have no data backing this, but I would assume that the vast majority of people browsing are running higher-end devices with more powerful hardware.

      A lot more to think about, thanks!

  • Drupal webdesigner Reply

    Thanks for this great insight in to the pagespeed of mobile and normal website today.

    Were working on a mobile website for a client, so the information is very welcom.

Leave a Comment on This Article