mobile web performance

The 27 best web performance links of Q1 2012

12 Apr 2012

3 Comments

This week, I had a chance to go through the latest links added to Strangeloop’s WPO Hub, and as always, I’m impressed by the breadth and depth of the topics covered. There are a lot of smart people in our industry.

A few things I noted in the first quarter of 2012:

  • We saw a lot of jockeying for performance dominance and audience dominance among browsers, indicating that the war isn’t over yet. This is great news for all of us — from users to site owners.
  • Our understanding of issues that affect mobile performance and third-party performance — topics that most of us were ignorant of just a couple of years ago — is increasingly nuanced.
  • More and more, we’re seeing mainstream coverage of web performance, signalling that this topic has permanently entered the public spotlight. It definitely makes my job easier. :)

Mainstream coverage

For Impatient Web Users, an Eye Blink Is Just Too Long to Wait
Really great piece in the New York Times about Google’s research into the neuroscience behind perceived page speed. Excerpt: ”Remember when you were willing to wait a few seconds for a computer to respond to a click on a Web site or a tap on a keyboard? These days, even 400 milliseconds — literally the blink of an eye — is too long, as Google engineers have discovered. That barely perceptible delay causes people to search less.”

How One Second Could Cost Amazon $1.6 Billion in Sales
Fast Company published this piece about our (lack of) tolerance for wait times in general, and about page speed in particular. Among other things, they cite the stat that one in four people abandons a page if it takes longer than four seconds to load.

Webpages showing sharp growth in girth
This was a fun example of the trickle-up process in action. On December 20th, I predicted that the average web page would hit 1MB in 2012. On December 21st, GigaOM picked it up. On December 22nd, it showed up on BBC News. I love the internet.

Think Quarterly: The Speed Issue
Google’s “Think Quarterly” isn’t exactly a mainstream publication, though it’s pretty widely read in the tech community, but I’m including this link here because I love the broad approach — ranging from technical to philosophical — of this particular issue, which is dedicated to the idea of speed. It includes articles by Urs Hoelzle, Kristen Gil, Jeff Jarvis, and Tjaco Walvis. Definitely a must-read.

Browsers

Which Browsers are the Fastest?
Interesting study from New Relic. Key findings were that, while IE 9 outperforms other browsers on Windows, Chrome 13 on Mac was overall the fastest experience (2.4 seconds). In mobile speed tests, the fastest experience was on Blackberry Opera Mini (2.6 seconds), twice as fast as Safari 5.1 on iPad.

Internet Explorer market share surges, as IE 9 wins hearts and minds
Summary: ”The browser wars are back on in earnest. For the second time in three months, Internet Explorer made large gains, picking up almost 1 point of market share. Chrome, Firefox, and Safari all lost out, as Internet Explorer 9 won over new users.”

Browser Speed Tests: Chrome 17, Firefox 10, Internet Explorer 9, and Opera 11.61
As always, the latest round of Lifehacker browser speed tests generated some interesting results. Overall, Chrome was the winner, but the tests crossed a lot of parameters, and each browser had its strengths. Definitely worth checking out, especially if you’re new to understanding the nuances of browser performance.

Internet Explorer Performance Lab: reliably measuring browser performance
The MSDN blog offers a detailed look behind the scenes at the IE Performance Lab. Be sure to check out the comments, too.

Chrome Fast for Android
A must-read if you care about mobile web performance: Google engineer Tony Gentilcore’s top 10 Chrome for Android speed features.

Chrome 16 – World’s Most Popular Browser
Interesting observation from Google engineer Mike Belshe: In January 2012, Chrome 16 quietly became the world’s most popular browser.

Case studies and other research

Just One Second Delay In Page-Load Can Cause 7% Loss In Customer Conversions
The folks at TagMan partnered with the UK’s leading glasses e-tailor, Glasses Direct, to study page speed and conversion behavior. Their findings substantiated Aberdeen’s 2009 findings, in which slower page load times correlated with a 7% drop in conversion rate.

Real User Monitoring at Walmart.com
Cliff Crocker, Aaron Kulick, and Balaji Ram joined forces at a meeting of the SF Web Performance Meetup to tell a RUM (real user monitoring) story through the lens of three job functions at Walmart.com: the performance data analyst, the developer, and the business analyst. Some excellent slides demonstrating the business value of performance. (I featured my four favourite slides in this post.)

