Ecommerce

Updated: Use of content delivery networks doesn’t correlate to faster websites for the Alexa Retail 1000

Here at Strangeloop, we’re in the process of compiling the results of our Alexa 2000 performance study (which I wrote about here) into a formal, more detailed report. I was looking at one of our spreadsheets, which contains all the data about content delivery networks (CDNs), and had a Rainman moment that led to the creation of this scatter graph:

Here you can see the top 1000 retail sites, ordered from left to right. The blue diamonds represent the sites that use a CDN. The red squares X’s represent the sites that don’t. Not surprisingly, CDN use is much more prevalent among the higher-ranked sites. and non-existent among the lower-ranked sites.

Now look at the vertical axis, which indicates the page load times for each site. This is where things get really surprising.

As you probably know, content delivery networks make sites faster by caching content closer to users. Therefore if CDN use automatically correlates with faster-than-average websites, this graph should look profoundly different:

  • The blue diamonds should be clustered exclusively in the bottom left sector. Instead, the blue diamonds are almost an identical overlay of the red squares X’s.
  • I would also expect that lower-ranked, non-CDN-using sites would have, on average, markedly slower load times, meaning that the red squares X’s on the right side of the graph should be clustered in the top-right corner. But instead you can see that the right half of this graph is almost a mirror image of the left half.

Theories

There are a few possible explanations for these results:

  • Website owners believe they have “fixed” their site speed issues once they start using a content delivery network, and therefore they stop investing in other performance best practices. Part of the reason they may believe their sites are faster is because they are relying on backbone tests to give them a readout of their websites’ speed. As I’ve written before, backbone tests are not a good indicator of performance.
  • The CDN’s edge caches may be too full to contain all the objects needed to deliver fast web pages.
  • A CDN’s edge caches contain the objects for pages that are most frequently requested by users. If objects are not pulled often enough, they will not remain in the cache, meaning that you won’t always receive the full benefit from your CDN.
  • CDN pops are too far away from the end users and offer limited benefit.

It’s interesting to note that companies that are not currently using CDNs are making good use of other performance best practices to deliver comparable site speed. When these companies make the decision to add a content delivery network to their mix, they have a good chance of surpassing those sites that rely solely on their CDN. And because performance is a key factor in driving online sales, we could see some interesting shake-ups in next year’s Alexa retail ranking.

This research brings up a number of unanswered questions. I intend to dig deeper into this to find out if these findings correlates to which content delivery network provider is selected, what type of CDN they use (small object or whole site) and the impact of geography and sure type.

Edited on 12/22/2010 to add:

I decided to generate a new graph to make it more readable, using a less heavy X icon in lieu of the red squares. In generating the new graph, I realized that I had incorrectly displayed the sites that use CDNs (the blue diamonds), so that they were compressed in the left half of the graph rather than across the entire width. The new, correct graph now appears above. You can see the old graph here. This correction doesn’t affect the observations and theories contained in this post.

Related posts:

Downtime may grab headlines, but slow website performance is the silent-but-deadly #1 enemy

When I got back to my desk on Monday morning, I had not one, not two, but eight different emails from colleagues, sending me the same article about the Black Friday outages suffered by JC Penney and American Eagle.

I’m not surprised by this (the emails, I mean, not the outages). Spectacular site outages are the most visible form of IT failure, and, like car crashes, they get the most media attention.

But if we look at the results from Black Friday, while the spectacular car crashes of JC Penney and American Eagle may attract the attention, the real revenue killer is still site speed. But you won’t read headlines about this.

Site speed and site performance are not sexy and spectacular. It’s hard to get an editor excited about running a story with a headline like “An ecommerce site took 12 seconds to load from my house, so I got frustrated and went to a competitor.”

Yet my esteemed colleague, performance expert Lenny Rachitsky, has gone on the record (if Twitter is considered the record) as saying “Downtime is better for a B2C web service than slowness. Slowness makes you hate using the service, downtime you just try again later.”

A tale of two ecommerce mega-sites

To elaborate on this point, let’s compare JCpenney.com with one of its competitors, Macys.com:

Website Availability Page load time (seconds)
Macys.com 100% 21.186
JCpenney.com 99.10% 7.231

According to this news release from performance monitoring company WatchMouse, JC Penney’s website was down for a total of 6 hours and 42 minutes on Black Friday. This is definitely something that JC Penney should be — and no doubt is — concerned about.

But let’s look at Macy’s, which had no downtime issues over the holiday weekend, but whose home page takes an incredible 21.186 seconds to fully load, compared to JC Penney’s passable load time of just over 7 seconds. If we look at the stats on the direct relationship between performance and revenue, and apply the formula that a 1-second performance improvement nets out to be about a 7% increase in conversion, we can deduce that Macy’s slowness is, quite arguably, a much greater revenue-killer than JC Penney’s one-off downtime issue. A relatively slow site like Macys.com might have lost upwards of 30% of its potential revenue this weekend to competitors, due to its poor performance.

There’s also the long-term effect of slow performance. A 1-second delay equals a 16% decrease in customer satisfaction. This dissatisfaction leads to fewer return visits and negative word of mouth. In fact, joint research by Microsoft and Google found that the cost of slowness increases over time and persists for weeks even after site performance is improved.

