Loading cached static resources with a CDN

Posted by

A CDN, (or Content Delivery Network), helps us to improve performance of static files, such as images, JavaScript, CSS, videos, and much more. The basic idea is files are cached in a location closer to end users. For example, if you discover that users in Japan have much slower loading times because the images are stored in USA, then you create a CDN that will sync and replicate images to be closer to Japan. This is accomplished with “POP locations”. Azure CDN has 129 POPs, across 65 cities.

Today, we are going to use a CDN to optimize the delivery of the images from our Storage Account to our website. We don’t just want to add a CDN to our project, we want to show the value of adding CDN, so to verify this, we are going to use our new QA environment, “SamLearnsAzureAussieQA”, located in “Australia East”, which we created over the past 2 weeks, (here and here). Our plan is to add a CDN and compare the loading times of images that use the CDN, and images that do not.

Distributing the images to each environment

One minor item we have not completed yet, is that our images are accessed from our shared “data” resource group – we haven’t yet created a process to copy these items to each of the environments. To do this, we are going to create a new release, named “Copy Storage from Data”, and use the “Azure File Copy Extended” task, that copies to and from storage accounts.

In the source section of the task, we set the source subscription, storage account name, and the blob container “partimages”.

In the destination section of the task, we set the destination subscription, storage account name, (using a variable, as this will vary from environment to environment), and the blob container “partimages”. We also check the “recusive copy” option to ensure we copy all folders and all of their contents.

With our dev environment setup, we duplicate the task and set it up for all of our environments. We don’t need to specify an artifact, we will only run this when we need to.

Creating a new CDN resource

Next we start by creating and configuring a new CDN resource in our test East US resource group. We use the “Standard Microsoft” pricing tier and create the CDN.

We then generate the ARM template and deploy the CDN resource with our release. Once this is complete, we look at adding the “end point”. The “end point” is the actual connection between the storage account and our CDN metadata. The CDN end point is what we will use in our web site code to access the images – so in this example we can compare the direct storage account path, verses the CDN endpoint path:

We export this to our ARM template too, and deploy and verify that we have created it correctly. Below you can see the CDN (profile), and half of the CDN endpoint – where we define all of the file types that can be served by the endpoint.

In the second half of the CDN endpoint, we can see the rest of the files we are delivering, as well as the “endpoint origin”, that contains the link back to the storage account. The “endpoint origin” doesn’t accept the “Tag” property, so it doesn’t look as neat as the rest of our resources. You can view the entire ARM template to date, here in our public repo.

Testing the CDN against storage

Finally, it’s time to create a calibrate and test the access time for our websites. For this, we are creating a new test page on our website to show an image from a storage account and a CDN:

The result allows us to see images from both locations, and compare loading time:

When we enable the browser console, and look closer at the “network” tab, we can see our images loading. Now we can really see the CDN benefits. The first, CDN, line, is loading in 28ms, as the image is loading from a local East Coast POP, verses 606ms for the storage blob from Australia.


Today we setup a CDN for our images, seeing a real performance boost, even when we hosted our content in Australia. With our tests complete, we delete the Australia stages from our releases, and drop the resources in our Azure Portal. We could also use CDN for JavaScript and Stylesheets, but we won’t dive into that yet, as our scripts and styles are still minimal and we won’t see a drastic improvement


One comment

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s