iPad

2013 predictions: The average web page will hit 2MB, Android will pull ahead of iOS for good, and your smartphone will get infected with a virus

11 Dec 2012

6 Comments

It wouldn’t be December without a batch of audacious predictions for the new year. Assuming we all survive past December 21st, here’s what I think 2013 will hold for site owners, mobile users, CIOs/CTOs, RUM vendors, and the browser wars.

1. The average web page is going to hit 2MB.

A year ago, I predicted that the average web page would hit 1MB in 2012, which it did in May. Today, the average page is 1280KB. In a post I wrote last month, I predicted that, at the current rate of growth, typical page size would hit 2MB in early 2014. I’m upgrading that prediction to the end of 2013. Call it a hunch. This has massive implications for site owners in terms of bandwidth, but mobile users will be hardest hit, from both a usability perspective and a throttling/data cap perspective.

2. By the end of 2013, at least half of all North Americans will own a tablet.

Currently, 29% of North Americans own some kind of tablet. With the proliferation of new inexpensive tablets, with the emergence of kids as a mostly untapped tablet market, and with Christmas just around the corner, I’m predicting that more than 50% of North Americans will own a tablet by year end.

3. Global mobile traffic will hit 25% of total internet traffic.

Right now this number is 13%, but numbers are surging in China and India.

4. 25% of online shopping will be via mobile.

With the explosive adoption of tablets, we’re going to see a major jump in mobile shopping. Mobile phones and tablets represented 24% of online shopping on Black Friday, up from 6% just two years ago. We’re going to see that Black Friday stat become the norm.

5. 2013 will be the year your smartphone gets infected with a virus.

You know it’s coming. Cue the dark lords of anti-virus software to the rescue.

6. Android will pull ahead of iOS smartphone adoption. For good.

In five years, we’re all going to look back on 2013 as the year Android pulled ahead for good on smart phones. When it comes to this kind of call, I use the Strangeloop team as the canary in the coal mine. My dev team is moving to Android en masse. I haven’t seen this type of shift since 2009 when the mass exodus from Blackberry began.

7. Mobile performance will continue to be a major problem.

Mobile sites will remain too slow. Too many people still believe that their simplified mobile site is the answer (which it’s not, because it’s often too simple), or that responsive web design is the answer (which it’s not, because RWD pages can actually be even bigger and slower than a typical page). There’s no single magic bullet for mobile performance. Companies are going to have to really apply themselves to finding solutions that work for their unique situations.

8. This will be a great year for Chrome, an okay year for Internet Explorer, and a bad year for Firefox.

Internet Explorer will halt the bleeding and stabilize, but not grow, its market share. Chrome will hit 45% of worldwide browser market share by the end of the year — almost entirely at the expense of Firefox.

9. Two of the four largest CDNs will be acquired and integrated into larger companies.

I’m not naming names, and I have no inside information. This is just my hunch that we’re going to see big changes in this market.

10. Netflix will continue its decline, while Amazon video delivery will ascend.

Amazon’s rise in video delivery to the home will become evident in 2013. Amazon can outspend almost anyone for content — and when it comes to video, content trumps all.

11. DDOS attack mitigation will dominate the enterprise.

There’s nothing CIOs/CTOs hate more than visible failure. Sixty-five percent of the top ecommerce sites will have a mitigation strategy in place by the end of 2013.

12. RUM vendors will finally start to make money.

Real user monitoring will move from the sideshow to the main stage for half of analytics vendors. We’ll even see the first example of actionable RUM, which operations can use to trigger alarms that matter. Operations will start to trust RUM. By year end, RUM will be found on 35% of ecommerce sites.

Related posts:

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

New findings: How does browser usage vary throughout the day and week?

8 Aug 2012

4 Comments

Last month, I questioned the validity of using Internet Explorer 8 as the default browser for performance testing. In the comments on that post, Stephen Pierzchala raised a good point:

I would be really interested to see a little more granularity in both the Akamai IO and Strangeloop data that shows browser usage by time of day and day of week. While it doesn’t change the aggregate results, it may indicate the type of browser that people choose to use, rather than the browser they are told to use.

