Yottaa's Site Optimization & Web Performance Blog

Valentine's Day Website Performance Problems: Who Was Heartbroken?

Feb 14, 2013 7:03:00 PM

Posted by Ilya Mirman



godivaRight on the heels of analyzing Superbowl 2013 site crashes is Valentine’s Day!  And given the billions spent by consumers on gifts (and the many millions spent by the Ecommerce sites to drive consumer traffic), we thought it’d be interesting to monitor and diagnose site performance and user experience of several popular web sites, in order to answer the following questions:

  • How do the sites compare to each other, and the rest of the web, on one of the most important commerce days of their year?
  • Are there any user experience / site performance problems?
  • How can we avoid these problems?

tweetSo, here’s what we found…

Ecommerce Sites are Highly Complex, Distributed Apps

These days, a typical web page contains ~80 assets; have a download size of ~700 KB; and ~8 javascripts; and pull content from ~8 domains.

content complexityWell, the Ecommerce sites are considerably richer in styling, interactivity, and use of 3rd-party widgets:

  • ftd.com – 1.9 MB; 187 assets; 25 javascripts; content from 42 domains [test results]
  • godiva.com – 2.3 MB; 198 assets; 53 javascripts; content from 62 domains [test results]
  • 1800flowers.com  – 3.2 MB; 189 assets; 48 javascripts; content from 45 domains [test results]

js vs page load timeThere are, of course, forces driving this complexity – increased sophistication around user experience and site analytics; an increasingly complex web infrastructure; the social nature of the web; etc. 

But this complexity inevitably has an impact on performance.  For example – the more Javascripts there are, the worse performance is, on average.  That’s not to say there aren’t ways to deal with that (more on that below).  But that does mean spending cycles optimizing performance is that much more important.

Performance Varies Widely

Site performance and user experience varies widely.  Some sites were blazingly fast –average load times of 3 seconds across the U.S.; others were considerably slower – 6-10 seconds on average.  I was a bit surprised that – in this day and age, with all the research connecting site speed and business metrics –  some top Ecommerce brands were that slow.  (In Ecommerce, every millisecond counts!)

valentine%27s day ecommerce trending data

More surprising and troubling than the variation in average performance was that occasionally, there were significant performance degradations.  In particular, it was interesting to note that several  - independent – Ecommerce sites all had poor performance on Tuesday evening (4AM GMT / 11PM EST).  (It appears that a leading CDN vendor was experiencing a problem – some assets that typically took fractions of a second to download were taking tens of seconds.)

CDN problem

CDNs and 3rd-party Widgets Were Primary Sources of Performance Problems

Over the past 48 hours, Yottaa’s monitoring network of real browsers identified hundreds of issues affecting user experience and site performance.  The problems were clearly visible in the page loading screenshots Yottaa’s Site Monitor captured, and we could drill down into the waterfall chart to understand the root cause.

For example – both Russell Stover and Godiva candy sites had occasional problems:

candy screenshots

And, here's an example of Godiva.com's slow page loading, and the corresponding waterfall:

godiva problem

And - flower sites weren't spared either:

ftd.com

FTD

Teleflora.com

teleflora2

Drilling  into the waterfall chart further, we could identify the source of the bottleneck.  Sometimes, it was a slow connection time to the server; other times, long waiting times; and in the example below, it was actually a long receiving time (a negligible Time-to-First-Byte, but a long 12-second Time-to-Last-Byte).

akamai problem

CDN issues weren’t the only culprits.  Sometimes, 3rd-party widgets (e.g., ads, tracking tags) slowed sites down. In the example below, a javascript blocks downstream assets:

blocking

In the example below, the ftd.com developers were relying on a Microsoft server to serve the jquery javascript.  Though it usually downloads in a fraction of a second, in this case it took over 20 seconds!

Microsoft Jquery

Avoiding Site Problems

It’s ironic that for these sites, the very infrastructure they turned to in order to improve performance turned out (sometimes) to be the weakest link.  So…what to do?  Here’s three suggestions:

  1. Site Monitoring: It’s critical that your web operations and marketing teams have a handle on site health – by monitoring availability and performance, providing insight on potential problems, and being able to implement a timely resolution.
  2. Front End Optimization: The sites evaluated here could all have benefitted from “front end optimization” – performance techniques that improve load times in the browser by reducing the number of requests, reducing the weight of the requests, and ensuring that 3rd-party assets are loaded in a way that doesn’t block other assets.
  3. Federated CDN: One movement that has been gathering steam over the past several years is the idea of a federated CDN. Simply put, by using more than one CDN, you can leverage the geographic strengths of multiple CDNs to improve performance and reduce risk.  Though there arguably hasn’t been enough technical or commercial progress in this area, this may very well be the future of content delivery over the next several years.

Thoughts?  (And - how was YOUR Valentine's Day?)

 

 


Topics: Application Optimization

Posts By Topic