Mobile

Goodbye, unlimited mobile data plans. Hello, throttling. What does this mean for site owners?

Data consumption on cell networks is a huge problem that will only get exponentially worse. We’re barely seeing the beginning. In this post, I’m going to outline the problem, as well as the solution landscape as I see it.

Let’s start with some mind-boggling numbers:

  • According to a Cisco report, the number of mobile-only users is set to explode. In 2010, there were 14 million mobile-only users. That number is projected to grow to 788 million mobile-only users by 2015.
  • More from Cisco: last year’s mobile data traffic clocked in at 597 petabytes a month — eight times the size of the entire global Internet in 2000.
  • What are all those petabytes comprised of? A lot more than viewing “mobile-optimized” sites. People are using the full web (particularly social sites), downloading games and apps, streaming music, watching videos, using GPS, and playing online games.
  • In 2011, 31 million mobile consumers viewed mobile video. Mobile video traffic exceeded 50% of mobile bandwidth.
  • In 2011, 33% of Facebook’s traffic came from mobile, as did 55% of Twitter’s traffic and 60% of Pandora’s.

Think your 2 GB plan has you covered? Maybe — for now. But as we all get used to the idea of on-demand, on-the-fly content delivery, our expectations are growing. According to Nielsen, mobile data usage more than doubled in every single age group between 2010 and 2011. As a for-instance, the average 25-34 year old used 264 MB of data in Q3 2010. One year later, that number leaped to 578 MB.

And have you ever wondered what 1 MB gets you? In most cases, not very much:

Solutions

There are solutions. But there are no perfect one-shot solutions.

Solution 1: Consumers will educate themselves about their data usage.

Pro: There’s an app for that. Apps like Traffic Monitor and 3G Watchdog (both for Android) show data usage for every app on your device. I was talking to customer recently who told me that he uses one of these apps to monitor how much data individual sites are using, and he simply stops visiting the data hogs.

Con: However, I don’t believe most users will work to this extent to monitor their data usage. It’s not how we’re wired to consume media. Generations of consuming newspapers, books, radio, television, and the desktop internet have trained us to believe that we are entitled to an unlimited (and practically free) supply of information and entertainment.

Solution 2: Consumers will restrict their usage to wi-fi instead of their 2G/3G/4G network.

Pro: Mobile devices are like Jekyll and Hyde. On wi-fi they can use tons of bandwidth and it doesn’t matter. On 2G/3G/4G they can’t. Using a wi-fi hot spot doesn’t count toward your monthly data allotment from your service provider, because you’re basically making your data consumption someone else’s problem.

Con: The average mobile user doesn’t stare at their screen to figure out what mode they are in. And most wi-fi hot spots are unsecured, in order to make them accessible to users. Of course, there are lots of workarounds you can use to to secure your device and information, but to be frank, most users aren’t savvy enough to implement them.

Solution 3: Carriers will continue to impose data caps and throttle users who are identified as being high-bandwidth users.

Pro: From the perspective of the carriers, the numbers cited at the top of this post make a compelling argument for throttling. Sprint (the only national carrier that promises unthrottled, unlimited bandwidth) is going to be challenged to keep up its commitment.

Con: If you’ve even been throttled, you know how intensely, painfully slow it is. Pages that used to load in just a couple of seconds take a couple of minutes. It’s brutal. What’s more, it’s not a great long-term strategy for carriers. Right now, in most cases only the top 5% data users are being throttled. But as mentioned above, we’re all using more and more data. At some point, the average person’s usage is going to equal that of a power user. What’s the solution then? Throttling more and more users? At some point, something has to either give… or break.

Solution 4: Site owners will funnel users toward leaner mobile-optimized sites.

Pro: Modern websites are designed for big screens. They send images that are too high quality for mobile phones, and these big images bloat pages. Serving leaner, stripped-down pages to mobile users is a relatively easy way to deal with this problem.

Con: As I’ve said many times, this solution is deeply flawed. For one thing, mobile-optimized sites look terrible on a tablet, which is technically a mobile device. For another, users don’t want a stripped-down online experience. In fact, 1 out of 3 users will choose to visit the full site when presented with a mobile version.

