When creating and launching a new site, the question of whether to use a CDN (content delivery network) and which one to use will inevitably come up. So we’re going to try and identify the different ways in which a CDN can be used, and when you really need one.

What is a CDN?
We’re going to assume you basically already know what a CDN is. If not maybe take a look at this infographic from wpbeginner first?

To briefly summarize, a CDN is a service that will cache your site content and serve it from a point in their delivery network that’s closest to the end-user — therefore both lowering the load on your regular web server and speeding things up for the browser. So the CDN will proxy the content from your regular webserver and then store & distribute that content amongst its own network and optimize delivery by location.

Sounds like a no-brainer, right? Well… maybe. Once we dig in a little more it’s clear there’s a lot of ways you can use a CDN and lot of different kinds of CDNs.

The main functions of a CDN are:

1. Content proxy-caching (the aforementioned grabbing from your regular webserver and storing & delivering)
2. Content optimization (minification, compression, bundling).
3. Edge delivery (delivery to the end-user based on the nearest server available in the CDN).

and the main things you might consider putting through your CDN (in order of increasing difficulty) are:

1. Common 3rd-party libraries like JavaScript, CSS, etc.
2. Commonly used static content like navigation buttons, logos, footer stuff, etc.
3. Less commonly used static content like per-product images.
4. Dynamic content like HTML page contents.

So do I need one or not?

Well, depends on what’s slowing your site down and if it really is “seeming slow” to your users. One thing we always warn against is unnecessary optimization. A CDN is a great tool if you need it, but it adds cost and complexity to your project, so unless you see a problem with speed or delivery to fix, focus on other stuff first!

Here’s some questions to ask yourself before making the jump into a CDN:

– Does my site feel slow to my users? What does your full-page site speed reporting baseline look like? (checkout our site speed metrics article for more)
– Am I heavily loading my primary web server(s)?
– Do I have a lot of visitors that are physically far away from my primary web server?

If you are answering “yes” to any of those questions then probably it is time for a CDN.

Option 1. Maybe just a shared-library CDN?

One case in which I think a CDN should almost always be used is for common third-party libraries. So if you’re using jquery, or angular, or something common a lot of sites use, definitely load it from a CDN! There’s plenty of free shared-library CDNs out there for this — people commonly use google, jquery code, microsoft, etc. Aside from the already stated benefits of a CDN, the other big benefit with using a common library from a common 3rd-party CDN is that our end-user probably already will have that library cached from some other site they’ve been to using that same CDN. Then they don’t have to download anything!

Another benefit is that included in this way you know the code is what it says it is; if the file says jquery 2.1 from google or code.jquery.com you can be pretty sure it’s that and that alone, not some locally modified version that a previous developer bundled with some other files or something that’s been locally modified for some hacky reason.

But that’s just one or two files? What about all my other javascript libs?
So maybe your site uses a lot of Javascript libraries. You’ve got the google jquery include working, but you’re still locally hosting a myriad of jquery plugins, etc. Then maybe you want the next-level of a shared-library CDN like cdnjs. cdnjs and other similar services host a lot more libraries and probably have whatever library you are using (maybe if they don’t you might want to consider using a more common library?).

Option 2. Just cache my static/commonly-used content?

So let’s say #1 isn’t enough. The site still reports as a little slow or there are other issues. The next step is to start caching all the non-dynamic parts of a page you can. This is the most common scenario and what I think of when someone says “I need a CDN”.

There’s two main ways to attack this — either point your www. site at your CDN service or use a subdomain like cdn.yrdomain.com that points at your CDN and then in your HTML refer to those common elements from the subdomain (e.g. src=”//cdn.yrdomain.com/logo.png”). The former means that you are technically running all your traffic through your CDN, but only caching the static stuff.

Your approach will depend on your existing code/cms/stack/etc., so there’s no way to say which way will be best for your specific scenario. In general however the “www.” approach via a service like Cloudflare that allows simple setup of URL-based forwarding rules will be easiest.

However if you’re using a CMS like WordPress then you should consider the subdomain option using W3 Total Cache plugin along with a CDN that it directly supports (which is most of the big ones including MaxCDN — which even offers a coupon for that plugin’s users).

Option 3. I need everything cached!

You’re sure you don’t just want to do option #1 or option #2? Well, maybe you’ve got a ton of traffic. Or really high performance requirements. It’s time to start caching everything you can. This means usually you have to have your main www. site pointed at your CDN or load balancer that parcels out to your CDN, and you need to start paying a lot of attention to your TTL (time-to-live) settings on different pages of the site and start looking at exclusions for different user states.

In the case of a big site with a ton of traffic this is going to get very custom very quickly, and is well beyond the scope of this article. If it’s just that you really want to squeeze every millisecond out of performance you can and you’re not worried about logged-in users and dynamic content, then use a CDN like CloudFront or CloudFlare that you can point your www. site at and let it just cache everything (but seriously that should not be a common use-case).

Which CDN do I use?

Aside from the shared-library CDNs, I’ve mentioned CloudFlare, CloudFront & MaxCDN above. If you happen to be on Amazon AWS (EC2) already, then go ahead and check out CloudFront. If you’re with Media Temple go ahead and check out your free CloudFlare account. If you’re somewhere else then maybe check out MaxCDN or CloudFlare first. I’m focusing on ones that are the most cost-effective and user-friendly, certainly if you are running big enterprise site you may be more interested in Akamai or Limelight first, but in my experience they are not going to be so plug & play as options like CloudFlare.

If you’re wondering which CDN is the fastest, Cedexis reports on that — but the top 15 are all pretty fast and for most people the difference between their #1 ranked Akamai with a 44ms median vs. #12 Cloudfront with a 48ms median is a negligible difference for most of us, so pay attention to the features and price that fit your needs before worrying too much about speed.

Share this post: on Twitter on Facebook on LinkedIn