Home Weblog index

Some thoughts on CDNs

Written on 5 Sep 2016

“Of course you should use a CDN to deliver your JavaScript and CSS content” is considered something of a truism among some developers, and advertising material from CDNs is plentiful, but things are a bit more complex than that.

Performance

The greatest touted advantage of a CDN is faster load times. Because CDNs have worldwide servers, users can fetch a copy of your content from a server nearby which should be faster.

But is this always true?

CDN performance is pretty hard to measure. In fact, I can’t really find any good figures on the web that aren’t produced by a CDN provider (and thus not reliable). My personal experience is checkered, and while a CDN can most certainly improve the load performance, I would be careful in just assuming so.

It is already very easy to serve static content with very high performance using tools such as Varnish. In many cases, this is about as fast (and certainly ‘fast enough’).

Hacks

Any server can be compromised, no matter how secure. It is entirely possible for someone to breach your CDN and inject malicious code.

Stuff like this does happen, for example with Linux Mint this week and externally loaded malware ads are also a thing. There are many, many, more examples to be found.

These events are comparatively rare and usually (but not always!) quickly discovered. But they do happen. It is a risk, and using a CDN increases the attack surface.

An important question here is what sort of website are you developing? What is the maximum damage that can be done? For example, the Plesk interface loads a Facebook ‘like’ button by default, effectively giving Facebook complete control of your server if they decide to take it. The chances that they actually will do this are small, but the potential damage can be huge, and IMHO it’s not worth the risk.

But if you just serve a basic weblog or some such, the worst that can happen is that you serve ads or malware for a while (probably along with thousands of other sites). Not great, but not a disaster either.

Malicious CDNs

In a similar vein, the CDN provider may “go bad” in the future and start inserting adware or such in the CDN. Sourceforge does this with some downloads.

This is chiefly a concern with public CDNs and quite rare, but it does happen. Are you sure that bootstrapcdn.com won’t start serving crap in ten years’ time?

Availability

A CDN may go down for an hour, week, month, or cease operation altogether. If the CDN stops working, your JavaScript and CSS stop working, which basically means that your site stops working.

This is especially a concern for sites you write once for clients and then never look at again. Ideally, they should keep working for as long as possible.

Complexity

The old adage of ‘everything is a fucking DNS problem’ has been replaced with ‘everything is a fucking caching problem’.

Caching is great, but it also adds a lot of complexity. CDNs effectively add another layer of caching, and things can – and do – go wrong here.

Conclusion

Think about the drawbacks, try to optimize your server with Varnish first, and please, measure the actual real-world performance (which is probably easier said than done).

Feedback

You can mail me at martin@arp242.net for feedback etc. No, I don’t have Twitter, but you can use this form to send me an email if you want.



Copyright © 2010-2016 Martin Tournoij <martin@arp242.net>
This document is licensed under a cc-by 4.0 license.