We all tend to have semi-educated guesses about the browsers that people choose to use at work/school versus those they use at home, but I wasn’t able to find any studies that answer Stephen’s question. So I took a look through our beacon data to see if I could spot any trends. I got some interesting results that confirmed a few of my assumptions.

Approach

  1. Gathered data for one month of traffic for two large North America-based ecommerce sites.
  2. Pared traffic down to four browsers: Chrome, Firefox, Internet Explorer, and Safari.
  3. Aggregated data for each day of the week and plotted this on a graph for each site.
  4. Aggregated data for each hour of the day and plotted this on a graph for each site.

The results were interesting.

Observations

Browser usage throughout the week

As you can see on this pair of graphs:

  • Internet Explorer was the dominant browser for these sites.
  • Traffic for every browser, with the exception of Safari, either flatlined or decreased over the weekend.
  • Safari traffic spiked dramatically over the weekend.
  • Friday is a big browsing/shopping day across all browsers.

Browser usage throughout the day

These graphs bear a striking similarity to the daily breakdown graphs, in that IE, Firefox, and Chrome use begins to trend downward at the end of the workday, just when Safari use spikes.

Conclusions (aka “more educated guesses”)

While this data represents only two websites, I think there are enough similarities to make these findings a compelling argument for a couple of statements:

  1. Internet Explorer should still be the go-to browser for testing ecommerce sites in North America. The primary reason for this, in my opinion, is that many people are browsing/shopping while at work.
  2. Safari is a serious contender as the browser of choice for home shoppers, particularly those in desirable demographics (in other words, the Apple crowd). This is more of a hunch than an educated guess, but my feeling is that this partially based on the massive recent growth of the iPad market. I say this because everyone I know who uses a MacBook uses Chrome or Firefox instead of the default safari browser, whereas everyone I know who owns an iPad uses Safari. (Like I said, it’s just a hunch.)

I definitely don’t consider this the last word on the subject. The browser wars are far from over, and there’s enough flux in the industry that it’s anyone’s guess as to what the next year might hold. If you know of any comparable studies or statistics, let me know.

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: , , , , , ,

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

20 Jan 2012

11 Comments

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:

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

Announcing the Strangeloop Mobile Site Optimizer

21 Sep 2011

13 Comments

Patents have been filed, bugs squished, datasheets reviewed… and today, we’ve announced that Strangeloop has developed the world’s first advanced front-end optimization solution for mobile devices.

To say that I’m excited would be an understatement. As anyone here can tell you, I’ve been haranguing our dev team about it every day for months — years, actually. They’ve politely (for the most part) tolerated me, and in the end delivered a product we’re all incredibly proud of.

Our marketing team has put together some excellent materials explaining what Mobile Site Optimizer is. I want to take a different approach and talk first about what Mobile Site Optimizer isn’t.

Mobile Site Optimizer is not:

  • A tool that designs mobile-specific sites.
  • A suite of desktop optimization best practices disguised under a shiny new label.

We’re not getting into the business of mobile site development.

Companies like Mobify are already in the business of designing slick, mobile-specific sites, and they do a great job. That’s not a business we want to get into. Mobile Site Optimizer will make m.domain.com sites faster, it’s true, but we also wanted to take on the challenge of making the full site faster on mobile browsers.

But why do we want to do this, when companies can just create a mobile site? Two reasons:

  1. Earlier this year, when we were digging into our beacon data (gathered over the course of hundreds of millions of transactions on our customers’ sites), we noticed something interesting: 1 out of every 3 people coming to sites via mobile devices chose to view the full site, when that option was available.
  2. “Mobile” is a huge umbrella that includes tablets. Anyone who’s been paying attention knows that tablets are set to dominate the personal PC marketplace. This year alone, 15% of PC sales were tablets, and that number is only going to rise. Tablet owners don’t want to see a scaled-down version of a site. They want the full-site experience. Yet tablets are subject to many of the same performance pains as smartphones: slow parsing speed (10-20x slower than desktop) and greater latency (up to 6x), not to mention the roughly 300ms delay caused by the need to convert touch to click events every time the user taps the screen.

