Amazon

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

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:

We’re teaming up with Amazon Web Services to bring advanced FEO to CloudFront customers

There’s a great quote from Geoffrey Smalling, CTO at Wine.com, in this Strangeloop case study:

Anyone who tells you there is [a single magic bullet] does not have a deep understanding of the myriad issues that affect performance. Performance tuning requires a multi-tiered approach.

To get the best acceleration results, most of our customers use a combination of front-end optimization (FEO), content delivery network (CDN), application delivery controller (ADC), and in-house engineering. But this many acronyms can come with a steep price tag. While this is a great approach if your company has deep pockets or the in-house know-how to structure these solutions, let me paraphrase an old ad: “For everyone else, there’s Amazon CloudFront and Strangeloop.”

This is my roundabout way of announcing our latest partnership, this time with Amazon Web Services. Effective immediately, we’re teaming up to offer Strangeloop’s Site Optimizer service to CloudFront customers.

CDN + FEO: Two great tastes (etc.)

The benefits of combining content delivery with FEO aren’t news if you’ve been reading my blog for a while. To sum it up, CloudFront addresses the performance middle mile by bringing resources closer to users — shortening server round trips and, as a result, making pages load faster. Strangeloop’s technology tackles performance at the front end, analyzing and optimizing every page of a site, without touching code, so that it renders more efficiently in the browser.

As the table below (which uses data from this case study) shows, this combined solution has a huge impact on page metrics, from number of requests to payload to start render and load times. The bottom line: a combined CDN/FEO solution can make pages up to four times faster.

Q: Who wins? A: Small- to mid-sized companies

As a pay-as-you-go service, CloudFront brings an affordable content delivery service to smaller companies. In the same way, we can now bring advanced FEO — which has formerly only been available to companies with those aforementioned deep pockets — to smaller companies, as well as to companies for whom FEO is murky new territory.

Amazon Web Services senior manager Alex Dunlap has written a really great post on the AWS blog that talks about our partnership and explains how to configure Amazon CloudFront to work with Site Optimizer. I urge you to check it out if you want more insight into how our services complement each other.

If you have any questions about how these two solutions work together or their net benefit, let me know. In the meantime, expect an Amazon sales rep and a Strangeloop rep to show up at your door and make a compelling case for why you can get better performance for a fraction of the cost you are currently paying your existing provider. Let the games begin. :)

MORE: Find out how to get started with CloudFront and Strangeloop.

Related posts:

Jumping in the Velocity Wayback Machine: 9 presentations that are still relevant today

It’s going to be a busy two weeks. I’m in London right now, meeting with some of our partners, then off to talk about mobile at USI in Paris on Monday, then straight to Santa Clara to sit on a Velocity panel about performance tools on Tuesday.

Now that I’ve fulfilled my self-pimping obligation, I want to take a minute to revisit some of my favourite sessions from past Velocity conferences. Recently I read somewhere that we tend to distrust information that’s more than a year old, but I have to say that I find these slide decks, some of which are three whole years old, still interesting and relevant today.

Velocity 2011

Performance Measurement and Case Studies at MSN

Paul Roy, Alex Polak, Gregory Bershansky

MSN shared some case studies that showed how speeding up load time affected page clicks. I live for these kinds of case studies, so I was happy to learn that:

  • In an experiment with implementing synchronous jQuery load, they experienced a +0.5% increase in search clicks and page clicks.
  • In another experiment with improving JavaScript execution time, they experienced a +1.2% increase in search clicks and a +0.5% increase in page clicks.

But what I thought was particularly interesting was the case study around delaying ad loading. They experimented with delaying the loading of a major ad by 1 second, which improved the time to onload by 500ms. As a result, they saw an increase page clicks and views, but a 15% dropoff in ad clicks.

Obviously this kind of ad performance hit isn’t viable for a site that relies on CTR for revenue, but what grabbed my attention was MSN’s takeaway from this exercise:

Velocity 2011 - Microsoft case study: Delay ad loading

My favourite thing about this session was that, rather than being scared off by the initial 15% hit to CTR, Microsoft persists in looking for the sweet spot that yields faster load time without hurting advertisers. This improvement may end up just being a hundred or so milliseconds, but the message here is that it’s a goal worth chasing.

The Impact of Ads on Performance and Improving Perceived Performance

Julia Lee, Senior Director of Engineering, Yahoo! Mail

With almost two billion page views a day, the cumulative effects of latency can hit Yahoo mail hard. They found that 73% of their overall latency was due to ads. No surprise when you look at how convoluted an ad’s server call can be:

Velocity 2011 - Third-party ad call
What does this convolution add up to, performance-wise? Julia shared that in the old days, before redirects, the average ad experienced about 464ms of latency. Over time, that number grew to 2.7 seconds.

Mobile Web & HTML5 Performance Optimization

