A short guide to a CDN

It comes up on almost every project, usually later than it should. Everything we would tell a client about a CDN in the time it takes to drink a coffee.

Performance work is mostly subtraction, which makes it unpopular and effective. Doing this properly once is usually cheaper than doing it approximately three times.

Why it matters

Distance to the server is real latency. None of that requires a large budget, only a decision and someone to own it. If it only works because one person remembers to do something, it does not work yet.

What good looks like

A CDN also absorbs traffic spikes. There is a version of this that is over-engineered, and it is worth avoiding. Write the reasoning down alongside the decision, because the reasoning is what changes first.

The mistakes we see most

Static sites benefit almost for free. In practice this is a scheduling problem more than a technical one. The practical test is whether someone new to the project could tell, in a minute, that it had been handled.

In practice

Speed is a feature people notice only in its absence, and then they leave rather than complain. Three things worth confirming about a CDN before you move on:

• Someone can say what the current setup is without going to look
• A CDN also absorbs traffic spikes — and you know whether that is true here
• There is a way to tell whether the last change to this helped

Most of the value here comes from doing the first two things, not all of them.