Mobile website performance and user behaviour

So why not just slap a “Mobile” sticker on our desktop Site Optimizer?

We considered it. In fact, we tried it. We even got jealous when we saw others do it. After all, we knew that Site Optimizer offers an unparalleled suite of optimization treatments. And with hundreds of deployments under our belt, including some of the biggest companies and sites in the world, we knew Site Optimizer could scale securely.

But the more we dug into the mobile space, the more we realized that mobile environments pose some challenges we’d never faced with desktop. At the same time, we realized that mobile also offered us some pretty cool opportunities.

And at the end of the day, we just couldn’t resist tinkering around solely for the fun of it.

So we went for it. We bought tons of different devices, hooked them up to different networks, and started studying waterfalls (a geek’s paradise). And as it turns out, those challenges I mentioned above — parsing speed, latency, touch screens, and more — ended up spurring the development of eleven never-before-seen optimization treatments designed exclusively for mobile devices. Here are three of my favourites:

Mobile SuperCache

On the desktop, the browser cache is a key tool for delivering faster pages to repeat visitors. On mobile browsers, not only are caches notoriously tiny, they also get flushed all the time — even sometimes within a single visit — making them practically pointless. Mobile Site Optimizer gets around this by taking advantage of an HTML5 feature called Local Storage to configure storage (in mobile browsers that support HTML5) that is both persistent and reliable. The Mobile SuperCache goes far beyond just getting things into cache. It includes invalidation, prioritization of objects in cache, the ability to cache in-lined objects, and some additional cool secret sauce that you will need to call me to find out about.

Touch Event Conversion

As I mentioned above, every time a mobile user touches their screen, the device has to translate that touch event into a click event in real time. Typically, this takes about 300 ms, but it can take up to 0.5 seconds. Those touches add up. So we found a way to automatically convert all those clicks into touches, relieving the browser of the realtime overhead of conversion.

Dynamic Payload Decision Making

This feature is my pet. (Don’t tell the others.) We found ourselves really challenged by the idea that one of our standby Site Optimizer treatments, Predictive Browser Caching (aka Preloading), which delivers fantastic acceleration results on the desktop, might actually be a huge negative for mobile users. Predictive Browser Caching works by intelligently guessing where a user is likely to go next and preloading those page resources in the browser. This is great is you’re on a Wifi connection, with practically unlimited data, but what about when you’re out and about, roaming on your 3G or 4G network? Sending all those resources — some of which you may never see — could eat up a lot of your data plan.

Our challenge was to squeeze as much benefit as we could out of Preloading, without bottoming out people’s data plan. So we came up with Dynamic Payload Decision Making, which recognizes each user’s network connection in the moment, and makes sure that the user is served pages optimized according to their network limits. As one example, if you’re at home, you get a more aggressive version of Predictive Browser Caching. If you’re out on the street, you get only a trimmed-down core set of preloaded objects. You win both ways. This is just one of many dynamic payload decisions we make, but the goal is always to serve the end user’s best interests.

I could go on all day (really — ask anyone), but I’ll wrap things up here and direct you to discover our other eight treatments on our site. On top of the usual datasheet and whitepaper, we’ve also got some infographics that illustrate why mobile performance should be a big deal, as well as a pretty nifty video that shows how Mobile Site Optimizer works. Here’s a peek:

Before I sign off, I want to thank our lead developers on this project, as well as our CTO, Kent Alstad, and our VP of Product, Hooman Beheshti, for their incredible work over the past few months. I also want to tip my hat to the rest of the amazing team here at Strangeloop, who made this industry first possible.

*We didn’t entirely forsake Site Optimizer. We ran our desktop treatments through a battery of tests and kept those that delivered benefits to mobile.

Related posts:

By: Tammy Everts Category: Tags: , , , , , ,
1 2