Maximiliano Firtman

If you’re in mobile web development, this slide deck is a must-see. Starting at slide 51, Maximiliano gives an impressively thorough breakdown of optimization tips, from handling images to deferring content. This slide is my favourite:

Velocity 2011 - Why mobile websites are slow

Velocity 2010

Performance Testing: Putting Cloud Customers Back in the Driver’s Seat

Imad Mouline

In this session, Imad shared some KPI data,back when such information was still hard to come by, including this graph showing that speeding up a page by just 4 seconds decreases abandonment by 25%:

The Impact of Web Performance on Page Abandonment

Psychology of Performance

Stoyan Stefanov

This was a great presentation that demonstrated (to many of us for the first time) the human factors side of web performance. For example, Stoyan showed that there’s a distinct difference between perceived speed and actual speed. When it comes to web performance, this difference works against us:

Actual versus Perceived Time

Metrics 101

Sean Power

There were a handful of messages that were threaded throughout many of the presentations and discussions at Velocity 2010. The relationship between performance and the bottom line was one of them. Sean presented some visuals that hammered these points home. Among other things, he showed how, as latency increases, conversion rate drops:

Impact of increasing latency on conversion rates

Sean also showed the long-term effects of poor performance: a poorly performing website suffers not one but two waves of abandonment, as users spread the word of their poor experience and drive other users away from the site.

Long-term impact of poor performance on user behavior

In the last part of his session, Sean offered a realistic step-by-step plan for dev/ops folks to measure performance and outcomes in their organization. He said that if you create only one graph for your site, it should be one that looks something like this, which shows the direct impact of page load on conversions:

Sample graph: The relationship between web page load time and conversions

Velocity 2009

The User and Business Impact of Server Delays, Additional Bytes, and HTTP Chunking in Web Search

Eric Schurman and Jake Brutlag

There were many cool things about Velocity 2009. One was the presentation of so much brand-new data about the relationship between page speed and business metrics — often done by deliberately slowing down pages, which was considered a pretty radical idea. For many people, this connection, which we take for granted today, was a revelation. Another cool thing was the research partnerships, like this one between Amazon and Google. Definitely worth a watch.

The Secret Weapons of the AOL Optimization Team

Dave Artz

More groundbreaking research. AOL found that visitors in the top ten percentile of site speed viewed, on average, 7.5 pages per site visit. Visitors in the bottom ten percentile viewed just 5 pages per visit.

Shopzilla’s Site Redo – You Get What You Measure

Philip Dixon

This is a seminal piece of research. Back in 2009, Shopzilla became the poster child for web performance when they shaved almost 5 seconds from their page load times and increased revenue by 7-12%.

It’s been fascinating to note the evolution of themes from year to year, and to follow the ever-deepening nuances of performance. I’m looking forward to seeing what Velocity 2012 holds.

Related posts:

2012 predictions: The average web page will hit 1 MB, Google and Siri will face off, and Chrome, Windows 7, and RUM will rise

It wouldn’t be December without an avalanche of predictions for 2012. Here’s my contribution.

1. The average web page will surpass 1 MB in size.

Between December 2010 and now, the average web page grew from 716 KB to 965 KB, according to the HTTP Archive. That’s 30% growth in slightly less than one year. This kind of growth is the norm, as pages have grown at a rapid rate since 1995, when the average page size was just 14.1 KB. It’s pretty safe to assume that this growth will continue. We’re going to see sites grow by at least another 30%, taking them well over the 1 MB mark — a number that would have blown our minds 10 years ago. The main culprits: images (which account for more than half of the average page size) and third-party scripts like analytics, ads, and social sharing widgets.

2. Site owners are going to demand more transparency and control over third-party content and scripts.

As the graphs above show, scripts are the fastest-growing area of page growth. In just one year, scripts have grown by 50%, from 115 KB to 172 KB on the average page. As I wrote here a couple of months ago, the average top e-commerce site contains seven third-party scripts, with some sites containing up to 25 scripts. These can have a serious impact on page performance. Poorly optimized third-party scripts can slow down page load by several seconds or even stall it completely.

Currently, most third-party script providers don’t offer real-time monitoring of their scripts, nor do they offer meaningful service level agreements (SLAs). As site owners become increasingly educated about the importance of page speed, they’re going to start demanding that scripts be properly optimized to either load asynchronously (or better yet, load after document onLoad). They’re also going to demand better monitoring, reporting, and accountability from script providers.

3. Chrome will become the dominant browser.

For the past year, we’ve seen Internet Explorer and Firefox slowly dropping in popularity, while Chrome’s popularity has been rising steadily. Right now, IE is still dominant, and Chrome just passed Firefox. Chrome’s success is well deserved. It’s fast, clean, and comparably glitch-free. With Chrome set to unite with Android, which is as much a semantic merger as a technical one, we’re going to see Chrome’s numbers climb sharply.

