Akamai Diversity
Home > Web Performance > How your CDN changes the performance of your site

How your CDN changes the performance of your site

Customer expectations are driving ever increasing demands on website performance. Delays are now measured in milliseconds, not seconds, and cause direct financial impact to the business. And yet, despite these pressures for each business to have lightning fast websites and large budgets being spent on performance, most businesses are still plagued with slow sites. The median page load time for the largest 1000 websites is a whopping 6.4 seconds, more than double what most users will tolerate before risks of abandonment! (*According to httparchive.org)

One of the most common challenges when trying to improve performance is the inability to understand and monitor the website properly. While there has been a proliferation of monitoring tools to try to address this problem, they have neglected to monitor the CDN. The CDN plays a key role in accelerating your website (as I'll demonstrate below), but like any other component, only if it is used, configured and tuned properly. Not including CDN in your monitoring prevents your site from reaching maximum performance, and hence is a top performance blocker!

In this series of blogs, I'll help you understand how to incorporate the CDN in your monitoring strategy and thereby improve the performance of your site. For part 1 of this series, we will start by understanding the crucial role the CDN plays in your site's performance profile.

Without the CDN we can simplify the performance profile to the following (see diagram below):

  1. Browser time (request) - Browser prepares and sends a request to an appropriate server
  2. Transport time (request) - The request travels the Internet from browser to your data center or cloud
  3. Back-end time - Request reaches a back-end server (in the data center or cloud) and the server processes the request, usually with a flow that involves many other servers. Once processing is done, the response is sent back
  4. Transport time (response) - The response travels the Internet back to the browser
  5. Browser time (response) - The browser downloads, parses and renders the response

Steps #1 and #5 are monitored by Real-User Monitoring (RUM) tools while step #3 is monitored by Application Performance Management (APM) (and others like DB, network and infrastructure monitoring). #2 and #4 can be deduced from #3 and #5 if you can correlate the metrics between your monitoring tools.

BorisBlog1.png
Now let us look at this flow with a site using a CDN. There are several possible scenarios.

CDN Scenario #1 - The CDN edge has the content for the request cached. The scenario is now:

  1. Browser time (request) - Browser prepares and sends a request to a nearby edge
  2. Transport time (request) - Request travels a short distance on the Internet to the edge
  3. Edge time - The edge receives the request, locates the response in its cache and sends back the response
  4. Transport time (response) - Response travels a short distance on the Internet back to browser
  5. Browser time (response - The browser downloads, parses and renders the response

So in this scenario, the performance should improve due to:

  • No back-end time (the APM metrics don't exist for this flow)
  • Shorter transport time (CDN would need to have these metrics). Now you need metrics from your CDN to monitor #3 effectively.

BorisBlog2.png
Now let's look at the case where the CDN does not have the content cached. I will assume that this CDN provides routing services along with caching (as in the case of Akamai).

CDN scenario #2:

  1. Browser time (request) - Browser prepares and sends a request to a nearby edge
  2. Transport time (request) - The request travels a short distance to a CDN edge server, then is forwarded through an optimal path to the back-end server in the datacenter or cloud
  3. Back-end time - Request reaches a back-end server (in the datacenter or cloud) and the server processes the request, usually with a flow that involves many other servers. Once processing is done, the response is sent back
  4. Transport time (response) - The response travels the optimized Internet path back to the browser, passing through the CDN Edge
  5. Browser time (response) - The browser downloads, parses and renders the response

In this scenario the performance has improved from a non CDN scenario due to:

  • Faster transport time. Both #2 and #4 are significantly faster (especially when parts of the Internet are congested) because the CDN chooses the fastest of multiple routing choices and uses TCP optimization. And now you need metrics from the CDN to monitor #2 and #4 effectively.

BorisBlog3.png
From the two scenarios above, we can see the CDN can potentially make a big difference in website performance and alter the way you need to monitor your site. That's because while you may still see the same metrics of speed between front and back-end, they fail to explain what happens in between and leave you with a large blind spot. You may experience sudden slow downs (or speed ups) of overall page load times with no change in back-end or browser metrics, making it very hard to troubleshoot. This points out a key gap in your overall monitoring strategy and hopefully encourages you to learn how your CDN works and how to monitor it. In the next blog, I will go into the actual monitoring of the CDN along with the rest of your systems, and which key metrics (KPIs) you need to collect from each of your systems and focus on.

Leave a comment