The Performance Golden Rule
Excellent post from Steve Souders. He revisits his six-year-old stat about where end-user response time happens and confirms that 76-92% still happens at the front end. I really love this kind of post. In our industry, it’s crucial to keep revisiting these kinds of numbers and testing our assumptions.

The Need for Speed
Great case study for web performance geeks: How Chemeo delivers “pure bounce with pure value”.

No framework needed
Nice case study from 37signals about how they shaved 500ms from a page and got a 5% conversion bump.

January 2012 Site Performance Report
It’s great to trumpet success stories, but we learn as much by talking about what’s not working as by talking about what is.  This report card — in which the team at Wayfair shares how they suffered page slowdowns of up to 370% —  is a good reminder that optimization is a neverending task.

When good back-ends go bad
In this post for the annual Performance Advent Calendar, Pat Meenan talks about the fact that, while the back end is only responsible for 10-20% of response time, when it goes wrong, it can really go wrong. Among other things, Pat shares his findings that ”It is not uncommon to see 8-20s back-end times from virtually all of the different CMS systems.” Ouch.

Mobile

M-commerce site performance hampered by Verizon
Not exactly news, but still a good reminder from Internet Retailer that you’re at the mercy of networks when it comes to mobile performance: “The load times for virtually all of the 30 retailers on the Keynote Mobile Commerce Performance Index for the week ending Feb. 12 were negatively affected by a dip in performance on the Verizon wireless network.”

Mobile UI performance considerations
More goodness from the Performance Advent Calendar. If you’re just starting out with mobile web performance and don’t know where to begin, this post by Estelle Weyl is a good place to start. You should also check out her session slides from Velocity EU.

Tips and how-tos

Web Font Performance: Weighing @font-face Options and Alternatives
Nice collection of tips for making sure your web fonts aren’t slowing down your pages.

Timing the Web
Still more Advent Calendar goodness. dynaTrace technology strategist Alois Reitbauer explains how to use navigation timing to measure page load time.

Third parties

3rd Party Providers and DNS Poisoning Risks
Here’s a topic that doesn’t get talked about enough, via the Catchpoint blog: ”DNS cache poisoning refers to data breach, whereby new DNS records are introduced in the DNS Cache of a resolver or computer and divert traffic to a different IP address. The cache poisoning can be caused by hackers trying to divert traffic to a phishing/malware sites or it could be a configuration mistake. In either case the end result is not good for end users – they will end up accessing the wrong site or not access your site at all.”

Are External Services Slowing You Down? New Relic Infographic Reveals the Fastest and Most Popular External APIs
More research (with infographics) from New Relic, this time showing the four fastest 3rd-party APIs among the 200,000+ applications the company monitors.

Tools

Welcome YSlow Open Source
Yahoo has released the source code for YSlow under the BSD Open Source license. They’re encouraging devs to “use the source code, learn how it works, fork it to make your own projects and enhance it with new rules, features, and whatever will improve this tool we all love.”

Google: SPDY Gaining Adoption
Article in Web Pro News about the fact that SPDY is gaining support among browsers, developers, and vendors: “Recently, Firefox has added SPDY support, which means that soon half of the browsers in use will support SPDY. On the server front, nginx has announced plans to implement SPDY, and we’re actively working on a full featuredmod-spdy for Apache. In addition, Strangeloop, Amazon, and Cotendo have all announced that they’ve been using SPDY.”

Introducing mod_spdy, a SPDY module for the Apache HTTP server
Google engineers Matthew Steele and Bryan McQuade break down how Google’s mod_spdy for Apache works.

The Biggest Misconception about Google Page Speed
Really interesting findings from Catchpoint: “There is no correlation between Page Speed Score and how fast a page loads.” This corroborates our own findings here at Strangeloop. A while back, I was talking about this with Pat Meenan, and a probable reason for the drop is because the newest version of Page Speed checks for more optimizations, which has resulted in lower scores across the board. It’s also important to know that Page Speed doesn’t take into account advanced front-end content optimization techniques — nor could it, because there are way too many of them to track and measure. As a for-instance, we’ve had experiences here at Strangeloop where we’ve taken a page with a perfect Page Speed score, accelerated it with Site Optimizer, cut load time in half, and ended up with a new Page Speed score of 74%.

