The Speed of the Mobile Web, Part 1: User Perception

Last week, Gomez published "Why the Mobile Web is Disappointing End-Users,” which you can read online at Scribd. In summary, huge numbers of users are reporting problems with the mobile web, with download time the number one problem.

While this seems simple, it really isn't. Consider my ongoing experience on my Nokia E71, on the AT&T network, in a non-impacted 3G area, using the highly optimized Google Reader (and I'm using the "mobile" version not the "iPhone" version, though the device supports both). I also use the same site in Opera Mini.

Typically it takes two tries before the native browser can find the page, and if I reload the page that is there Google errors out. Opera Mini is faster, but I have to tell it which network to use two or more times before I can load the page.

I just outlined problems with the browser, the network, the site, and the operating system/device. Each contributes to my slow experience. And most sophisticated users won't be able to distinguish these, let alone typical users.

Perception vs. reality

Before we get too focused on speed, consider some fascinating research by User Interface Engineering titled The Truth About Download Time. Don't get wound up in the age of the research; the conclusions are still true.

There are two paragraphs you really need to read:

... we found that there was no correlation between ... [actual download speeds] and the perceived speeds reported by our users. About.com, rated slowest by our users, was actually the fastest site (average: 8 seconds). Amazon.com, rated as one of the fastest sites by users, was really the slowest (average: 36 seconds).

There was still another surprising finding from our study: a strong correlation between perceived download time and whether users successfully completed their tasks on a site. There was, however, no correlation between actual download time and task success, causing us to discard our original hypothesis. It seems that, when people accomplish what they set out to do on a site, they perceive that site to be fast.

So. Perceived speed is not the same as actual speed.

This is undoubtedly the case for the Gomez study. How many users actually count seconds? Very few. So don't be overly concerned about times in the study. But do be concerned about how fast that people think the web is, as well as failure to accomplish goals.

What to do?

Let's avoid the finger pointing here. Everybody, at every step of the mobile web value chain, can increase the speed of the mobile web. Over the next four parts in this series, we'll look at what each of the different types of organizations can do. We'll make these links as each of these is published.

• Content providers
• Operators/carriers
• Manufacturers and operating system makers
• Browser makers

In the meantime, contribute your thoughts to the (currently very brief) Design for Mobile page on Mobile Web Speed.

Great post and a very nice overview about the mobile. Your post really helped me a lot to understand that why the mobile web is not very fast!
Thanks for sahring this useful information!
cheers

Yeap, yeap… Network speed is the top “missing link” today w.r.t. mobile web apps. Speed (really, latency) is the main issue behind dissatisfaction and why today mobile web is not better than local apps. (let me see if I get to finish a piece on this exact topic w.r.t. Chrome) And this latency issue is in my opinion a top reason why Google is working hard on Chrome as a “platform” that enables for local-app like characteristics for web apps that helps tackle this latency, speed and related perception problem for mobile web apps.

ceo