At first a content delivery network seems like a great idea, but is it possible that it can actually be detrimental to your sites speed? Lets find out.
NOTE: I've removed some test links as this was written when the blog used a different template.
I was first drawn to the idea of a CDN, not to store a websites assets in edge locations so they are closer to the downloader, but more because most browsers will only download 2 assets at a time from any one domain, Read about it on the YUI blog.
So logically, splitting your websites assets across 2 domains allows 4 parallel downloads for the same page; which should therefore load roughly twice as fast (schoolboy maths I know but the logic is sound). Whether these assets are stored in one location or multiple, there should still be an increase in speed.
So if this is the case, why not split assets across more (sub)domains to allow even more parallel downloads such as css.site.com js.site.com images.site.com? After all, we can create a wildcard dns record to point to the main website and come up with as many as we want dynamically.
The answer there is domain name lookup time. For each domain your website needs to download from, the browser has to look up the location of the domain and then connect to it and download the needed files.
So what happens if we stick to just the two; the main domain and cdn.maindomain, is this a surefire way to make your website faster? Lets put it to the test.
I'm choosing a page on this website which has a number of requests due to the images http://www.robertwent.com/blog/joomla/
- The site is hosted on Amazon Web Services in Ireland.
- I am using webpagetest.org using 50 runs of first view only (to eliminate the affects of caching) and set to chrome browser.
- The page has 23 requests, 19 from the main domain, 1 skype, 1 facebook, 1 google and 1 woopra
So first test of the standard site is Dublin, Ireland
Taking the median of 50 loads
Load time: 3.419s
First byte: 0.735s
Document complete: 3.419s
Fully loaded: 3.443s
This I would assume should be the fastest, being closest to the server serving the site, so now to Dulles, USA and another 50 runs
Load time: 4.927s
First byte: 0.597s
Document complete: 4.927s
Fully loaded: 6.229s
So as expected, longer, nearly twice as long, for a user further away from the host server.
So now lets try loading some of the assets (all images, a big chunk of the page) from the cdn sub-domain located on the same server (exactly the same files but allowing more parallel downloads). So of the 19 assets loading from the domain name, 8 are now loading from the cdn sub-domain, roughly half (the larger half).
Back to Ireland, where I would expect the load time to be longer due to the extra lookup and the proximity to the host.
Load time: 3.401s (-0.018)
First byte: 0.636s (-0.099)
Document complete: 3.401s (-0.018)
Fully loaded: 3.422s (-0.021)
Dulles
Load time: 5.406s (+0.479)
First byte: 0.778s (+0.181)
Document complete: 5.406s (+0.479)
Fully loaded: 5.908s (+0.2321)
So really not what I expected. The tests started as 10 runs but I changed to 50 because I couldn't believe what was happening again and again.
My idea was that the location close to the server would download the assets quick enough that the extra dns lookup would actually slow down the loading when using a CDN. The location further from the server, taking longer to fetch the assets should benefit from the extra parallel downloads but actually loads slower (sometimes significantly by percentage).
So what happens when we change that cdn sub-domain to use Amazon cloudfront? The reason for using cloudfront is that their edge locations are the same as their hosting points so Ireland should not change, where as Dulles VA should be able to download the images faster when they are stored closer in Ashburn VA.
Ireland
Load time: 3.316s (-0.103)
First byte: 0.421s (-0.314)
Document complete: 3.316s (-0.103)
Fully loaded: 3.316s (-0.127)
Dulles
Load time: 4.636s (-0.291)
First byte: 0.739s (+0.142)
Document complete: 4.636s (-0.291)
Fully loaded: 5.686s (-0.543)
So these results are more or less expected. One thing I haven't mentioned yet is server load. The more requests a server gets the longer it will take to process them (in the same way DDOS attacks disable servers full stop). So the fact that the CDN is no longer pointing to the same origin has allowed the resources to be downloaded faster in both cases due to the host server having to do less work.
Note: Now obviously the results of this test are in no way conclusive to anything. They were run on one site with a relatively low number of requests for a cms on a vps whilst no one was looking at it. If a server is under demand then a cdn may be very beneficial for all visitors in all cases.
My point is: Don't blindly believe that a CDN is a fast route to a fast site. In certain circumstances it may even slow it down.
Look at your clients website, think about where it should be hosted and where the people who will be viewing it are located.
First of all, optimize your hosting and setup.
If the site then becomes huge then look at outsourcing some of your content to other locations.
For many websites, the few milliseconds saved could be shaved off in other places first with greater effect.