And finally, a shameless plug for Strangeloop’s annual performance state of the union, which came out in January. We tested the top 2,000 Alexa-ranked retail sites and analyzed the results against our findings from the previous year. Among other things, we found that the average e-commerce website takes 10 seconds to load, web pages are getting bigger, and Internet Explorer 9 outperforms other browsers.

If you have any other links to share, let me know in the comments. And if you’re looking for more great links, we have hundreds — sorted by topic, industry, and type — over in the Strangeloop WPO Hub.

Related links:

By: Tammy Everts Category: Tags: , , , , , , , , , , ,

Latency reality check: Early findings show that desktop latency ranges from 65-145ms

2 Apr 2012

12 Comments

Last year, we here at Strangeloop conducted an in-house research project in which we determined that 97% of mobile end-user response time happens at the front end. We did this by digging into our customers’ beacon data and analyzing millions of unique transactions.

At the time, I mentioned that I planned to conduct a similar project to identify typical latency for mobile users versus desktop users. We recently completed our research, and the results were surprising. While we expected mobile latency to be high (last fall, some ad hoc research led to the realization that latency can hit 350ms on 3G), we also expected latency for desktop users to be relatively low — and this was not the case.

(If you’re a newcomer to the web performance scene, here’s a short primer describing what latency is, why it’s a problem, and a few common solutions.)

Methodology

  1. We took latency measurements for three US-based Strangeloop customers for discrete periods of time between February 15, 2012 and March 15, 2012. Each site uses a different content delivery network (CDN). Latency measurements were performed once per visit. We measured a total of three million unique visits.
  2. While we tested across all mobile and desktop browsers, the results for Internet Explorer are not included, due to some incompatibilities with the latency measurement process. The browsers included in the results are Firefox, Chrome, Safari, and any others that were able to run the test JavaScript.
  3. Desktop and mobile results were each aggregated and graphed for each site.

Results

Check out the histograms depicting the latency spread for each site. Medians are highlighted.

Site #1: Desktop browsers

Desktop latency: site #1

Site #1: Mobile browsers

Mobile latency: site #1

Site #2: Desktop browsers

Desktop latency: site #2

Site #2: Mobile browsers

Mobile latency: site #2

Site #3: Desktop browsers

Desktop latency: site #3

Site #3: Mobile browsers

Mobile latency: site #3

Observations

1. Desktop latency was worse than expected.

Median desktop latency ranged from 65ms to 145ms. My experience is that people tend to lowball their latency predictions for their own sites, estimating numbers in the 20-30ms range. If you do this, these numbers should make you think again.

I can’t stress this often enough: If you rely on your backbone tests to understand your site’s performance, you’re not getting an accurate view of your site’s true latency issues. Even 20-30ms is on the incredibly optimistic end of the real-world spectrum. Numbers like 76ms and 138ms are a lot more realistic. If you’re being told that your site experiences numbers below 20ms, you’re getting bad information.

2. Median mobile latency was between 26% to 96% poorer than desktop.

There’s been a spate of reports lately citing the fact that mobile users are using devices over their wifi connections at home. As a result, I’ve heard more than one web dev/design person say that this takes some of the heat off of optimizing for mobile — a dangerous opinion, in my mind. Median latency of 190ms is a serious performance hit.

3. The CDN you pick really matters.

Further to the above, the CDN you choose makes a big difference. Each of the sites we measured is on a different CDN, and as you can see, desktop latency was almost doubled from one site to another.

4. Outliers for mobile had double the latency of desktop outliers.

Check out the long tail of outliers for mobile. 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 990ms. That’s almost a full second for EVERY page resource. Even if you’re maxing out the browser’s ability to make concurrent connections, those nigh-seconds add up fast.

5. Mobile traffic accounted for about 10% of total traffic.

As an interesting aside, we found this number held across all three sites. Note that these were mobile users who were visiting the full site, not an m.site.

Conclusions

While the sample size of three sites isn’t large enough to draw a sweeping, industry-wide conclusion, the number of visits measured — three million in total — is still significant enough to draw some meaningful conclusions.