Solution 5: Site owners will explore new technologies to solve the mobile bandwidth problem.

Pro: There’s no silver bullet to solving the mobile bandwidth problem. The real solution will actually be a combination of new solutions — including, yes, advanced front-end optimization solutions like Strangeloop’s, as well as mobile-specific content delivery networks and infrastructure investments.

Con: Site owners are going to have to shake off their laissez-faire attitude about their users’ bandwidth issues. Historically, end-user bandwidth limitations have never been something that site owners concerned themselves with. As far as they were concerned, if your at-home connection was too slow, it was your own problem. It was up to you to buy a better modem or find a better ISP. The mobile bandwidth dilemma, however, is everyone’s problem. Throttled users react to page slowdowns the same way any other web user does: they view fewer pages, they buy less, and they’re less happy with your site. Site owners will need to recognize this and, for the first time, take proactive steps to mitigate end-user bandwidth limits.

Related posts:

Web performance and the 2012 US election: Is site speed an early indicator of future success?

According to this Mashable post, Barack Obama and each of the Republican candidates’ all claim to be pretty pro-technology, with strong anti-SOPA and anti-PIPA stances. I wanted to see if this pro-tech stance extends to web performance, so I decided to take a shallow dive into their websites and mobile strategies. I was actually kind of surprised to see some interesting patterns emerge.

1. Website speed correlates (mostly) to position in the primaries.

When you stack these numbers side by side, you see a rough relationship between site speed and recent primary results. At 46.4% and 31.9%, respectively, Mitt Romney and Newt Gingrich led the Florida primary. Interestingly, both also lead when it came to site speed. Gingrich’s site is fastest, with a load time of 7.7 seconds (maybe we shouldn’t be so quick to laugh at his plans to colonize the moon), while Romney’s loaded in 9.3 seconds. Rick Santorum and Ron Paul lagged in both areas, trailing far behind in votes and suffering load times of 10.7 and 13.5 seconds, respectively. (Interesting to note: President Obama’s site fared worst of all, with a load time of 13.6 seconds.)

How fast did websites load for Republican candidates?2. None of the candidates’ sites rose to the challenge of designing for mobile devices.

At recent Velocity conferences and elsewhere online, I’ve emphasized that one-third of mobile users want to access a site’s full content, not just a stripped-down “mobile” version. At the same time, there’s no doubt that making a full site usable on a mobile device is a major challenge — a challenge that none of the candidates rose to. Romney is the only candidate to serve a mobile site, which, to his credit, did link to the full site. The other candidates all deliver their full websites to mobile.

Mitt Romney has a mobile-optimized website

Given how tech-savvy President Obama’s people were throughout his first campaign, it’s not surprising to see that, with his new campaign site, they’ve adopted responsive design principles. Depending on whom you ask, responsive design is the savior of cross-platform development. Done well, it allows content to adapt to a variety of devices — desktop, tablet, and smartphone — maintaining content and design integrity while respecting the constraints of the device. (Here’s a longer review of the President’s new site and whether or not it serves as a good example of responsive design in action. I didn’t experience all the problems the reviewer did, so I’m wondering if they’ve since been fixed.)

3. Mobile experiences ranged from poor to terrible on Android over 3G.

I visited each of the candidates’ sites using two mobile devices and networks: my iPhone over wifi, and a borrowed Android over 3G. While all the sites loaded within 10-20 seconds on my iPhone, their performance on the Android via 3G ranged from slow to unbearable. Romney’s site was fastest, at 21 seconds, but it failed to size properly (see below) in the browser. The full sites for Gingrich, Santorum, and Paul each took several minutes to load.

MittRomney.com - mobile-optimized site on an Android device

4. On every site, the primary call to action — donate — was either lost or ineffective for mobile users.

On all the non-optimized sites, the “Donate” button was lost on the screen. Romney’s mobile-optimized site made it easy to find the “Donate” button, but on the Android it kept generating an error message saying there was a problem with the security certificate — not something a potential donor wants to read right before handing over their credit card information.

