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!

Tammy Everts

As a former senior researcher, writer, and solution evangelist for Radware, Tammy Everts spent years researching the technical, business, and human factor sides of web/application performance. Before joining Radware, Tammy shared her research findings through countless blog posts, presentations, case studies, whitepapers, articles, reports, and infographics for Strangeloop Networks.

Contact Radware Sales

Our experts will answer your questions, assess your needs, and help you understand which products are best for your business.

Already a Customer?

We’re ready to help, whether you need support, additional services, or answers to your questions about our products and solutions.

Get Answers Now from KnowledgeBase
Get Free Online Product Training
Engage with Radware Technical Support
Join the Radware Customer Program


An Online Encyclopedia Of Cyberattack and Cybersecurity Terms

What is WAF?
What is DDoS?
Bot Detection
ARP Spoofing

Get Social

Connect with experts and join the conversation about Radware technologies.

Security Research Center