Latency is hard to get a bead on. It’s all too easy to ignore your site’s latency issues if you assume that your site is at the fastest end of the latency spectrum, or if you assume your CDN is a catch-all solution, or if you rely on backbone tests for your performance measurement. If you’re in the habit of doing any of these things, these findings should give you pause and encourage you to perform this kind of testing on your own pages.

As a further area of study, I’m interested in looking at the wifi versus 3/4G latency numbers, as well as the latency breakdown by device. If you have any suggestions for ways to cut and slice this data, let me know.

If you have any questions about how you can replicate our latency measurement tests on your own site, ask away. I’ll be happy to help.

Related links:

By: Tammy Everts Category: Tags: , , , , , , ,

World Series of web speed: Are online ticketing agencies ready for Opening Day?

26 Mar 2012

1 Comment

With Opening Day just around the corner, I thought it would be interesting to take a look at how some of the major online ticketing agencies perform. I got a few surprises. While a couple of sites offered a fairly speedy transaction experience, most were slow, and I was surprised to see which ones were slowest. But my biggest takeaway is that none of these sites are ready for the massive growth in mobile ticket purchasing that’s just around the corner.

Methodology

  1. Targeted 9 ticketing sites, ranging from smaller agents like FindTicketsFast.com to Ticketmaster and the official MLB.com site.
  2. Used Webpagetest.org to test the load time of each page in a transaction (ordering tickets for the same Rays vs. Red Sox game) up to, but not including, completing the purchase, as it would appear to a visitor using Internet Explorer 8. (Note that I used a custom script for running the tests, which took caching into account for each page of the transaction flow.)
  3. Calculated the total transaction time for each site.
  4. Took a deeper look at the numbers and individual test results to see if there were any trends.

Results

Transaction times: MLB ticket sites

Observation #1: Most transactions were slow.

While a couple of sites – Cheap MLB Tickets and Find Tickets Fast – had relatively fast total transaction times (12.08 and 15.03 seconds, respectively), the rest were much slower, with transaction flows ranging from 19.01 seconds to 43.37 seconds.

The average load time for all transaction pages across all the sites was 5.85 seconds. This might not sound like much, but as I regularly remind people, more than half of online shoppers will abandon a page after 3 seconds.

Observation #2: The official MLB site and Ticketmaster offered the slowest user experience — by a large margin.

I assumed these two sites would be among the fastest, but in fact Ticketmaster and MLB.com were by far the slowest, with total transaction times of 39.67 and 43.37 seconds respectively.

Looking at the test results, it’s easy to see why these transactions took so long. Over the course of the MLB.com transaction, there were a total of 636 page requests – content like images and third-party scripts that have to travel from the servers to the user before the page can render. MLB.com is pretty graphics intensive, so a lot of that content is individual image files. But when you look at waterfall charts for the site, you can see dozens of JavaScript and CSS files that are preventing visible content from loading. This is the kind of content you should defer or have load asynchronously to give your pages a huge performance boost right out of the gate.

Observation #3: The average transaction took five pages, not including checkout.

The number of pages in each transaction varied from four to six. From a usability perspective, this is a significant amount of friction. We know that the fewer pages in a transaction, the higher the number of visitors who convert (make a purchase, download an app, etc.).

There’s a reason why Amazon initiated one-click checkout a while back. They know that getting shoppers through the sales funnel faster leads to higher conversion rates, greater order value, and better customer satisfaction. To illustrate, there’s a case study that came out a few years ago that showed how one e-commerce site eliminated just one page in an online transaction and dropped their transaction abandonment rate from 45% to 33%.

Observation #4: For a fast ticket-buying experience, eBay is a solid bet.

I chatted with Sam Laird at Mashable about these results (read his subsequent post here), and he wondered how fast it would be to buy the same tickets on eBay. A few tests later and we have the number: 12.2 seconds, making eBay among the fastest options.

Observation #5: If these transactions are slow for desktop users, they’re even worse for mobile users.

These findings have huge ramifications for mobile consumers. A page that takes 15 seconds to load on your desktop could take a minute or longer to load on your smartphone, depending on your device and connection. Or worse, the transaction could end in an error message, which is what happened when I tried to time the MLB.com transaction on my iPhone:

Device/connection Transaction time
iPhone 4GS (3G network) 46 seconds (ended in error)
iPad (wifi) 62 seconds

 