Spot the call to action on these non-optimized pages

Why should web performance matter for presidential hopefuls? (Hint: It’s about democracy)

It’s one thing to tout your pro-technology stance to curry favor with voters, but there are a couple of obvious, self-serving reasons to walk the walk when it comes to your web presence: it makes it easier for you to reach more people, and it makes it easier for your supporters to, you know, support you. Candidates may not care about this beyond the lip-service stage right now, but a few things to bear in mind down the road, when campaigning really heats up:

  • 25% of Americans who have mobile devices use mobile exclusively. This means 1 out of every 4 voters expects to be able to access the full site via their device.
  • According to the source in the point above and to this report from Pew Research, many members of the mobile-only group are technology late adopters, skewing toward older people and those with lower incomes. These groups have traditionally been heavily targeted by Republican candidates.
  • By the same token, people with lower incomes are more likely to be users of Androids and non-iPhone devices, and more likely to access the internet via 3G.
  • Only 28% of smartphone owners use an iPhone, according to Nielsen. Having a mobile site optimized only for iPhone users is like slamming the door on almost three-quarters

Related posts:

Advanced Mobile Optimization: How does it work? How do we measure success? [slides]

It’s been a busy couple of weeks, but I finally got around to posting the slides from my talk about advanced mobile optimization at the San Francisco & Silicon Valley Web Performance Meetup.

I always enjoy coming to these Meetups, and this time was no exception. Thanks again to Aaron Kulick for inviting me, to LinkedIn for hosting, and to the extremely keen and knowledgeable crowd who turned out. :)

Related posts:

Interesting new findings about page views, time on site, and bounce rate across desktop and mobile browsers

Last month, I talked with Mac Slocum at O’Reilly Radar about mobile performance, and he asked me a couple of interesting question:

  • Are mobile users more or less tolerant of delays than desktop users?
  • Are users of one type of system more accepting of delays than users of another?

These questions are a gateway to a fascinating area of research, because they lead into a topic that we all have pet theories about (i.e. Chrome users are more tech savvy than the average person, while Internet Explorer users are less) but have little statistical evidence to back up.

I told Mac that I planned to do more digging and report back, so here I am.

Methodology

  1. I took five e-commerce sites (full sites, not mobile versions) that Strangeloop is currently accelerating and pulled their entire transaction volume over the past month — totaling hundreds of millions of unique visits via desktop and mobile. While desktop transactions outnumbered mobile transactions, the mobile numbers were still statistically significant: the smallest set of mobile numbers comprised around 200,000 unique visits and the largest set comprised about 20 million unique visits.
  2. I extracted the following data: page views, time on site, and bounce rate.
  3. I sorted the data into the following browser/OS groups: Internet Explorer, Firefox, Chrome, iPad, iPhone, and Android (phone).
  4. I calculated the averages for each metric and browser.
  5. I graphed the numbers and looked for trends. Some interesting patterns emerged:

Desktop vs. mobile performance: average pageviewsDesktop vs mobile performance: average time on siteDesktop vs mobile browser performance: average bounce rate

Three Key Findings

Finding #1: Internet Explorer users consistently view more pages, spend more time on site, and have a lower bounce rate than Firefox and Chrome users.

The average number of page views for IE users was 6.134, as opposed to 5.17 for Firefox users and 5.14 for Chrome users. IE users spent between 30-45 seconds longer on the site than other users, and their bounce rate was lower by 5 or 6 percentage points — a pretty significant difference. Could all of this substantiate the belief (among non-IE users, at least) that IE fans are less tech savvy and therefore slower and more ponderous web users than the rest of us? Or perhaps it’s a hardware issue — are IE users more likely to be using older systems with less processing power?

But what about that lower bounce rate? At around 35%, it’s a pretty strong number, especially compared to 41% for Firefox users and 42% for Chrome. A lower bounce rate generally signifies that people who come to your site find it relevant and worth sticking around to check out. Are IE users better searchers and more likely to arrive at the right destination, or are they simply more easily satisfied than other users?