Users brush off isolated downtime incidents. They don’t brush off the lingering effects of slow page speed.

And yet, given all this, JC Penney made headlines. Macy’s did not.

Right now, site downtime represents the single greatest fear of all IT professionals. Given the massive potential losses caused by slow site performance — a silent and deadly conversion killer — I suggest that sub-par page load times share that top spot.

Related posts:

End-of-year web performance report: Top retail sites are slower, not faster, than the rest of the pack

Benchmarking is an endless numbers game. Just when you accept one number, another comes along to burst your bubble. But sometimes not in the way you expected.

Case in point: Everyone wants to know how the big players measure up, hence the countless performance studies on everything from the Fortune 500 to the Internet Retail 500. We here at Strangeloop have done a few of our own. When we undertook our most recent study — a look at the top 2,000 retail sites according to Alexa — we got a few surprises.

Methodology

We used Webpagetest to test each site’s home page, via the server in Dulles, VA San Jose, CA, as it would appear to a visitor using IE7 on DSL. (Wondering “Why IE7?” Please read this.)

For the purposes of this study, we focused on these performance criteria:

  • Time to first byte, start render, document load time, and full load times for first and repeat views
  • Page Speed scores: Keep-alive, compress text, cache static content, combine JS/CSS, and use CDN

What we expected to find

We went into this study expecting to see three patterns emerge:

1. Average page load time of 7 seconds or less.
Last spring, Aptimize released a report that benchmarked the average Fortune 500 website at 7.066 seconds, following a virtually identical methodology. We expected that our results in this area would mirror theirs, or possibly be faster, given the fact that performance has become such a hot topic over the course of the year, especially in the retail sector.

2. Top-ranked sites load faster than lower-ranked sites.
We assumed that top-ranked sites would invest more heavily in performance optimization. As a result, we expected that the top 100 sites would perform better, on average, than the overall average for all 2,000 sites.

3. Generally poor Page Speed scores.
Based on our recent look at the Alexa Retail 1000, which revealed that almost half of these sites don’t follow two of the easiest performance best practices — enabling keep-alives and text compression — we anticipated that this trend would prevail.

What we actually found

Turns out, we got two out of three wrong. Or one out of three right, if you’re one of those half-full-glass types.

1. Average page load time was 11.21 seconds.

Site speed as indicated by time to first byte, start render, document complete time, and time to fully load

That’s right: the average page took more than 4 seconds longer to fully load than the widely accepted Fortune 500 benchmark of 7 seconds.

2. The Alexa-ranked top 100 sites were slower than the overall average, not faster.

Site speed as indicated by time to first byte, start render, document complete time, and time to fully load

Not only were the top 100 sites slower, they were much slower. The average load time was 14.39 seconds, 3.18 seconds slower than the overall average. (This kind of blows my mind.)

3. Page Speed scores were as poor as expected.

Performance grades: keep-alives, compress text, cache static content, combine JS/CSS, use CDN

While it’s heartening to see a significant number of sites enabling keep-alives — one of the easiest ways of immediately improving page speed — this histogram demonstrates that most sites had failing Page Speed grades.

Who was slowest and who was fastest

I was surprised at how many sites in the top 100 took 20 seconds or more to fully load. Here they are:

Slowest-loading sites in the Alexa Retail Top 100
Site Fully loaded (seconds)
autotrader.com 40.284
babycenter.com 33.251
kohls.com 33.237
nike.com 31.643
dickssportinggoods.com 27.044
barnesandnoble.com 24.925
sears.com 22.623
bhphotovideo.com 22.588
allposters.com 21.791
cabelas.com 21.539
macys.com 21.186
stubhub.com 20.466
landsend.com 20.448

At the opposite end of the spectrum, these were the sites from the top 100 that loaded in less than 5 seconds:

Fastest-loading sites in the Alexa Retail Top 100
Site Fully loaded (seconds)
ecrater.com 2.270
futureshop.ca 2.768
amazon.com 2.939
emusic.com 3.131
wellsfargo.com 3.146
etsy.com 3.354
6pm.com 3.571
bodybuilding.com 3.998
bestbuy.com 4.402
shopbop.com 4.411
netflix.com 4.445
audible.com 4.529
ebay.com 4.991

Some clear takeaways

Just because the performance community has made gains in some areas, this battle is still moving in an uphill direction. It’s too early to assume that (a) every online retailer even has performance as a stated goal, and (b) retailers have a clear sense of how to go about making their sites faster.

2010 may be the year that performance finally got on the map, but 2011 is the year that the map needs to get some serious eyeballs.

Related posts:

Best image of the day

Courtesy of Heering.com. They get full points for honesty, at any rate.
Web Peformance Optimization: Funny photo of the day

Crosspost: Is your website slowing you down?

If you’ve been coming here for a while, then you’re probably familiar with some of the points I raise in this article I recently wrote over at Marketing Daily. But if you’re new and want to get an overview of why site speed matters and the first steps you can take to tackle performance on your site, you might want to check it out.

Related posts