Which is better?
I have no idea.
Sorry. That’s not the end of the post, obviously, but really after the time it took to write this, my answer is that I really don’t know. So let’s talk about why I don’t know.
The claim is this: “A CDN is faster!” The idea here is that a CDN will be faster because it lessens the load on your server. Anything that’s being process by another server means less work yours has to do. And that is totally true. Also, many CDNs have worldwide locations, which means someone in India can download your cat video from a nearer server than yours in Michigan. Also, more people have downloaded shared resources (like Google fonts) so it won’t be downloaded again, making their experience faster.
And all that sounds great. But the actual functionality and performance gains are not going to be exactly tit for tat. At first, I thought that since I get a lot of traffic in Brazil, having a CDN that has local servers would be great for them. It was. A little. But it was a lot worse for me. Using my site in the US slowed down measurably. This was because of the latency of the CDN being worse than my own server.
In addition, many site speed tests measure how many URLs you call in your page. Using a CDN ups that by one. It’s minor, but it’s something to consider. There’s also the idea of branding, which a CDN can hurt if you use it wrong (most CDNs will allow you to use cdn.yourdomain.com of course). Using too many servers for a CDN (think of it like cdn1.example.com, cdn2, and so on) can slow down the user experience too and cause overhead with all the DNS lookups.
What’s the alternative? Good caching. And I do think that proper, server side caching is hugely important. But at the same time, the right network for your static files can provide significant improvements. Which is why we always end up back at CDNs.
The real thing to consider is what your content is on that CDN. WordPress is dynamic content and shouldn’t be on a CDN. Images and stylesheets, though, those are perfect for a CDN. You take the traffic and, thus, the load off your server and it becomes faster. Streaming video too.
Which brings us around to the idea of the cloud as a CDN.
But is it faster? Is it better? Is it safer?
Maybe. It certainly can be, but there is no blanket perfect answer for all of us.
Currently I build local but prepare for the possibility of a CDN later on.
3 replies on “CDN vs Local”
+1000
Definitely a CDN can slow down a website. Some sites I’ve seen, however, have enormous amounts of graphics and they really benefit from having a CDN.
This is especially true of sites with very busy periods, running solely on Apache — e.g. just serving up the same few images over and over when people arrive at work and read their emails. I’ve seen a website that was crumbling under the pressure of morning email image access (readership of about 10,000 / day) that suddenly ran very smoothly once the images were moved to a CDN. Probably sticking NginX in front of Apache would have fixed that too, but a CDN was a much simpler solution at the time and also reduced the server traffic.
As usual, “it depends”.
I have used MaxCDN and decided not to renew when tests showed my (very small) site being on average faster with a static domain pointing to my own server, similar to the setup that was described here last week.
As is often the case when web performance is concerned; test the impact (multiple tests from webpagetest.org, using nodes from different locations) of any change and decide based on that hard data instead of assuming “best practices” are always the best solution. The proof of the pudding, after all, is in the eating.
@frank: You get ALL THE POINTS for actually knowing the full phrase re the proof of the pudding.
That’s one of my wife’s buggaboos 😉