Chapter 9. Content Delivery Networks
This chapter covers
- CDN options
- Domain sharding
- Developing with a CDN
Every time you open a browser and request a URL, you’re connecting to a server that could be located thousands of miles away. Each request you make might have to make a round-trip to a server that’s halfway around the world! If you host your website in a data center in New York and a user connects to your site from Sydney, each HTTP request travels a very long distance. Each round-trip takes time, and even though it may only amount to milliseconds, it all adds up.
It’s important to keep in mind who might be accessing your website—and from where. While the majority of users might be located in your own country, your website can be accessed by users who live elsewhere. A Content Delivery Network (CDN) allows users to access content on servers that are relatively close to them, minimizing the distance a request travels and reducing your site’s web page load times. A CDN improves your chances of serving the same website experience to all your users, regardless of their location. Happy users = happy developers!
9.1. What is a Content Delivery Network?
Content Delivery Networks, or CDNs as they are better known, are a collection of server nodes located around the world that contain a clone of your site’s static files. Because static files such as images, JavaScript, and CSS don’t change often, they’re ideal for CDNs.
Figure 9.1 shows a collection of nodes that might represent a typical CDN. Many CDN services will have a similar collection of nodes around the world. When you upload your content onto a CDN, it gets cloned and propagated to all the other servers in its network throughout the world. Each time a user requests one of these files, they get served the file from the node closest to them. If a user in Sydney requests a file, they will receive the file from a server in Sydney instead of a server in New York. This simple change is highly effective in reducing load times.
Figure 9.1. A typical collection of CDN nodes scattered in different locations around the world
The benefits of using a CDN extend far beyond rapid response times. Using a CDN also reduces the number of requests served from your website, thereby reducing the amount of bandwidth your site requires. You’ll still get all the benefits of caching and compression, along with a wider network that reduces the amount of bandwidth consumed by your website. But because your website’s static content will be served from such a wide network, it also means your website’s load will be well-balanced for your users, wherever they are around the world. Say, for example, you are about to launch a new product online and you expect a very high volume of traffic. This large, distributed network of nodes is much better equipped to handle high simultaneous traffic loads.
You might think only large companies can afford to use a CDN, but this is not the case. CDN technology is commercially available to all developers and it’s affordable. You only pay for the file storage space and outgoing bandwidth that you use. I use an affordable and easy-to-use commercial CDN for my personal blog.
In chapter 2, you investigated WebPagetest, an online web performance tool that produces waterfall charts. WebPagetest is a great tool that allows you to run a free website speed test from multiple locations around the globe. This is perfect if you need to test a CDN. I’ll repeat: when you’re developing your site, remember that users will be accessing your site from all over the world. It’s important for you to give them the same speed and performance as the users who are close to the hosting server.
Let’s take a look at how a CDN can improve your worldwide performance by using WebPagetest. First, navigate to www.webpagetest.org and enter the URL for my personal blog: www.deanhume.com. Choose a test location in Geneva, Switzerland, and choose IE8 as your test browser.
Once the test starts, it will be queued and run from that test location. When the test finishes running, you’ll be presented with something similar to what you see in figure 9.2.
Figure 9.2. A web page performance test for www.deanhume.com against a test location in Geneva, Switzerland
What you’re looking for here is the location of the closest CDN node that served the static content. If you choose the first view (on an empty cache), and navigate to the request details, it will produce a table similar to figure 9.3.
Figure 9.3. The request details for deanhume.com against a test location in Geneva, Switzerland
In figure 9.3 notice the locations of the requests being served from the CDN. The test location is in Geneva, Switzerland, and the location of the files being served is Switzerland. Even though the dynamic content on my site is being hosted in a datacenter in New York, I’m serving the static content to a Swiss user from a computer in Switzerland!
Now my Swiss user will receive their content from a server that is located geographically close to them, which saves a round-trip to a distant shore. Reducing the number of network hops also reduces latency, meaning you’re able to speed up the time it takes for a web page to load.
9.2. CDN options
There are many CDN options available. Almost all of them are extremely easy to set up, and you can be up and running in minutes. Table 9.1 shows a few of my favorite commercial CDNs.
Table 9.1. A few more widely known commercial CDNs. Many companies offer an affordable CDN service.
|
CDN Name |
Website |
|---|---|
| Amazon Cloudfront | http://aws.amazon.com/cloudfront/ |
| Rackspace CDN | www.rackspace.com/cloud/public/files/ |
| Windows Azure CDN | www.windowsazure.com |
| Akamai CDN | www.akamai.com/ |
| CacheFly | www.cachefly.com/ |
| EdgeCast | www.edgecast.com/ |
| GoGrid CDN | www.gogrid.com/products/infrastructure-cdn |
Each commercial CDN offers a competitive pricing structure as well as a dedicated network infrastructure. Because each company has its own requirements, specific CDN setup techniques will be left for you to discover.
You shouldn’t feel constrained by my favorites in table 9.1. If you discover other CDN providers, investigate them, try them out. Go out and get a CDN! It will make a big difference to your website’s performance around the world. CDN storage is cheap, so play with a few of them and choose the CDN that best suits your needs and budget.
9.3. Domain sharding
In chapter 6 you learned HTML optimization techniques to help you improve how a browser renders your web pages. One topic was the browser’s ability to download a web page’s components in parallel. Most browsers limit the number of parallel connections opened to a particular domain. Figure 9.4 shows a browser downloading two images at a time in parallel. To overcome this limitation, you can apply a technique called domain sharding, which splits resources across domains. If a browser allows a limited number of connections per domain, add another domain with a CDN. The CDN is as another domain from which you’re serving static content. Newer browsers allow a much higher number of parallel downloads, but this technique is still recommended because you get the added benefits of a CDN as well as a higher number of parallel downloads for older browsers.
Figure 9.4. Most browsers are only able to download from a limited number of connections per domain.
Figure 9.5 contains a snapshot of the network components for Amazon.com. Note that in the figure the main HTML web page is being downloaded from www.amazon.com, yet the static files are being downloaded from two separate domains. From a simple investigation of the network downloads, it seems that the three following domains are being used to serve the static content from amazon.com:
Figure 9.5. A snapshot of the network components that are downloaded when you visit www.amazon.com.
- Amazon.com
- G-ecx.images-amazon.com
- Z-ecx.images-amazon.com
Yahoo! released a study in 2007 that recommends sharding across at least two domains.[1] The study notes that performance starts to degrade above four domains; that’s why a good compromise is two domains. Maximizing parallel downloads comes at a cost, and depending on your bandwidth and CPU speed, too many parallel downloads can degrade performance.
1 Tenni Theurer, “Performance Research, Part 4: Maximizing Parallel Downloads in the Carpool Lane,” YUI blog, April 11, 2007, http://yuiblog.com/blog/2007/04/11/performance-research-part-4/.
CDNs are becoming more and more affordable and freely available. You’ll find many of the top-performing websites today use domain sharding to provide a faster platform for their static content. If you combine the power of a CDN’s geographical node base with the browser’s ability to download more efficiently from multiple domains, your website’s load times will drastically improve. This improvement will be observed across all browsers, both old and new.
9.4. Developing with a CDN
If you open the Surf Store application and run it against the Yahoo! YSlow web performance tool, the performance score for the site is 91 out of 100. This is a good score, but the tool grades each suggestion separately, so you still score an F for a Content Delivery Network. I reckon we can do better! Figure 9.6 shows the result that the Yahoo! YSlow tool produces.
Figure 9.6. The Yahoo! YSlow score for the Surf Store application still needs some improvement.
Adding your website components to a CDN is an easy transition. But depending on your development environment, it may not always be advisable to work directly off a CDN while your website is still under development. You may have a development team that needs to access these files constantly, which can add to your bandwidth bills. It’s best to work off local copies while in development, then switch to the CDN once the website is in production. Next, you’ll learn a technique in both ASP.NET MVC and ASP.NET Web Forms that will allow you to work with a CDN while still in development.
9.4.1. ASP.NET MVC HTML helper for CDN development
You can add an HTML helper to your sample application that contains a switch between your development content and the production content on a CDN. Whether or not you work on a team, it can still be beneficial to use development content before moving to production content when your site goes live. The key to using this technique is matching the local file structure to that of your CDN. This makes it easier to navigate between folders and allows you to easily map to certain files. Let’s run through an example that makes use of this technique.
Begin by adding a key to the Web.config file with the location of the CDN.
Listing 9.1. Adding the CDN URL to the Web.config file
You added the CDN URL to the appSettings section of the Web.config file. Next you’re going to use this CDN URL to build a path for your content, depending on whether you’re in Release or Debug mode. Start by adding a new class file, called CdnUtils.cs, to the solution. Figure 9.7 shows the newly created class file in the Solution Explorer of the sample application.
Figure 9.7. A new class file is added to the SurfStoreApp MVC project.
Inside this new class, add the code in the following listing.
Listing 9.2. Using the CDN URL in Debug/Release mode
The code uses the content path that is passed in and updates it with the CDN URL, depending on whether the code is in Release mode. If you’re still in Debug mode, the code will run as normal and return the content path that was passed in. Only if you’re in Release mode will the CDN URL be appended to the content path.
Finally, update your views to use the new HTML helper method you wrote. Instead of calling an HTML image tag like so:
<img src="@Url.Content("~/Content/Images/surfing-homepage.png")" />
You now use:
<img src="@Html.CdnUrl("~/Content/Images/surfing-homepage.png")" />
And that will produce the following HTML when the web page is rendered:
<img src="http://88600723r47.cf3.rackcdn.com/Content/Images/ surfing-homepage.png" />
This HTML helper will allow you to switch easily between the CDN and your local file storage.
9.4.2. ASP.NET Web Forms helper for CDN development
Whether or not you work in a team environment, it can still be beneficial to use local content before moving to using CDN content when your site goes live. The key to using this technique is matching the local file structure to that of your CDN. This makes it easier to navigate between folders and allows you to easily map to certain files. You’re about to run through an example using ASP.NET that uses this technique.
Start by adding a key to the Web.config file with the location of the CDN.
Listing 9.3. Adding the CDN URL to the Web.config
You added the CDN URL to the Web.config file’s appSettings section. Next you’re going to use the CDN URL to build a path for your content depending on whether you’re in Release or Debug mode. Start off by adding a new class file called CdnUtils.cs to the solution. Figure 9.8 shows the newly created class file in the Solution Explorer of the sample application.
Figure 9.8. A new class file is added to the SurfStoreApp project.
Inside this new class, add this code.
Listing 9.4. Using the CDN URL in Debug/Release mode
The code uses the passed in content path and updates it with the CDN URL, depending on whether or not the code is in Release mode. If you’re still in Debug mode, the code will run as normal and return the content path that was passed in. The CDN URL will be appended to the content path only if you’re in Release mode.
Finally, you need to update your views to use the new helper method that you wrote. Instead of calling an HTML image tag like so:
<img src="Images/surfing-homepage.png" />
You now use:
<img src="<%= SurfStoreApp.Utils.CdnUtils.CdnUrl("Images/
surfing-homepage.png") %>" />
This will produce the following HTML when the web page is rendered:
<img src="http://88600723r47.cf3.rackcdn.com/Content/Images/surfing-homepage.png" />
By making this simple change, you’re making sure you’re developing and using local content first; this might save you a hefty CDN bill!
9.5. The results
You have updated the Surf Store application in both solutions (MVC and Web Forms) to use the new CDN for its static content. When you ran the sample application against the Yahoo! YSlow tool, the previous performance score came in at 91 out of 100. Before running YSlow against the sample application again, you need to tell YSlow the name of your CDN. The tool doesn’t have a known list of CDNs it uses to validate against, but it does give you the option to add your own CDNs to the list. In figure 9.9, the YSlow tool has detected that content is being served from two servers. In this case, you’ll add the CDN but nothing else from the local host, as this would most likely be our hosting server.
Figure 9.9. The latest YSlow performance result. The YSlow tool gives you the ability to add your own CDNs to a list of approved CDNs.
Once the CDN has been added to the list and the tool is rerun, the performance score improves. Figure 9.10 shows you now have an overall performance score of 99 out of 100! The CDN rule suggestion has gone from an F to an A.
Figure 9.10. The YSlow performance score after moving the content onto a CDN
If you run the Surf Store website against the Google PageSpeed tool, you’ll get a similar result. Figure 9.11 shows a performance score of 99 out of 100! This is pretty impressive considering we’ve taken this website from a starting score of 57 to a score of 99 out of 100.
Figure 9.11. The Google PageSpeed score after moving the static content to a CDN.
9.6. Summary
Every time you open a web page, you could be making a round-trip to a server halfway around the world to retrieve the required components to load the page. These round-trips take time, and not surprisingly, the farther away you are from the hosting server, the longer it will take to download the web page components. You can improve this delay with a CDN.
In this chapter you’ve learned about the benefits of using a CDN to serve static components to your users from a server that is geographically closer to them. Instead of making a round-trip to a server that could be many miles away, your users will receive content from a server node that is a lot closer. You’ve learned about domain sharding and how you can use it to overcome the browser’s limits when it comes to downloading multiple resources in parallel. By using an extra domain for your site, the browser is able to download more components in parallel. A CDN can also be a great way to add an extra domain to your application that will help with domain sharding. In this chapter we implemented a technique in the Surf Store application that allowed you to easily switch between the content on a CDN and the local content while your site is in development. This technique will hopefully save you money on your CDN bandwidth bills.
Our Surf Store application now has an overall performance score of 99 out of 100 across both the Google PageSpeed and Yahoo! YSlow tools. Not bad considering we started off with a lowly 57 out of 100. The overall load time of the page has been cut in half and the total page weight was also reduced significantly. In the next part of this book, we shift our focus toward server-side code and look at ways that we can leverage the power of the server to further improve page performance.