4. Windows is going to surprise us on mobile.

Everyone thinks it’s an iOS/Android world, but that could all change when we see Windows 7 embedded in the next wave of Nokia devices. I recently had a chance to play around with a Win7 device, and it was pretty slick (which, coming from a die-hard iPhone user, is saying a lot). Remember how Internet Explorer blew Netscape out of the water back in the ’90s? Windows 7 might not be a game changer to quite that extent, but we’re going to see it become a contender in the mobile universe.

5. Mobile consumer behavior will continue to evolve as mobile users’ expectations grow.

Marriott recently reported that 47% of their mobile bookings happen on the same day as check-in. This implies an important paradigm shift among mobile user behavior. Clearly, these users have developed the expectation that they can book on demand and on the go. Mobile users expect 100% availability and quick response. There’s zero “try again later” mentality. They won’t return to a poorly performing site — they’ll bounce to another site that can give them what they want immediately. We’re going to see more of this type of behavior, and site owners are going to have to adjust to the fact that mobile users are even more demanding than desktop users.

6. Companies will focus internally on mobile development.

As I mentioned in this piece on O’Reilly Radar, the 2011 holiday shopping season has proven that the mobile web is no longer a curiosity. Rather than keeping mobile on the sideline, in 2012 companies will grow their mobile teams, and these will eventually match the size and scope of their regular development teams.

7. Amazon Silk is not going to spark a browser revolution.

As I also mentioned in the O’Reilly interview, while Silk offers a performance boost for some tablet content, even its own product manager, Brett Taylor, says of tablet browsing, “It’s not meant to process and crunch a lot of heavy data.” I’ve written many times about the difference between basic versus advanced content optimization. Basic optimization techniques – such as those embedded in Silk – can actually slow down, or even break, pages. Web pages are becoming even more complex, data-intensive, and dynamic. Because of this, advanced content optimization – which takes a big-picture approach to accelerating the entire site — is increasingly emerging as the only reliable way to optimize sites without causing harm.

8. Google and Siri could begin a long face-off.

Google has become synonymous with search, and it would require a massive paradigm shift to dislodge them from this position. Siri has the potential to be a formidable contender. By taking users completely out of keyword-entry mode, and by focusing on local search, Siri is incredibly attractive to mobile users, who are often task-oriented and on the move. But it all comes down to results. Google became dominant in search because it delivered the most relevant results, and it delivered them fast. If Siri can do the same – and to be blunt, right now Siri kind of sucks — then it’ll be interesting to see how Google responds.

9. Companies are going to start shining a spotlight on internal application performance.

2010 and 2011 marked the years when companies realized how important site speed was for their e-commerce sites. Now that everyone has internalized the fact that faster pages equal more revenue, they’re going to take this insight and apply it to their internal web-based applications. There are a lot of studies, dating back as far as 1968, showing that employees can radically increase their productivity — in some cases by more than double — when computer response time is improved by just 2 or 3 seconds. But very few companies did anything with these findings. We’re going to see a renaissance in this kind of research, and we’re finally going to see companies aggressively pursue improving internal performance.

10. The CDN market is going to become a lot more competitive.

Until recently, whole site acceleration or dynamic site acceleration (DSA) was a big-ticket solution offered by one company. Now there’s a growing selection of competitive products backed by innovative companies offering newer technology and, ultimately, faster sites. Unlike the price wars that happened in the video delivery marketplace a few years back, the added value will keep prices and margins at reasonable rates (nothing like the usurious rates currently being charged). The big winners here are going to be savvy site owners, who could see their bills reduced, and their service quality go up.

11. Real user monitoring will make performance testing accessible to smaller, “mortal” companies.

Performance testing is challenging. When synthetic tests (sometimes called backbone tests) were first developed, they came with a pretty major price tag, which meant they could only be embraced by site owners with deep pockets. With the recent proliferation of affordable, quality real user monitoring (RUM) tools, site owners will be able to finally get real insight into their visitors’ behavior — at a decent price.

Agree? Disagree? I’d love to hear your thoughts.

Related posts:

How vulnerable is your site to third-party failure?

Third-party scripts are the single most common point of failure for sites: just a single line of JavaScript can take down your entire site. Despite this, measuring the impact of third-party content on a site’s usability is often an afterthought — if it even gets thought about at all.

After reading Pat Meenan’s excellent post on third-party SPOF (single points of failure), in which he used WebPagetest to simulate how your site will perform if one of its third-party providers goes down, I was inspired to try it out for myself. (I wasn’t the only one. Steve Souders wrote this great post today, as well.)

After running my tests, I revisited some research we did here at Strangeloop into third-party scripts and how they’re used by 200 top ecommerce sites. Some very interesting stuff came up, which I’ll get into later in this post.

