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.
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.
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.
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.
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.
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.
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 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.
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.
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.
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.
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.
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.
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.
It seems that the concat-and-minify and CDN tools in our tool belt may be a little at odds, though.
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.
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.
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.
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.
About the Author
Subscribe to be the first to get our expert-written articles and tutorials for developers!