A CDN (content delivery network) caches copies of your site’s files on servers around the world. Visitors download from a nearby edge server instead of your VPS. Done right, it makes pages load faster far from your server, reduces load and bandwidth on the origin, and absorbs traffic spikes.

What a CDN actually speeds up

  • Static assets (images, CSS, JS, fonts, video) — served from the edge, close to visitors. The biggest win.
  • Cacheable pages (static sites, blogs with page caching) — if you allow the CDN to cache HTML.
  • TLS handshakes — terminated at the nearby edge, which shortens connection setup for distant visitors.

What it doesn’t speed up by itself: dynamic, uncacheable requests (logged-in dashboards, checkouts, APIs). Those still travel to your server. For them, server location and application speed matter — see choosing a VPS location.

When a CDN is worth it

  • Visitors spread across continents.
  • Media-heavy pages.
  • Traffic spikes (launches, news, viral posts).
  • Limited origin bandwidth or monthly transfer.

Less important when your audience is concentrated near your server and pages are light — a well-placed VPS with good caching may already be fast.

Two ways to set one up

1. Proxy (reverse-proxy) CDN — change your DNS so the whole domain goes through the CDN (e.g. Cloudflare’s orange-cloud proxy). Everything passes through the edge; cache rules decide what’s stored. Easiest to set up. See Cloudflare with your VPS.

2. Asset/pull CDN on a subdomain — keep example.com pointing at your server, and serve assets from cdn.example.com, which pulls from your origin. Many CMS plugins rewrite asset URLs automatically. You control exactly what goes through the CDN.

Caching rules that work

  • Hashed assets (app.3f9a2c.js): cache for a year, immutable. See Nginx browser caching.
  • Images and fonts: long lifetimes; purge when replacing a file under the same name.
  • HTML: either don’t cache at the edge, or cache briefly / with purge-on-publish (WordPress plugins and CDN APIs can purge automatically). Never cache pages for logged-in users or carts — bypass on session cookies.
  • Respect Cache-Control from the origin, or set edge rules explicitly — but keep one source of truth.

Protect the origin

With a proxy CDN, attackers can still hit your VPS directly if they know its IP. Options:

  • Allow ports 80/443 only from the CDN’s IP ranges in your firewall (most CDNs publish them). See accepting only Cloudflare traffic.
  • Don’t leak the origin IP in DNS records (mail, old subdomains) or email headers.
  • Authenticated origin pulls (client certificates from the CDN) for stronger guarantees.

Real visitor IPs

Behind a CDN, your server sees the CDN’s addresses. Configure your web server to read the visitor IP from the CDN’s header (CF-Connecting-IP, X-Forwarded-For) — otherwise logs, rate limits and Fail2Ban act on the CDN’s IPs. See real IP behind Cloudflare.

TLS: full end-to-end

Use a certificate on the origin too and set the CDN to connect over HTTPS with validation (“Full (strict)” in Cloudflare terms). “Flexible” modes that connect to the origin over plain HTTP cause redirect loops and leave traffic unencrypted between CDN and server. See WordPress too many redirects.

Common pitfalls

  • Caching personalised HTML → users see someone else’s cart or account page.
  • Forgetting to purge after deploys → stale CSS/JS on unversioned files.
  • Double compression or optimisation features (minification, image rewriting) breaking scripts — enable cautiously and test.
  • CDN in front of APIs that rely on client IPs or WebSockets without configuring them.

Measure

Compare time to first byte and full load from several regions before and after (WebPageTest, Lighthouse, or curl timing), and watch the CDN’s cache hit ratio — a low ratio means your cache rules aren’t doing much.

Related: website speed optimization. Pair a CDN with a well-located origin — our USA, Hong Kong and Japan VPS locations cover the Americas and Asia.

  • CDN
  • Performance
  • Caching