Methodology

I wanted to see how vulnerable the top five ecommerce sites (according to Internet Retailer) are to third-party SPOF. I did the exact test that Patrick did, but decided to blackhole all third-party domains except the CDN domain (i.e. if a site was using Akamai or Level 3 for small objects, I did not blackhole that domain).

I generated a series of side-by-side videos for each site, so you can get a vivid sense of the impact of third-party failure on page load. I’ve also included the waterfalls so you can see what the major culprits are. (You can see the scripts I used by clicking on the waterfall for each test and clicking “strip”.)

Amazon

Waterfalls: normal vs. broken

Observations:

  • Site still performs
  • Site looks fine, except for the fact that the ads don’t come in.

Staples

Waterfalls: normal vs. broken

Observations:

  • When Omniture dies (see line 18 of the waterfall), the entire site stalls for almost 30 seconds.
  • This site is entirely reliant on Omniture.

Apple

Waterfalls: normal vs. broken

Observations:

  • Caveat: Right now, Apple is still running its Steve Jobs memorial home page. Practically zero content, meaning the page is incredibly small.
  • Very few third-party calls.
  • Nothing blocks. The entire internet could go down and this site would still work.

Dell

Waterfalls: normal vs. broken

Observations:

  • As with Staples, Omniture blocks the page request (see line 11 of the waterfall), this time for almost 20 seconds.

Office Depot

Waterfalls: normal vs. broken

Observations:

  • This waterfall is the worst of the bunch.
  • The issue here seems to be one that Steve described in this 2010 blog post about SPOF. In this case the file is an external JavaScript file very near the top of the page, which is why the effect is so bad. The page is white until it times out trying to connect to the broken domain.
  • The same behaviour happens when testing this page with HTTPWatch in IE9, Firefox 7, and Chrome 16.

How are top ecommerce sites using third-party scripts?

A few months ago, I wanted a to get a sense of how ecommerce sites were implementing third-party scripts. We did an audit of the top 200 Internet Retailer sites to see who is using what. Here’s some of what we found.

Average number of third-party scripts


Average # of 3rd-party scripts
Top 200 sites
6.7
Top 20 sites
3.5

6.7 actually isn’t that bad, but some sites use many more than that…

Top sites, in terms of the number of third-party scripts used

Site # of 3rd-party scripts
Coastal Contacts
25
Express LLC
23
American Greetings
22
Urban Outfitters
21
The Sports Authority
20
Coldwater Creek
19
American Girl
19
RealNetworks/GameHouse 18
Chico’s FAS
18
Signature Styles/Spiegel
17
Boden USA
17

When you look at the sheer volume of widgets and third-party tools out there, the numbers above are not too surprising. This next table represents just the tip of the iceberg…

Most-used third-party scripts

3rd-party script provider
Appearance in top 200 sites
Omniture
98
Google Analytics
97
DoubleClick Floodlight
49
DoubleClick
45
Google AdWords Conversion
45
Coremetrics
44
Right Media
40
Foresee 36
Microsoft Atlas
33
LeadBack
32
DoubleClick Spotlight
29
Turn
29
Facebook
27
Acerno
26
Rubicon
25
Channel Intelligence
24
Dotomi
22
Interclick
22
Traffic Marketplace
22
Adconion
19
Channel Advisor
19
Resonance
19

Many people would guess Facebook because of its visibility, but this is a good reminder that “invisible” scripts are actually much more widely used than obvious content like social buttons.

Conclusions

Omniture doesn’t come off well, obviously. In 2 out of 5 of the sites I tested up top, it was clear that if Omniture goes down, the site goes down. And as our survey shows, almost half of the top 200 sites use Omniture.

But I don’t want to over-focus on Omniture. The key issue here is that site owners are implementing more and more third-party scripts, possibly improperly, and with little to no analysis of how these scripts affect their sites. It doesn’t matter how well you optimize the rest of your site if a single line of external JavaScript can take out the whole thing.

Takeaways

The odds that all your third-party scripts are going to fail simultaneously? Pretty close to nil. The odds that some of them going to fail sometimes? Pretty much guaranteed. You need to ask yourself these questions:

  • What do you know about the third-party scripts on your site? Do you know how many scripts your site contains. Do you know who all of your providers are?
  • Is your third-party content optimized? You can’t optimize the script itself, obviously, but you can make sure that it’s implemented well in your pages. (Here are some good tips and how-tos.)
  • Are all those scripts adding value? And is that value significant enough to outweigh any performance losses? (See my blog post and accompanying webinar to figure out how to calculate this.)
  • What are your SLAs with your third-party providers? Do you even have SLAs with your third-party providers? (Not to turn this into a product shill, but third-party SLAs are a feature in our new Mobile Site Optimizer. If you want to learn how this feature works, read more here.)

Related posts: