Are you making any of these 8 common (and wrong) assumptions about mobile performance?


I’m very excited to share that my first article for ACM Queue recently went live. It covers a number of best practices you should be considering when it comes to optimizing your pages for mobile devices.

Why should you care about mobile-specific optimization? In many ways, it’s a profoundly different beast than desktop optimization, yet many people still routinely make one or more of these incorrect assumptions:

Assumption 1: Mobile performance is still a side issue.

Now, in fairness, I haven’t heard anyone say this recently. Most site owners will state that mobile is important — and they probably believe what they’re saying. But there’s a disconnect between what people say and what they do. Despite the fact that, according to pretty much every analyst I follow, mobile usage is poised to overtake desktop usage by 2014, most of the site owners I talk to have not allocated optimization resources 50/50 across desktop and mobile.

Mobile usage will overtake desktop by 2014

Assumption 2: Mobile users expect poorer performance.

If you’ve been in the performance space for any period of time, you’ve probably encountered the statistic that 85% of mobile users expect pages to load as fast or faster than they load on the desktop.

Here’s the rub: if you’ve been in this space for any period of time, you’re probably not in that 85%, which makes it hard to buy into that stat. I’m right there with you. I always expect pages to take forever to load, even over wifi. (In fact, I’ve adopted a defensive browsing technique that involves queueing up my actions so that I hit the “enter” button, put my phone down, then feed the dog or get one of my kids a glass of water or any other task that takes 15-30 seconds to perform, and then I pick up the phone, hoping that the page has loaded.)

If you’re like me, it’s important to remember this: We’re the freaks. Normal people expect identical experiences across all their devices.

Assumption 3: Mobile users will stay on your m.site.

I’ve covered this here before, but it bears repeating: stripped-down
 m.sites are not an effective strategy for most site owners. Most simply aren’t up to the challenge of serving the rich, dynamic experience — not to mention the depth and breadth of content — that most users expect. This is why, according to research we conducted last fall, analyzing millions of ecommerce transactions, 35% of mobile users will choose to view the full site when given the option.

35% of mobile users choose the full site

These full-site visitors are also better customers than m.site visitors. We found that, for every $7.00 of mobile-generated revenue, $5.50 (almost 80%) was generated by mobile shoppers using the full site. Only $1.00 came via m.site, and $0.50 via the mobile app.

Assumption 4: Responsive web design will automatically make your pages faster.

Responsive websites are complex, and that complexity can come with a serious performance pricetag. Guy Podjarny wrote an excellent post on his blog explaining the challenges of building a fast responsive website. It’s not to say that it can’t be done — just that site owners need to be aware that RWD may make your pages look better on a variety of devices, but it doesn’t automatically make your pages load better on a variety of devices. It’s all about implementation.

Assumption 5: Mobile latency and desktop latency are identical.

In web performance circles, “latency” is the amount of time it takes for the host server to receive and process a request for a page object. The amount of latency depends largely on how far away the user is from the server.

Mobile latency is consistent only in its inconsistency, even when measured at the same location. This is due to a number of variables beyond the amount of data passing through the tower. As this graph shows, factors such as the weather, and even the direction the user is facing, can have a significant impact:

3G latency

In one study we performed a while back, median desktop latency ranged from 65-145 milliseconds, which isn’t great. Mobile fared even worse, with a median range of 90-190 milliseconds. What was especially significant was noting the longtail of outliers for mobile (below). Individually, outliers aren’t hugely significant, but when you see a tail this long, it represents a large number of people who are experiencing painful latency – in this case up to 990 milliseconds.

Mobile latency over 3G

 

 

 

 

 

As Ilya Grigorik stated at the recent Velocity conference, if you’re designing for mobile, it’s safe to assume you’re going to incur 2000ms of 3G latency.

Assumption 6: Your CDN will deliver the same acceleration benefits to your mobile visitors as it does to your desktop visitors.

CDNs are somewhat effective for mobile users, but it may be hard to rationalize the cost based on the marginal return. A while back, I wrote about a case study in which we stepped through a series of acceleration treatments on a page to measure the impact of each treatment for mobile users. When we added the CDN, we found that:

  • Doc complete time decreased by only 10%, compared to a 20% improvement we noted in a similar experiment in desktop optimization.
  • We shaved less than a second off start render time, taking it from 7.059 seconds down to 6.245 seconds.

So while there were performance gains, they were not hugely significant.

Assumption 7: Your mobile browser cache is the same as your desktop cache.

Leveraging the desktop cache to store page resources (such as images and CSS files) is a core performance best practice that allows pages to load faster throughout a user’s path through your site and on repeat views. I was surprised to learn recently that many people assume that the mobile browser cache functions in more or less the same way. Mobile browser caches
 are usually much smaller than on desktop machines, causing items to be flushed quickly — sometimes even within a couple of page clicks during the same visit. It’s possible to leverage the newish HTML localStorage specification as an alternative to relying on browser caching, but this isn’t a default. It has to be done manually or via an automated tool such as Radware’s FastView.

Assumption 8: 4G/LTE is a cure-all for mobile performance pains.

Last fall, we performed real-world performance testing of the same 200 leading ecommerce sites over 3G and LTE, and found that LTE was only 27% faster than 3G. This is a far cry from claims that LTE is, on average, 10 times faster.

And even if LTE were significantly faster, 3G isn’t going away any time soon. Count on it to be around until the ’20s. Consider it the network version of Internet Explorer 6.

Takeaway

Friends don’t let friends make assumptions about mobile performance. Chances are, you know someone who believes at least one of the above. Time to straighten them out. 🙂

Tammy Everts

As a former senior researcher, writer, and solution evangelist for Radware, Tammy Everts spent years researching the technical, business, and human factor sides of web/application performance. Before joining Radware, Tammy shared her research findings through countless blog posts, presentations, case studies, whitepapers, articles, reports, and infographics for Strangeloop Networks.

Contact Radware Sales

Our experts will answer your questions, assess your needs, and help you understand which products are best for your business.

Already a Customer?

We’re ready to help, whether you need support, additional services, or answers to your questions about our products and solutions.

Locations
Get Answers Now from KnowledgeBase
Get Free Online Product Training
Engage with Radware Technical Support
Join the Radware Customer Program

CyberPedia

An Online Encyclopedia Of Cyberattack and Cybersecurity Terms

CyberPedia
What is WAF?
What is DDoS?
Bot Detection
ARP Spoofing

Get Social

Connect with experts and join the conversation about Radware technologies.

Blog
Security Research Center