MLB.com iPhone error page

Mobile ticket buying is already a big industry, and it’s only going to get bigger:

Should giants like Ticketmaster be running scared from smaller, faster ticketing agents like Cheap MLB Tickets?

In the short run, no. But in the long run, as the mobile ticketing market matures and consumers conduct more and more transactions via smartphone, those people aren’t going to wait minutes for each page in a 5-page transaction to load.

Some would argue that apps are the answer to these problems, and this is somewhat true, but only for power users. Mobile shoppers still use the web more than apps, according to a recent Nielsen study. While apps will continue to be popular, it’s incredibly short-sighted to think they’re a cure-all for performance.

Related posts:

By: Tammy Everts Category: Tags: , , , , , , ,

Our need for web speed: It’s about neuroscience, not entitlement

21 Mar 2012

18 Comments

It was inevitable.

In the past couple of weeks, web performance has gotten a lot of mainstream attention. The New York Times published an excellent piece about why 250 milliseconds is enough to give a site an advantage over its competitors. Mashable featured a set of infographics showing, among other things, that one in four internet users abandon a page that takes more than 4 seconds to load. And Fast Company dove a little deeper into these infographics in their coverage, focusing on stats like the fact that a 1-second page slowdown could cost Amazon $1.6 billion in sales each year.

Any time an idea goes mainstream, there’s always a backlash. It’s no surprise, then, that web performance has attracted some naysayers. When you read some of these articles, there’s a recurring theme in the reader comments, ranging from the cranky…

People can’t stand to wait anymore for anything. Now it’s milliseconds that drive people nuts. To quote a certain big, tough TV star of years past, “I pity these fools”.

To the zen…

Nobody likes to wait. Yet patience is an inner order, a form of power that needs developing, nurturing, sustaining.

To the really cranky…

Oh… pity the hyper-impatient web generation. Such busy lives with so many important things to do — like post the latest drivel onto their Facebook pages or download the You Tube viral video of the day. Oops sorry — of the minute.

In short, some folks are saying that we should suck it up and be happy with the web speed we have. I’m all for developing patience and other inner virtues, but it’s not that simple.

In his comment on this post, Michael Howell summed up the situation precisely:

Why oh why are these sites being flooded with people complaining about sites taking minutes to load, and others decrying the downfall of patience? This is about neuroscience and rhythm, not entitlement and overt frustration.

The human factors side of web performance is one of my favourite topics. It seems like a good time to give an overview of exactly why we crave faster pages.

Slow pages cause “web stress”: increased agitation and poorer concentration

A 2010 study at Glasgow Caledonian University found that slowing down web pages during an online transaction led to increased agitation and poorer concentration in the study’s participants. The participants wore an EEG (electroencephalography) cap to monitor their brain wave activity. The experiment also used EOG (electrooculograph) technology to track eye movements and facial muscle movements. Participants completed tasks using either a 5Mb web connection, or a connection that had been artificially throttled to 2Mb.

Brain wave analysis from the experiment revealed that participants had to concentrate up to 50% more when using badly performing websites. EOG technology and behavioral analysis of the subjects also revealed greater agitation and stress in these periods.

Why the stress? Basically, it’s because our short-term memory sucks.

Usability guru Jakob Nielsen states that human responses to poor load times is, in a large part, due to our poor short-term memory. Information stored in our short-term memory decays quickly, which is why we don’t perform as well when we have to wait, even for just a few seconds. And after 10 seconds? You can pretty much forget about it. Literally.

Jakob Nielsen - acceptable website response times

But why is this? This is where things get really interesting.

At any given moment, there are three basic types of memory processing at work in your brain:

  • Sensory memory
  • Short-term memory
  • Working memory

There’s also long-term memory, but it doesn’t really come into play here. So first up, let’s look at sensory memory…

Sensory memory: Your occipital lobe (AKA “the memory store”) works in 100ms bursts.

Every time you see something, this visual information is taken in by photoreceptor cells in your eyes and then sent to the occipital lobe in your brain. This is called the “iconic memory”, which is just one of our three types of sensory memories. (The other two govern sound and touch.)

