Why Ecommerce Sites That Use a CDN Take Longer to Become Interactive (and Why You Still Need a CDN)


One of the most provocative findings in our latest State of the Union for Ecommerce Web Performance was the fact that using a content delivery network correlated to slower performance for retail sites. In today’s post, we’ll explore what this finding means (hint: correlation doesn’t mean causation) and why you still need a CDN in your performance toolkit.


If you’re not familiar with this research, every quarter we measure the load times for the home pages of the top 500 ecommerce websites (as ranked by Alexa.com) with our eye on a number of performance metrics, including load time, time to interact (aka TTI — the moment when a page’s primary content loads and becomes interactive), page size and composition, and adoption of performance best practices.

Key Findings About CDNs and Performance

Page size and composition for sites that use a CDN versus those that don'tWe broke out the numbers into two camps — sites that use a CDN and sites that don’t — and we learned a few things:

  • 75% of the top 100 sites use a CDN.
  • Median time to interact (TTI) for a page that uses a CDN was 5.7 seconds. Median TTI for a page that doesn’t use a CDN was 4.7 seconds.
  • Median load time for a page that uses a CDN was 10.7 seconds. Median load time for a page that doesn’t use a CDN was 10.5 seconds.
  • Median size for a page that uses a CDN was 1692 KB, compared to 1607 KB for the median page that doesn’t use a CDN.
  • Median number of page resources for a page that uses a CDN was 105, compared to 109 resources for the median page that doesn’t use a CDN.

To summarize, pages that use a CDN and those that don’t are roughly the same size, contain a similar number of resources, and take almost the same amount of time to fully load. The most noteworthy difference was the amount of time it took for pages to render their primary content: the median CDN-using page took an entire second longer to become interactive than the median non-CDN-using page. (And as countless case studies have proven, when it comes to page speed and business metrics, every second counts.)

This suggests that a key performance-leaching culprit is how the pages themselves are constructed, which is not a problem that CDNs create, nor is it a problem they can fix. More on that in a moment, but first let’s back up a bit and discuss the most common performance challenges that online retailers face…

Four Performance Challenges for Ecommerce Sites

These are the most common performance issues experienced by retail sites. Note that only one of these issues can be mitigated by a content delivery network.

1. Server-side processing

Server-side delays can add precious seconds to your page load. You can speed up processing time by using more powerful servers, implementing a load balancing solution, enabling server-side caching, and optimizing your code.

2. Latency

Latency is the amount of time it takes for a host server to receive, process, and deliver on a request for a page resource (images, CSS files, etc.). Latency depends largely on how far away the user is from the server, and it’s compounded by the number of resources a web page contains.

A CDN addresses the latency problem by caching static page resources in distributed servers (AKA edge caches, points of presence, or PoPs) across a region or worldwide — thereby bringing resources closer to users and reducing round trip time.

Front-end optimization (FEO) techniques, which can be implemented manually or via an automated solution, alleviate latency by consolidating page objects into bundles. For example, a page that starts with 100 objects could see those objects consolidated into 20 bundles. Fewer bundles mean fewer trips to the server, so the total latency hit is greatly reduced. There are also FEO techniques that make the browser cache do a better job of storing files and serving them again where relevant, so that the browser doesn’t have to make repeat calls to the server.

MORE: Latency: 4 Ways You Can Fight Back and Accelerate Your Applications

3. Unoptimized images

Images comprise more than half of the average page’s total weight. Ecommerce sites are especially prone to graphics-induced page bloat, as their pages frequently contain large, high-resolution images. Yet in our research we found that many sites failed to take advantage of opportunities to improve image performance:

  • One out of three sites failed to properly implement image compression.
  • Three out of four sites don’t use progressive JPEGs, which can help improve perceived performance.
  • For many of the sites we studied, the feature image – arguably the most important item on the page, and the item which generally determines TTI – loaded last or almost last. Site owners should ensure that pages are structured to load feature images first.
  • Incorrect image formatting is a common problem. An image that is saved to the wrong format can be several times larger than it would be if saved to the optimal format. This wastes bandwidth, processing time, and cache space. As a general rule of thumb, photos should be in JPEG format, complex graphics should be in PNG-24 format, and simple images with few colors should be in PNG-8 format.

Image optimization can be performed manually or by using an automated front-end optimization solution. A CDN can’t help here.

MORE: Are We Optimizing Our Images Like Cavemen?

4. Third-party scripts

Third-party scripts – such as ads, social widgets, analytics, and trackers – have proliferated wildly in recent years, especially on retail sites. Two years ago, a typical ecommerce page contained around seven third-party scripts. Today, that number is well into the double digits, with some pages including a hundred or more.

Third-party scripts incur a performance penalty (e.g. by forcing the user’s browser to open dozens of connections across multiple hosts), but this isn’t the worst of the problem. Poorly implemented scripts can block the rest of your page from rendering, and can even cause your pages to crash.

MORE: An 11-Step Program to Bulletproof Your Site Against Third-Party Failure

Why Might Sites That Use a CDN Take Longer to Become Interactive Than Those That Don’t?

