Five mistakes teams make with a CDN
Most teams know this matters. Fewer have decided who owns it. These are the ones we run into repeatedly when we audit a CDN.
Performance work is mostly subtraction, which makes it unpopular and effective. Assume whoever inherits this will have half your context and none of your patience.
What to watch for
- Treating it as a launch task rather than an ongoing one
- Assuming someone else already owns it
- Distance to the server is real latency
- A CDN also absorbs traffic spikes
- Never checking whether the fix actually worked
Static sites benefit almost for free. It is worth being explicit about, because assumptions differ quietly. It rarely shows up as a line item, which is exactly why it slips.
A reasonable first step
What this looks like day to day
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
The point is not perfection, it is knowing which of these you have consciously chosen to skip.