CDN and Hosting: Where Your Site Is Served From
Every request from a browser to your server takes time to travel there and back. A visitor in the same country as the server gets a response in a few milliseconds; one on another continent waits much longer for every round trip, and loading a page takes several: DNS, the TCP and TLS handshakes, the HTML, then the files it references. Where your site is served from therefore sets a floor under how fast it can be.
What a CDN does
A content delivery network (CDN) runs servers in many locations. Visitors connect to the nearest one, which:
- serves cached copies of images, CSS, JavaScript and, if you allow it, whole pages, without contacting your server;
- shortens the handshakes, because TCP and TLS are set up with a nearby edge server;
- absorbs traffic spikes and attacks, since your server only sees requests the edge couldn’t answer;
- often adds modern protocols (HTTP/2 and HTTP/3) and compression without changes on your server.
A CDN helps most when your audience is spread out or far from your server. For a site whose visitors and server are all in one country, a well-configured server close to them may be just as fast, though the caching and protection still help.
How to fix
Cloudflare. Add the site, switch your domain’s name servers to the two Cloudflare assigns, and make sure the web records are proxied (orange cloud). Static files are cached by default; HTML caching needs a cache rule.
Other CDNs (Fastly, Amazon CloudFront, Bunny CDN, Akamai) usually work as a pull zone: you create a CDN host name that fetches from your server, then point your domain at it with a CNAME record:
www.example.com. CNAME example.b-cdn.net.
The bare domain (example.com) can’t hold a CNAME under standard DNS; use your DNS provider’s
alias or “CNAME flattening” feature, or redirect it to www.
Platforms such as Vercel and Netlify serve every site through their own CDN; nothing to add.
Shared hosting with cPanel or Plesk. Many hosts offer a Cloudflare integration in the panel. Otherwise, add the site to a CDN directly as described above.
Whatever the CDN, it can only cache what your server allows. Send long Cache-Control lifetimes
for versioned static files (see Browser Caching), and test that logged-in
pages and carts are not cached for everyone.
Choosing a server location
Without a CDN, host close to most of your visitors: a Turkish shop serving Turkey gains from a server in or near Turkey, while a site with a global audience gains more from a CDN than from any single location. Your analytics show where visitors come from. Time to First Byte is a good way to measure the difference (web.dev on TTFB).
How PerfoMetrix checks this
CDN. We look for headers that CDNs add to the responses we already received while loading the page:
| CDN | Header we recognise |
|---|---|
| Cloudflare | cf-ray |
| Fastly | x-served-by with cache- |
| Amazon CloudFront | x-amz-cf-id |
| Akamai | x-akamai-transformed |
| Vercel | x-vercel-id |
| Netlify | x-nf-request-id |
| Bunny CDN | server: BunnyCDN |
A detected CDN passes. If we find none, the result is information only and doesn’t lower the score: a CDN that doesn’t send one of these headers, or one configured to hide them, won’t be recognised.
Server location. We take the first address the site’s host name resolves to (IPv4 first) and look it up in a local copy of the DB-IP Lite database (CC BY 4.0), which gives the country and the network operator (ASN). No third party is contacted. This is information only.
Keep in mind:
- Behind a CDN, the address is the CDN’s, so the result shows the CDN’s network, not where your origin server is.
- IP geolocation databases are approximate, and an address can be registered in one country and used in another.