Why Websites Keep Copies of Themselves All Over the World

Light in a fiber cable is fast, but it isn't instant. If a website lives on one server in Virginia and you're loading it from Sydney, every request has to cross an ocean and come back. A modern page might need dozens of files (images, scripts, fonts, stylesheets), and all those round trips add up to a page that feels sluggish even on a great connection. You can't make the planet smaller. What you can do is move the files closer to the people asking for them.

That's what a CDN is. Content delivery network. It's a company that runs a lot of servers in a lot of cities (they call them edge servers or points of presence) and keeps copies of your site's files on them. When someone in Sydney visits, they get the logo and the CSS from a server in or near Sydney instead of the one in Virginia. The original server, which everyone calls the origin, only gets bothered when the edge doesn't have what's needed.

The way it usually works is through DNS. You point your domain at the CDN instead of directly at your server. Visitors connect to whichever edge location is closest to them, the edge checks its cache, and if the file is there it sends it right away. If it isn't, the edge fetches it from your origin, hands it to the visitor, and keeps a copy for the next person. That's why the first visit from a new region can be a touch slower and everything after it is quick.

How long the edge keeps a copy is mostly up to you. Your server sends cache headers like Cache-Control: max-age=86400 that say "this is good for a day," and the CDN respects them (or you override them in the CDN's settings). Static stuff like images and versioned JavaScript files can be cached for a long time. Your homepage, maybe not so long. A logged-in user's account page shouldn't be cached at the edge at all, and a decent setup makes sure of that.

Speed is the headline, but honestly it's not the only reason people use one. A few others:

Your origin does a lot less work. If the CDN is serving most of the images and scripts, your little server only handles the requests that actually need it. That can be the difference between a site that falls over when a post goes viral and one that shrugs it off.

They soak up attacks. Big CDNs have enormous amounts of bandwidth spread across the world, so a flood of junk traffic aimed at your site hits their network instead of your one server. Most of them bundle some kind of DDoS protection and a web application firewall for exactly this reason.

HTTPS gets easier and faster. The TLS handshake happens at the nearby edge rather than across the world, and most CDNs will issue and renew certificates for you.

There are trade-offs, and I think people should know them before flipping the switch. Because the CDN terminates HTTPS, it can see your traffic in plain form. You're trusting them with that. You've also added another company that can have an outage, and when a big CDN has a bad day, a surprising chunk of the internet goes down with it. And caching brings its own headaches. You fix a typo, push the change, and the old version keeps showing up because the edge is still holding yesterday's copy. Every CDN has a "purge cache" button for this, and you'll learn where it is quickly.

Do you need one for a personal blog? Not strictly. A small site on a decent server loads fine for most people. But several CDNs have free or very cheap plans, setup is often just changing your nameservers, and you get the HTTPS and attack protection as a bonus. For anything with a global audience or a lot of images, I'd put one in front of it without thinking too hard. Just set your cache headers on purpose instead of hoping the defaults guess right.