What a CDN fixes, and what it hides

A CDN keeps copies of your files in many places and serves each visitor from the nearest one. That removes distance, and distance is real: a request from Cairo to a server in Germany costs about 60ms before anything is computed, on every single file.

What it genuinely fixes

• Latency on static files - images, CSS, JavaScript, fonts - for visitors far from your server.
• Bandwidth peaks, because the origin serves each file once instead of once per visitor.
• A crude but effective shield against traffic floods.
• TLS negotiation, which happens near the visitor instead of across an ocean.

What it does not fix

• A slow query. The HTML still comes from your server, and it is still slow.
• A page that cannot be cached because it is personal to the visitor.
• A first visit to a cold edge, which pays the full trip anyway.

What it hides

This is the part that costs people time. With a CDN in front, your own tests are fast because you keep hitting a cached copy, while a logged-in customer on an uncacheable page gets the real, slow response. Measure the origin directly when you are looking for a bottleneck.

curl -sS -o /dev/null -w 'origin ttfb %{time_starttransfer}\n' \\n     --resolve yourdomain.com:443:203.0.113.10 https://yourdomain.com/

Two things to get right on day one

• The real visitor IP. Every log and every rate limit sees the CDN unless you configure it - see Cloudflare and the real visitor IP.
• Purging. Know how to clear one file and how to clear everything, before a deploy needs it.