There’s no doubt that JavaScript, CSS, images and other resources are becoming larger and larger and HUGELY McHUGENATOR sized these days (just take a look at any popular website you visit!). To make matters worse, though, we also have more people accessing these monstrous websites with 50megs of animated jiffs (pronounced “gif”), 10megs of JavaScript and more CSS than an MS-Word document’s “export to HTML”.

Things are a bit of a mess, quite frankly. But there’s hope, even with the monstrously sized sites and ever-increasing number of mobile users. Content-Delivery Networks (CDNs), while not a silver bullet by any means, can help you to reduce the amount of time that it takes to deliver your website assets around the world.

What Is A CDN?

Basically, a Content Delivery Network is a geographically distributed network of computer that deliver static content to users that are close to the actual servers.

Think of it this way… say a user is sitting in Sofia, Bulgaria, trying to download the HTML, CSS, JavaScript and images from your website that is hosted on a server in Dallas, Texas. You could say “this is great! I’m getting global traffic to my app!” and you would be correct. But I’ll be the user is currently saying “this is terrible! It took nearly a minute to download this page and show up in my browser!”

There goes your happy user, all kinds of mad and running to a competitor that has content delivered from a server that is geographically close to them.

Why? Because of network latency.

What’s Latency Got To Do With It?

The Earth is not a small place. Electrons and light can only travel around it so quickly. Now add in a series of a dozen or a hundred computers that each need to interpret billions of electronics and light pulses, to transfer your data around the world.

The net result is a massive slowdown of data transfer, even for relatively small files. And you already know you’re not dealing with small files or a small number of files.

100 Milliseconds To Respond

The ultimate test in how “slow” a website or any other software feels, from a user’s perspective, is the 100 millisecond (100ms) test. Anything beyond 100ms for a response, and the person looking at the screen will perceive delay.

Now this isn’t to say that the user will immediately move on after only 1/10th of a second. I think an average user would wait a little longer to start getting a response - which is another good point. You don’t necessarily have to complete the response within 100ms. You just need to put something in front of the user that tells them the system is doing something. This could be a spinner, a loading screen, or any number of things that tells the user the system is working. Once you have the first critical response in front of the user, you have significantly more time available to get the job done.

Reducing Latency With Servers That Are Close To The User

With only a few seconds to be considered “responsive”, you need your content to be delivered to an end user as quickly as possible. This means you need to serve content to them from servers that are close to them, geographically, as possible. The job of a CDN is to do exactly that.

You may not end up with a server in each town - but that’s ok. Even with a little bit of latency, having data travel a few hundred miles is a pretty quick trip compared to a few thousand miles.

Caching From The Same Source, Different Sites

Another of the primary benefits of using a CDN for a common file or library, is your browser’s cache. When your browser grabs jQuery from a commonly used CDN, for example, it can cache that individual file from that CDN. If another website requests the same file from the same CDN, the browser doesn’t have to go out and download the same file again. It can use the existing, cached version of that file.

This means that a user who is hitting your website, with your website referencing jQuery and other common libraries from a common CDN, may have a faster load time because of another website that they used! That’s a pretty big benefit when you consider how many websites use jQuery… a browser only having to download it once, and then re-use it across thousands of websites… that’s a huge savings in download time!

Some Popular Libraries On Some Popular CDNs

The use of CDNs has grown significantly in the last few years, as a response to the large files that people are serving up. And with JavaScript libraries and frameworks becoming more popular, they are also showing up on CDN servers that can be used and contributed to the general public.

Some good examples of existing CDNs include:

Google’s CDN, from which you can find jQuery, AngularJS, Dojo, Prototype and more. Google’s CDN is a bit closed, though. You can get stuff from there, but you can’t contribute to it.

Microsoft has their own CDN, of course. You can also get jQuery here, along with KnockoutJS and several other things that Microsoft builds / uses. Once again, Microsoft’s CDN is a bit closed.

Then there’s CDNJS - a more open system with far more files to serve. In addition to the very large number of libraries that you can get from this CDN, though, you can also contribute to it by submitting issues / pull requests to the CDNJS Github repository.

Telerik and Kendo UI have their own CDN. Any time you look at KendoUI.com, you will be served up some files from our CDN. You can use Kendo UI’s CDN in your Kendo UI projects, too (assuming you have a valid license for Kendo UI, of course). In fact, if you’re using the ASP.NET MVC wrappers, you can choose this as an option in the myriad of configuration options for the wrapper’s project templates.

And of course there are a ton of great CDN systems that you can use for your content. There are CDN services available from a good number of very large players in the industry, and they are pretty darn cheap when you’re talking about sending down a few small files to help speed up your site. Just do a bit of searchinig and you’ll find plenty of examples out there.

So, When Should I Use A CDN?

Here’s the kicker to all of this: just because you can use a CDN doesn’t mean you should. Like any other tool that we have in our toolbelt, a CDN is not intended to be the end-all-solution to our problems. No, there are times when it just doens’t make sense to use one.

Dynamic Content: Nope.

The first place that you don’t want to use a CDN is dynamic content. Dynamic content is the stuff that changes whenever someone loads a page. It’s the live data, the raw, server-side manipulated HTML, and any other bits that depend on your servers being able to process the request from the user and creates a different response based on the user and request parameters.

If you’re lookiing for a way to CDN your data-grid of customers, for the user to sort and page, stop. That’s not what you want to be doing.

Static Content: Yes!

The major thing that you want to be hosting on a CDN is static content. Content that changes very little - as in, it requires a redeployment of the content to be changed. This is typically your CSS, JavaScript and images. These are things that should not be dynamically generated in most cases. Of course there are exceptions to this, and when you run in to one of these exceptions you will need to stop putting that content on the CDN.

Intranet Apps: Probably Not.

Building an application that needs to be delivered via a corporate LAN / Intranet is also not a good candidate for using a CDN. Remember, your customers need to be hampered by geographic distribution and distance from your servers for a CDN to make the most sense.

If you’re building a web site that is delivered from internal servers, there is a less likely scenario of servers being too far away for the end user to be happy. Plus, internal applications tend to have a “use it, or else” policy (which is not a bad thing, by the way), making it easy for someone sitting in a remote office to just suck it up and use the “slow” load time of the internal network resources.

The only time I would recommend using a CDN for internal applications, is when you have a workforce that is spread throughout the world and there are resources that can be made accessible to the public. Libraries like jQuery, Angular, Kendo UI and others can be good examples of mixing an intranet app with a public CDN.

Sites Targeted At Mobile Devices: Maybe… But, Only If…

Mobile devices are the go-anwywhere computers of our age. This means they will be about as wide-spread around the world as you can get. But mobile devices tend to have another limiting factor in them: cellular network speed and latency.

Every request for a file from a website, while viewed on a mobile network, has to endure the same amount of latency as each request before and after it. Mobile networks are notoriously slow in the latency arena. There’s just no way around this.

A better bet for sites that target mobile devices, is to reduce the number of files being delivered to the device. The closer you can get to the magic number one (1), the better. There are tradeoffs to this, though. You’ll probably want clean separation of CSS and HTML, and you’ll probably want some images and some JavaScript to make it look nice. Keep the number of files down to a minimum, though. Use a single, concatenated and minified JavaScript file. Optimize images for the web to reduce file size. Keep your CSS clean and sane, without shadows and other things that kill mobile performance. There’s a ton of tips out there for handling mobile devices.

Once you are optimizing your mobile website to deliver as few files as possible, then you should consider using a CDN for that site. Get the rest of your house in order before you worry about that, though. There are potentially more performance gains to be had in those other areas, initially.

Still Other Things To Consider

This is not an exhaustive list of when you should use a CDN or not. There are going to be other scenarios to consider, other constraints, other aspects of the target audience, and much more that needs to be taken in to consideration. Hopefully this little list will get you started in thinking about when you should use a CDN, though.

CDN vs Concat-And-Minify

One of the other great tools that we have in our arsenal for JavaScript and CSS files, is that of concat-and-minify. This is a build-steps process, typically. A series of related JavaScript files are contenated in to a single file and then run through a minifier such as UlgifyJS. The end result is a much smaller file, typically with a “.min” suffix somewhere in the name. CSS files often have the same process applied to them as well. This can reduce the file size of JavaScript and CSS significantly, but perhaps more importantly, it will reduce the number of files that need to be downloaded.

It seems that the concat-and-minify and CDN tools in our tool belt may be a little at odds, though.

The “Always CDN jQuery” Camp

There are a lot of people that say you should always use a CDN for libraries like jQuery (and other popular projects, as well). They say this for good reason. Using a CDN, as noted already, can reduce latency and allow browsers to cache a common file so it doesn’t even have to load it from a server.

The “Always Concat And Minify” Camp

There are also a lot of people that say you should always concat and minify your JavaScript and CSS. This is also said for good reason. Reducing file size and reducing the number of files will help to speed up the load time for a site.

A Third, Viable Option: The “Do Both” Camp

There’s a third camp, here, that says you should do both. You should use a CDN and you should concat and minify your files. The conflict comes in to play when you talk about the benefits of a CDN with a library like jQuery vs the benefits of sending only a single file down to the browser.

Ultimately, It Depends

When you have an app that depends on jQuery, it would be beneficial to use a CDN for jQuery. This allows the browser to cache the file from that CDN. When the browser sees this file being requested from this CDN, it can grab the already downloaded copy instead of loading it from the server. But loading a separate file, even if it’s from the local storage on the device (mobile, desktop, laptop or otherwise) does incur some latency in file reads if nothing else. Browsers also tend to load JavaScript synchronously, potentially adding on to the perceived slowness.

So you might want to concat and minify jQuery in to your single .js file that you deliver to a browser. This ensures that the penalty for having a browser load multiple files is avoided. Except now you’re forcing the browser to download jQuery with all the other code for your app. You could have avoided this extra 32k of download by using a CDN.

So what do you do? This is where there is no clear answer, unforunately. Like everything else in software development, the only valid answer is “it depends”.

If you have to blindly choose CDN vs concat-and-minify, then just pick one. But if you have the luxury of some time and testing, then I would really recommend trying both and seeing which one produces the best results for you specific users.

A CDN Is A Great Tool. Use One.

CDNs are tools that can help you reduce the load time and latency in delivering content to your users. They certainly aren’t the only tool we need to help speed up our sites, but they are an increasingly important one. Take some time, do some research, and learn a little bit about how to use them effectively. It will be worth your time and effort when your users are suddenly happy about your site loading faster.