A CDN: the questions we get asked most
It is rarely the thing that gets a project approved, and often the thing that decides how it goes. The questions about a CDN that come up most often on our calls.
Speed is a feature people notice only in its absence, and then they leave rather than complain. If it only works because one person remembers to do something, it does not work yet.
Do we need to care about this?
Distance to the server is real latency. None of that requires a large budget, only a decision and someone to own it. Check it against what you would want a competitor's site to get wrong.
Can it wait until after launch?
Occasionally. More often the post-launch version costs several times the pre-launch one. The teams that handle this well are rarely the ones with the biggest budgets.
How do we know it is working?
Static sites benefit almost for free. Where this goes wrong is almost never a lack of knowledge. Write the reasoning down alongside the decision, because the reasoning is what changes first.
How to tell if yours is fine
Performance work is mostly subtraction, which makes it unpopular and effective. 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
If any of that sounds like a description of your current setup, it is fixable.