Finding #2: iPad users are more similar to desktop users than they are to smartphone users.

While iPad users view somewhat fewer pages per visit than desktop users (4.54 versus 5.14, 5.17, and 6.13), their average time on site and bounce rate were commensurate with the desktop crowd. This isn’t a huge surprise. We know that most iPad users are browsing in the comfort of their home, and they consider their iPad to be more like a small laptop than an oversized phone. What’s interesting here is that, even though iPad performance lags behind desktop (it is a mobile device, after all, and it suffers from many of the same performance constraints as a smartphone: from low processor power to touchscreen lag), iPad users seem willing to stick around for a longer desktop-like experience.

Finding #3: iPhone users consistently view fewer pages, spend less time on site, and have a higher bounce rate.

At the opposite end of the spectrum from Internet Explorer users we find iPhone users. In every sample group, iPhone users, on average, spent significantly less time on site (2:31 vs 3:20) and viewed fewer pages (2.41 vs 3.1) than Android, and had a higher bounce rate (60.76% vs 57.17%). The shorter time spent on site could be attributed to the (arguable) fact that iPhones are better-powered than other devices, but that doesn’t account for the page views and bounce rate. Do these validate all the stereotypes about iPhone users: that they — or should I say, we — are impatient, savvy web users who will bounce from a site if we can’t find what we want right away and aggressively search elsewhere? Or that we know what we want and can expedite a transaction faster and more efficiently than other users?

Takeaways

This research doesn’t directly answer Mac’s questions, but it does come at them sideways and raise some interesting — to me, anyway — questions about the types of people who use different technologies, and how and why they use them. We can’t answer these questions today, but these findings are food for thought and debate.

Your thoughts?

Related posts:

When it comes to mobile development, does bandwidth still matter?

If you work in mobile development, there’s a good chance you already have a strong opinion about responsive design. (If you don’t already have a strong opinion, that will probably change by the end of this year. As buzz phrases go, “responsive design” could be the “cloud computing” of 2012.)

Given all this, I couldn’t not respond to this post about responsive design written by Joaquin Lippincott, president of Metal Toad Media: When It Comes to Mobile Development, Stop Worrying about Bandwidth. He makes some good points about the fact that some responsive design techniques — such as swapping out images for CSS3, and using other CSS3 techniques like gradients and transparencies — are processor-intensive, meaning that while they may deliver superior performance, they can be tough on your device’s CPU.

But this statement stopped me in my tracks:

When it comes to building websites in 2012, bandwidth truly doesn’t matter. [emphasis mine] And it’s going to matter even less in 2013 with the roll out of more 4G networks. Additionally many devices are often on wi-fi, so provider network speed is truly a non-issue. Even on 3G, bandwidth isn’t a big deal – we’re streaming HD video, so don’t sweat 20k images.

To say that bandwidth seriously doesn’t matter, in any context, is obvious bait for any performance geek. True, a growing number of mobile users are browsing via tablets at home over their wifi connection, but this shouldn’t distract us from the fact that mobile use is growing across the board, which means that the total number of people connecting over 3G and 4G is still increasing. And any mobile user who is sensitive to their data cap — and to those monthly bills from their telecom provider — will tell you that, for them, bandwidth truly does still matter.

Not surprisingly, there were comments from a few performance geeks at the end of the post, which ultimately led to Joaquin clarifying his point to mean that developers and designers need to balance the trade-offs between bandwidth and CPU load.

While I think that anyone who builds sites for a living gets the fact that speed is an important usability issue (or as I prefer to put it: speed is THE important usability issue), I hear alarm bells when I hear people casually toss off statements like “bandwidth doesn’t matter”. To me, this post demonstrates the wide gap that still exists between design and performance. It also makes me wonder what kinds of conversations are happening out there between digital media agencies and their clients, who might not have the technical background to understand the nuances of what’s being discussed.

Your thoughts on juggling responsive design and mobile performance? I’d love to hear stories from the trenches.

Related posts: