*NB: Don’t panic. Correlation does not equal causation. More on that later in this post.
This week at Radware, we’ve released our latest research into the performance of the top 500 retail sites. (A little background: Every quarter, we test the load time and page composition of the same set of websites. The goal is to benchmark retail web performance and identify patterns.)
In the four years that we’ve been gathering this data, there have been two persistent trends:
- Pages are getting slower. The median top 500 ecommerce home page takes 10 seconds to load. In spring 2012, the median page loaded in 6.8 seconds. This represents a 47% slowdown in just two years.
- Pages are getting bigger. The median page contains 99 resources and is 1510 KB in size. In other words, a typical page is 20% bigger than it was just six months ago.
While these findings are compelling, I’m most interested in what we discovered when we analyzed how long it takes for pages to render primary content, and whether or not using a content delivery network (CDN) helps pages render their most important content more quickly. Here’s what we found…
Pages are taking longer to serve primary content.
Part of our analysis involved looking at the Time to Interact (TTI) for the top 100 sites. From a user experience perspective, TTI is arguably the most critical metric. It refers to the amount of time it takes for a page’s primary content — usually a feature image with a call-to-action button — to render and become usable. We identified the TTI for each page by looking at a filmstrip that depicts page load frame by frame. (See the example below.)
We found that the median TTI was 5.4 seconds — well short of the ideal render time of 3 seconds or less. In our Summer 2013 State of the Union, we found that the median TTI was 4.9 seconds. The difference between last summer and now may not seem dramatic, but this represents a 10% slowdown in just nine months. This is significant, especially given that this trend seems likely to continue.
While this finding is extremely compelling in and of itself, things get even more interesting when we compare the TTI for sites that use a content delivery network to the TTI for sites that do not…
Using a content delivery network (CDN) correlates to slower Time to Interact, not faster.
Content delivery networks are a well-known performance solution, so our initial expectation was that sites that use a CDN would be at least as fast, if not faster, than sites that don’t. Yet we found the opposite: the time to interact for pages that use a CDN was 5.7 seconds, compared to a TTI of 4.7 seconds for pages that do not use a CDN — a 1000-millisecond difference.
One second may not sound like much, but it can have a big impact on business metrics. In the past, I’ve shared case studies demonstrating that a one-second delay can result in:
- 8.3% increase in bounce rate
- 9.3% fewer page views
- 3.5% decrease in conversions
- 2.1% decrease in cart size
This finding should not be construed as a criticism of CDNs.
CDNs are a proven web performance solution that addresses the problem of latency: 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.
CDNs cure some, but not all, performance pains.
To understand why using a CDN may not always correlate to faster pages, we need to look at the pages themselves.
The first thing to consider is page size. We found that pages that use a CDN and those that do not are roughly comparable in terms of page size and total number of resources: pages that use a CDN tend to use slightly fewer, but slightly fatter, resources, which results in somewhat larger pages overall.
But this small difference in size arguably cannot account for the fact that pages that use a CDN become interactive a full second behind those sites that do not use a CDN. This suggests that the issue is not solely about getting resources to the user faster (i.e. by using a CDN) — it’s about how the pages themselves are built.
Some things to consider about leading sites:
- Leading sites are more likely to use a CDN.
- Leading sites are more likely to incorporate large high-resolution images and other rich content, thereby increasing the size of page resources.
- Leading sites are more likely to implement third-party marketing scripts, such as trackers and analytic tools. Third-party scripts can have a significant impact on performance. Poorly implemented scripts can delay page render, and non-functional scripts can prevent a page from loading.
In other words, sites that use a CDN are likely to contain more rich content and more third-party scripts, two of the greatest performance leeches. For these sites, using a CDN no doubt mitigates some degree of the impact of increased page size and complexity, but a CDN can’t be expected to do all the heavy lifting.
Front-end performance optimization picks up where CDNs leave off.
A CDN isn’t a magic bullet. It can’t fix the entire myriad of web performance problems, which includes:
- Server-side processing.
- Third-party scripts that block the rest of the page from rendering.
- Badly optimized pages, in which non-essential content renders before primary content.
- Unoptimized images (e.g. images that are uncompressed, unconsolidated, non-progressive, and/or in the wrong format).
- Unminified code.
- And many, many more.
This is where front-end performance optimization (FEO) comes in. (I’m aware that I’m probably preaching to the choir here, in which case feel free to stop reading now, and forward this post to ten people you know who need to read it. 🙂 )
CDNs address middle mile performance by bringing resources closer to users. FEO addresses performance at the very front end — where 80-85% of response time happens — so that pages render more efficiently in the browser.
To get the best acceleration results, most of our customers use a combination of front-end optimization (FEO), content delivery network (CDN), application delivery controller (ADC), and in-house engineering. As the table below (which is based on this case study) demonstrates, a multi-pronged performance solution can make pages up to four times faster.
While 75% of the top 100 retail websites use a content delivery network, CDN usage doesn’t correlate to faster load times. Sites that use a CDN took a full second longer to render primary content than their non-CDN-using counterparts. The problem lies not with CDNs, which are an effective weapon in the fight against latency. Instead, the problem lies within the web pages themselves: pages are larger and more complex than ever, and leading retailers are more likely to incorporate performance-leaching content, such as rich media and third-party scripts. The solution lies in adopting an aggressive, multi-pronged solution set that includes a CDN, automated front-end optimization, and in-house engineering.
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.