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:

Black Friday and Beyond [INFOGRAPHICS]

As a Canadian, I’m never sure how many people in the US manage to make it to work during the week leading up to Thanksgiving, but if anyone actually is out there reading right now, here’s a fun set of infographics we just released.

These graphics were triggered by Shop.org’s statement that online shoppers could spend $96 billion this holiday season. We did some digging to find out what these numbers mean. As you might expect, there’s a performance angle in here, too, but I’ll let you scroll down and discover it for yourself.

If you want to grab a high-res version for posting on your own site, you can get it here.

Black Friday and Beyond [INFOGRAPHICS]

Related posts:

The average web page has grown 20% in just six months

The HTTPArchive celebrates its second birthday this month, and it seems fitting to check in and take a quick snapshot of a typical web page. Not surprisingly, pages are bigger. But surprisingly, pages are even bigger than I expected.

Here you can see the growth in average page size over just two years:

Web page growth: November 2010 to November 2012

When I checked last spring, the average page came in at 1042 KB, just over 1 MB. In other words, a typical web page carries a payload that’s 20% bigger than it was just six months ago.

Anecdotally, I’ve noticed an interesting trend over the past few years. At this time of year, pages suffer “holiday bloat” as site owners try to stuff in more images, Flash, and rich media, not to mention a fresh crop of third-party scripts for things like ads, analytics, and trackers. Not unlike us Westerners, pages get fatter throughout November and December, and then, interestingly, trim down a bit when they go on a crash diet in January. At the risk of pushing this analogy over the edge, I’ll add that, like all crash diets, the effects don’t last. Before long, pages start puffing up again.

Pages could hit 2 MB in early 2014

When I wrote about page bloat for GigaOM last May, I projected that, at the then-current rate of growth, the average page would hit 2 MB in 2015. Based on this new finding, we need to upgrade that prediction to early 2014:

Projected web page growth: November 2012 to May 2014

Page bloat in and of itself isn’t news. Page bloat of this magnitude is. This has obvious ramifications for desktop users, but mobile users will be much harder hit.

For more insight into the current state of web pages, I recommend you check out Andrew King’s recent post Average Number of Web Page Objects Breaks 100, as well as Catchpoint’s Holiday Shopping 2012 State of Web Performance.

Related posts:

Only 1 out of 5 top ecommerce sites uses RUM. Why?

Real user monitoring (RUM) is a white-hot topic in our industry right now. For those new to the topic, RUM is monitoring technology that records all user interaction with a website or client interacting with a server or cloud based application. RUM tools use Javascript that’s injected into a page to provide feedback from the browser or client.

RUM is a powerful tool for site owners. It allows them to aggregate user data on a massive scale — think billions of page views — and then analyze the data in endless ways.

In short, for performance geeks, RUM is really, really cool. At any given Velocity conference, there’s a handful of sessions on it, and it’s a hot topic if you follow the #webperf hashtag on Twitter.

But to be frank, despite all the talk, my feeling has been that only about 20% of major ecommerce sites have adopted RUM tools. When I talk to people who run big sites, RUM is barely on their radar. (More on that later.) I was talking about this with a colleague last week, and she was surprised my estimate was so low. So I decided to back up my talk with a little ad hoc research.

Methodology

  1. Took the list of the top 200 retail sites, according to Alexa, and grabbed the middle 50 sites (#76 through to #125).
  2. Ran the home page of each site through WebPagetest in order to get their waterfalls.
  3. Looked at the waterfall for each page, searching for RUM beacons from each of these providers: Gomez, New Relic, Boomerang, LogNormal, DynaTrace, Torbit, Yottaa, and WebTuna.
  4. Looked at who’s using tools like Google Analytics and Chartbeat, which gather timings by default, though I didn’t factor these findings into some of my analysis. (More on this later, but in short: most people seem not to use the RUM results in Google Analytics.)
  5. Asked ten ecommerce managers if they use Google Analytics’ RUM feature.

Caveats

There’s the possibility that some companies may have developed their own home-grown monitoring tools, which might have escaped my search.

The research into the use of Google Analytics is much more anecdotal than scientific, as the sample is small and not representative of Google Analytics customers.

Finding 1: 84% of sites have not adopted RUM tools.

As mentioned above, I didn’t include Google Analytics and Chartbeat in my interpretation. Among the recognized RUM tools, here’s a look at which ones are currently being used:

How many online retailers use real user monitoring tools?

Finding 2: 9 out of 10 ecommerce companies don’t use the RUM feature in Google Analytics regularly.

While more than half (52%) of the sites I looked at use Google Analytics, most don’t use GA’s RUM feature with any regularity.

In a very non-scientific study, I asked ten ecommerce companies who use GA if they use the RUM features. Only one of them regularly looks at the RUM screen (more than once per week). I found that many of them knew that this feature exists and had clicked on the screen at least once.

When asked why they didn’t use it, I heard the following reasons:

  • The data was not comprehensive (different browsers and sample rate).
  • The data was not trusted. (Some were paranoid about Google. Tin foil, anyone?)
  • Existing performance tests were good enough.

I found these conversations very interesting and would like to learn more about this. It fascinates me that a trove of free data is available to people and they don’t use it. What does this say about the potential long-term success of RUM?

I would like to hear more about your experience using the Google Analytics RUM feature. Is my sample representative? If there is an adoption problem, is it caused by usability or data?

This research raises a few more questions:

Why so few RUM adopters?

All the pro-RUM talk is dominated by the mega-players like Google, Amazon, and Etsy, but it hasn’t trickled down to the “mortal” companies.

Does this mean RUM is irrelevant for smaller businesses?

I think real user monitoring is an essential tool in every site owner’s toolkit. If you’re not measuring real-world performance on an ongoing basis, then every effort you’re making to improve your application performance is a stab in the dark. As more and more RUM tools are available at various price points, there’s no excuse not to pick the one that suits your needs and make it a core part of your performance practice.

What should we make of the RUM tools that don’t appear to be used by the test sites?

These findings should not necessarily reflect badly on the tools that don’t appear to have been adopted by the sites I tested. There are some solid tools out there, but I don’t think the market has reached a place where the importance of these tools is being widely recognized.

Related posts:

This is your brain on a slow website [INFOGRAPHICS]

At Strangeloop, we talk a lot about the business value of web performance, but we’re just as interested in the psychology behind those metrics. Our marketing team recently put together this fun set of infographics that explains a bit of the science behind why we all crave nigh-instantaneous page loads.

If this is your kind of thing, there’s also an accompanying report — Our need for web speed: It’s about neuroscience, not entitlement — based on a post I wrote a while back.

Infographic: This is your brain on a slow website

Related posts: