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 monsterous websites with
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 monsterously 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
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,
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.
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 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
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
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!
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
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:
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.
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.
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
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.
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
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
down to a minimum, though. Use a single, concatenated and
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.
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.
One of the other great tools that we have in our arsenal for
a build-steps process, typically. A series of related
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
importantly, it will reduce the number of files that need to
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 are also a lot of people that say you should always
for good reason. Reducing file size and reducing the number of
files will help to speed up the load time for a site.
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.
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
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.
Copyright © 2016, Progress Software Corporation and/or its subsidiaries or affiliates. All Rights Reserved.
Progress, Telerik, and certain product names used herein are trademarks or registered trademarks of Progress Software Corporation and/or one of its subsidiaries or affiliates in the U.S. and/or other countries. See Trademarks or appropriate markings.