We already know that leading retailers are more likely to use a CDN than other retailers. It’s also crucial to note that these leading retailers are more likely to build pages that are qualitatively different from other retailers:

  • Leading sites are more likely to incorporate large high-resolution images and other rich content, thereby increasing the size of page resources, if not the quantity of page resources.
  • Leading sites are more likely to feature dynamic content, such as carousels, on the home page. These introduce new complexity (in the form of scripts and other moving parts) to the page, which means more potential to delay rendering the primary content.
  • Leading sites are also more likely to implement third-party marketing scripts, such as trackers and analytic tools, which can have a significant impact on performance.

This strongly suggests that sites that use a CDN have a slower TTI because of how the pages themselves are constructed.

Takeaway: If You’re an Online Retailer, Your Performance Toolkit Should Include FEO and a CDN

If you manage a major ecommerce site, then you don’t need to be told that your pages are larger and more complex than ever. This size and complexity comes with inherent performance risks, and these risks require mitigation on a number of fronts. Relying on a single performance tool to cure all of your performance pains is like relying on a single crutch when you have two broken legs.

Properly deployed, a CDN is an extremely effective tool for solving latency issues: shortening the amount of time it takes for the host server to receive, process, and deliver on a request for a page resource (images, CSS files, etc.). However, latency is just one of several critical issues for modern ecommerce sites. To get the best acceleration results, our ecommerce customers use a combination of solutions: CDN, front-end optimization (such as our FastView solution), application delivery controller (ADC), and in-house engineering.

DOWNLOAD: State of the Union: Ecommerce Page Speed & Web Performance [Spring 2014]

Like this article? Receive similar articles by subscribing to our blog today!


  1. I am keen to understand this metric, as to me it does seem like the most useful one. My question is therefore whether anyone is measuring this, and if so how are they doing so?

    Many thanks!

  2. Hi Sudhanshu. Good question.

    The tests in this study were conducted using an online tool called WebPagetest – http://www.webpagetest.org/ — an open-source project primarily developed and supported by Google. It simulates page load times from a real user’s perspective using real browsers. We tested the home page of every site in the Alexa Retail 500 nine consecutive times. The system automatically clears the cache between tests. The median test result for each home page was recorded and used in our calculations.

    To identify the time to interact (TTI) for each page in the Alexa Retail 100, we used WebPagetest to generate a timed filmstrip view of the median page load for each home page. “Time to interact (TTI)” is defined as the moment that the featured content and primary call-to-action button or menu are rendered in the frame. For ecommerce sites, defining “featured content” was straightforward, as it’s almost always comprised of a hero image or image carousel with a call-to-action in the form of a button or text link on the image/carousel.

    As you may have already deduced, this measurement technique relies partly on using a measurement tool, but partly on hands-on visual assessment by a real person. Right now, there’s no tool that I’m aware of that does all the measurement for you. If there were, I’d be the first one to start using it, as I agree with you — this is the most meaningful user experience metric I’ve found.

  3. So many interesting topics you cover here. In retail there needs to be a change in culture in the way sites are designed. Are sites designed for tablets or touchscreens, many retailers are based on similar platforms and thus you will allot of similarities are performance.

    I think another issue I’m seeing is a lack of identify, is the site for purchasing, is it browsing, is the site for diaplaying ads? your comment on 3rd party tags is interesting because mroe popular retailers look to leverage their site for revenue through ad placement while at the same time impacting performance and sometimes impacting site display.

    Is your home page or web-site your weekly flyer? This get’s into the issue if image size, qualty and lage amount of content.

    Another thing I find is sites are affraid to remove content, afraid to remove unsused Javascript or CSS because they don’t know what it does. Take a look at sites and see how many CSS definitions are defined but never used.

    Don’t combined all the files, combine files based on when they are used and need to be loaded. If you combined a bunch of Javascript libraries that you don’t use until the page is loaded there is no need to load them early, they should be loaded later or deferred so the browser is not busy parsing some huge 500k js file.

    You may have the question that I have my own reverse proxy, do I still need a CDN? I actually depends. If you have a globally of even regionally distributed user population, then yes. If you have SSD drives, your own cache lot’s of ram and the users are centrally dsitributed around your origin you likely won’t see much of an uplift from a CDN but a CDN is typically more than just caching, retailers typically use many more features than just content caching when using as CDN.

    One thing to keep in mind with CDNs is they don’t always have a cache hit, caches expire, content near a client may not be cached yet so you always need a content cache at your origin as well. Some CDNs offer methods that if content is missing from cache it’s forward to a central cache location before hitting origin making it more likely to hit a cache before origin and that only one request is allowed to hit origin and others are queued waiting for the cached content to come back. This helps the cache hti ratio and protects your origin from a flood of requests in the event of a cache miss. Some allow for pre-loading where you can upload new cache instead of letting it expire and hit origin to be refreshed. You should look to finger print static content so you can leverage browser cache and have not cache TTLs because if there is a change you just change the fingerprint and the user would get new content. If have seen cases where there is a 20-30min TTL and in those cases I’m not really sure why a CDN is used except maybe in the case where there are surges and you want the content fresh (<1hour) but don't want alot of htis to the origin. Again I go back to the pre-loadng/updating of cache by pushing or finger-printing of content.

    Love the topic could type more on it, maybe later

  4. Also need to look at BigBox eRetail sites vs pure internet eRetail. Abandonments Online to purchase in store, in-store pickup, loyalty, and proximity of stores are also other factors in online conversion whereas for internet eRetail online stores performance has a larger measureable impact on conversion than eRetail BigBox stores.


Please enter your comment!
Please enter your name here