People have been studying how iconic memory works for almost 300 years. In one of the earliest studies, performed in 1740, a glowing coal was attached to a cart wheel and the wheel was rotated faster and faster until observers perceived an unbroken circle of light. The study concluded that the glowing coal had to perform a complete cycle in 100 milliseconds or less in order to achieve persistence of vision. After 100 milliseconds, the “memory store” runs out. This number has remained fairly consistent throughout the centuries.

Interestingly, and not coincidentally, 100 milliseconds is Google’s stated goal when it comes to page load times.

We have no control over how our sensory memory works.

Iconic memory, along with the other sensory memories, is primitive. We can’t consciously choose what information is stored in our iconic memory, and we can’t will it to last longer. If we could, we’d probably go crazy or accidentally walk in front of a bus. Some sensory memory does stick, of course, provided it’s used quickly and eventually consolidated into the long-term memory.

Short-term memory and working memory: Working together to keep you from walking in front of a bus.

If our sensory memory’s role is to provide comprehensive information on our entire sensory experience, it’s our short-term memory’s job to extract the relevant bits and throw them into the hopper of our working memory. Your short-term memory can store information for 10-15 seconds, at most, enough time for your working memory to process, manipulate, and control it.

So the goal in getting page load times down to 100 millisecond is to keep information from falling through the cracks in our iconic memory, while also giving our short-term and working memory ample time to do all the parsing they need to do before they start losing information.

This is where we get into the idea of “flow”.

Flow: We’re hard-wired to perform tasks seamlessly.

Human beings have evolved to perform actions in beautiful, sequential flows. For hundreds of thousands of years, our day-to-day tasks — building a fire, hunting antelope, baking bread, milking a cow — have been a series of minute actions that flow more or less seamlessly into the next. This is hard-wired. It’s only in the past 40 or so years that we’ve imposed an entirely new way of processing information on our unsuspecting brains. And simply put: we aren’t wired to deal with the fits and starts of human-computer interaction.

“The doorway effect”: Why walking through doors makes us forget, and why this is analogous to using the web.

On the topic of flow, there’s an interesting article in Scientific American about why walking through a doorway makes us more forgetful. If you’ve ever walked into a room to do something, only to forget what you were there to do, you’ll find this interesting. It’s also relevant to online navigation, in my opinion.

A team of researchers tested their hypothesis using “rooms” in computer games, virtual environments, and real-world environments, and found that the results were consistent: our memories are worse when we enter a new environment through a doorway. They call this, logically, “the doorway effect” and the Scientific American article sums it up pretty well:

“…some forms of memory seem to be optimized to keep information ready-to-hand until its shelf life expires, and then purge that information in favor of new stuff. Radvansky and colleagues call this sort of memory representation an “event model,” and propose that walking through a doorway is a good time to purge your event models because whatever happened in the old room is likely to become less relevant now that you have changed venues. That thing in the box? Oh, that’s from what I was doing before I got here; we can forget all about that. Other changes may induce a purge as well: A friend knocks on the door, you finish the task you were working on, or your computer battery runs down and you have to plug in to recharge.”

The noteworthy aspect of this study is that the doorway effect persists in computer simulations. The act of going from virtual room to room is directly analogous to the act of navigating from page to page. It’s easy to conclude that the visual stimulus of watching a page refresh could purge the previous page’s “event model”.

Conclusion: In an increasingly networked world, we have two choices.

  1. We can speed up the web.
  2. We can speed up evolution.

Which sounds easier?

Related posts:

By: Tammy Everts Category: Tags: , , ,

Can the new iPad deliver on its performance promise? Five things to consider before answering that question

7 Mar 2012

1 Comment

Speed matters, and the folks at Apple know this. The new iPad 3 is expected to deliver faster performance via a (rumored) boosted Apple A5X mobile processor. As reported by Tech Crunch, “Apple states that the A5 SoC is ‘twice as fast’ as the Tegra 3 and the A5X offers ‘four times the performance.’”

But at the end of the day, it’s still a mobile device, hampered by many of the same constraints as smartphones, from battery power management to touchscreen lag to flaky browser cache. It’s also hampered by fast-growing user expectations. The average tablet user doesn’t think of their device as being a big-screen smartphone. Instead, they view it as a leaner, meaner laptop.

So the big question is: Out in the real world, can the new iPad truly deliver a satisfyingly fast user experience? It’s not a simple question to answer.

A few things to consider when you think about the iPad and performance:

1. iPad users are more similar to desktop users than they are to smartphone users.

In January, I dug into data spanning hundreds of millions of desktop and mobile transactions and found that iPad users are more similar to desktop users than they are to mobile users.

Desktop vs mobile browser: boounce rateWhile 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. Not a huge surprise. What’s interesting here is that, even though iPad performance lags behind desktop, iPad users seem willing to stick around for a longer desktop-like experience.

2. When sites are really slow, iPad users are as impatient as smartphone users. But when sites are really fast, iPad users are less impatient than smartphone users.

This is a really interesting dichotomy. Here’s an animated slide I created for Velocity EU last fall to illustrate this pattern in iPad users versus iPhone and Android users:

When things are really slow (as in page loads of 20+ seconds), iPad users bounce at about the same rate as Android and iPhone users. But as speed improves, iPad users tend to stay and their bounce rate gets dramatically lower — around 5% compared to 8% for iPhone users and 11% for Android users.

This is especially interesting given what we now know about conversion rates for iPad owners versus other mobile owners. (For example, over the Black Friday weekend, shoppers using iPads converted at a much higher rate than other mobile consumers, 4.6% vs. 2.8% for users of all other mobile devices.) Clearly, keeping your iPad traffic happy is a priority.

3. When it comes to generating page views, iPad trounces other mobile devices.

Again, no big surprise here. But it’s still interesting to see iPad’s growing dominance visualized, as in this animated graph depicting mobile traffic on a Strangeloop customer’s site over the course of two years:

You can see the seminal moment at the end of 2010 (right after Christmas, when it seemed like half the people in the western world suddenly had iPads) when iPad surged past iPhone and Android. While iPhone and Android made significant gains over 2011, page views via the iPad more than doubled — from less than 300K to more than 700K — in just one year.

You can see the same scenario play out over a much more compressed time frame in this next animation, which shows the adoption of an extranet application for another Strangeloop customer, a Fortune 500 company that had just launched a new internal app. Over just six weeks, you can see the mobile devices all starting out mostly neck and neck. Page views for the iPad slowly but surely lead the pack until week 5, when suddenly the iPad leaps ahead, leaving other devices in its dust.

In my opinion, this is just the beginning of the tablet’s dominance. It’s a no-brainer. The average person wants to see more content on a bigger screen.

But while people may embrace tablets, the tablet faces the same performance challenges as other mobile devices…

4. 3G performance is up to 10X slower than throttled broadband service.

As I mentioned above, most iPad users are browsing on their sofas. But many are not, and these folks are getting hit by brutal network slowdowns. Four months ago, I tried a quick-and-dirty approach to real-world mobile speed testing and found that latency can hit 350ms on a 3G network. It wasn’t pretty.

3G latency graphIf you’re experiencing latency of up to 350ms on a page with 50 resources, that’s a whole lot of load time. Given the fact that iPad users (and tablet users in general) expect a desktop-like experience, this lag time is painfully unacceptable.

But network performance is just the first half of the problem…

5. 97% of mobile end-user response time happens at the front end.

About a year ago, I revisited Steve Souders’s four-year-old stat that says that about 80% of end-user response time occurs at the front end, and made a surprising discovery: while this number has remained pretty much the same for desktop response time, the front end is where a whopping 97% of mobile response time happens. What this means for tablet owners: When they aren’t struggling with network issues, they’re challenged even further at the browser level. It’s one uphill battle followed by another uphill battle.

Where does this leave site owners?

Tablets are one of the most exciting innovations to hit the market in the past ten years, and Apple is definitely leading the charge. But you can’t have innovation without a few headaches. Site owners are faced with the challenge of creating sites that work on three types of devices: desktop computer, tablet, and smartphone. These sites need to look good, load quickly, and contain enough functionality and content to satisfy demanding visitors. At the same time, they need to respect bandwidth limitations and bow to the fact that mobile network throttling is on the rise.

How are site owners going to do this? There’s no single answer. The solution lies in embracing a diversity of strategies, from responsive design to infrastructure investment to mobile-specific CDNs (to, of course, front-end optimization). It’s going to be an interesting few years.

Related posts:

By: Tammy Everts Category: Tags: , , , , , ,
« 2 3 4 5 6 7 8 9 »