Recently, there was a thread on the WAA forum about content distribution networks and whether increased page load times could justify the cost of the CDN.
I asked our Marketing Director, Juan Ribero, to give me his input on the subject and here is what he wrote:
Everybody likes a fast car. I’ve never heard a single person utter the words, “I wish my car was slower.” The problem is that just because a car is fast does not mean we’re willing to deal with anything less than the utmost comfort and luxury. Only the most dedicated automotive enthusiasts would deal with a daily-driver that had no air conditioning or power windows simply because it was able to move down the road quicker than others.
Analogously, everybody wants their website to be really fast but few people are willing to give up on having items such as analytics tracking codes, personalization, rich media, numerous images, etc… At CableOrganizer.com we’ve spent a lot of time and money making sure that we provide the most useful information and content to our potential customers in the way that is preferable to them. The problem is that because our customers are a particularly savvy group and our products particularly complex, this has resulted in our pages having A LOT of content and this affected our website speed. People facing problems like this essentially have two options:
- Look for a middle path balance by eliminating just enough content to ensure that their website is fast enough.
- Invest in website optimization and content delivery to ensure that they could maintain the same amount of content while improving the speed of our website.
Since we were/are facing the dilemma of always wanting our site to be faster and had already dived headlong into the second option, we had to know exactly how much more money we would make (if there was a difference at all) from a faster website and how much we could be losing if our site slowed down for whatever reason. That way, we would know exactly how much resources we could devote towards speeding up the site and find out once and for all if services such as Akamai were worth the expense.
We used Tealeaf to find this information but SAS has this functionality as well and I’m sure something can be rigged up with Google Analytics partially using the Event Tracking functionality like the people at Panalysis. http://www.panalysis.com/tracking-webpage-load-times.php
First thing we did to figure this out was to use Tealeaf in order to make events based upon the load time on the client side (this is out of the box once you install Tealeaf’s Javascript SDK). We made sure to get really granular assuming that a 0.25 second difference was significant. We went from less than ¼ second to over 20 seconds.
We let the data build up for a month (getting over 200 sales a day so that a month was enough for statistical significance). We then segmented all of our sessions looking at load time averages with the stipulation that no maximum load time was ever more than 3 seconds above the average. We made the assumption that if somebody had an average load time of 0.5 seconds (very fast by most standards) but took 15 seconds loading a single page (usually indicative of a major problem) then their session behavior would be contaminated by that anomaly and it would not be indicative of other customers with sessions of that average speed.
We then analyzed each segment and saw what percentage of each segment actually purchased. These load-time derived conversion rates were quite telling. We found out that users who averaged less than 1 second of loading per page without any significant deviations throughout the session converted at a much higher percentage than those who took an average of 2 seconds. Although intuitively some would be inclined to say that the difference is slight between a second and two, our data proved that there was a statistically significant difference in conversion rate between those two numbers. As one would expect, the difference got more pronounced as the averages got higher and higher with the final extremities proving that our conversion rate for people who average a load time of 7 or 8 seconds was shameful (there may be other factors here like the fact that they’re mobile or dial up users abroad of course).
We were then able to see within these analyzed segments whether or not the average order value changed between those with low page load times and those with high load times and found that there was no consistent difference. This could be because some people interested in big orders would deal with a slow website whereas some business customers willing to make big orders would usually have faster connections and therefore lower load times (these are just my hypotheses.) I imagine that the data would have been a lot more telling regarding average order value if we had segmented it out by product type as naturally some of our impulse buys have a more elastic demand than those items to which we have the best pricing and/or are exclusive distributors. This would have been an interesting study to run but the further segmentation into product types may have diluted our numbers to the point of losing statistical significance so we judged it to be beyond the scope of this test.
As such, we accepted the lack of correlation between average order value and page load time for the time being and used our combined average order value to estimate how much more revenue we could generate on a monthly basis if we increased the speed of the website by an average of 1 second, 2 seconds, etc… and how much we would lose if the site slowed down by those intervals.
We found that the increased revenue that would come on a monthly basis was significant enough (even for a 1 second difference that only affected 1/10 of the visitors) that revenue allocation to the optimization of the website could be done in a quite liberal way. If we had not already been using Akamai for years, it would have been very interesting to do the same report before and after their implementation to see not only how much they lowered the average load time but exactly what their ROI is. Nonetheless, given the fact that most CDN services are relatively affordable, they would have to be really ineffective in order to not be a cost effective model for increasing revenue.