---
term: 'CDN (Content Delivery Network)'
seoTitle: 'What is a CDN (Content Delivery Network)? Complete Guide'
headline: 'What is a CDN (Content Delivery Network)?'
slug: cdn-content-delivery-network
category: cloud-architecture
shortDefinition: 'A CDN is a network of distributed servers that caches content close to users, so pages and files load fast everywhere.'
relatedTerms:
  - edge-computing-edge-functions
  - ssr-vs-csr-vs-ssg
  - jamstack
  - api-payload-optimization
contrastsWith:
  - edge-computing-edge-functions
faq:
  - question: 'What is a CDN in simple terms?'
    answer: 'A geographically distributed network of servers that keeps cached copies of your content close to your users. Instead of every request traveling to your origin server — possibly across an ocean — most are answered by a nearby edge server in milliseconds. The majority of major-site web traffic is served this way.'
  - question: 'How does a CDN work?'
    answer: 'Routing plus caching. A user''s request is steered to the nearest point of presence; if that edge server holds a fresh cached copy (a cache hit), it answers immediately. If not (a miss), the edge fetches from your origin, stores a copy for the time-to-live you configured, and serves everyone nearby from cache until it expires.'
  - question: 'Is a CDN the same as web hosting?'
    answer: 'No — a CDN complements hosting, never replaces it. Your host (origin) stores the authoritative content; the CDN holds temporary copies at the edge. If the origin disappears, the CDN eventually has nothing to serve. The division of labor: origin is the source of truth, CDN is the distribution layer.'
  - question: 'What are a cache hit, a cache miss, and TTL?'
    answer: 'A hit means the edge served its cached copy — fast, and the origin never noticed. A miss means the edge had no fresh copy and fetched from the origin — slower, once, for the first nearby visitor. TTL (time to live) is how long a cached copy counts as fresh, set via Cache-Control headers. Cache design is mostly the art of maximizing hits without serving stale content.'
  - question: 'Can a CDN serve dynamic content?'
    answer: 'Not from cache in the classic sense — a personalized API response differs per user. But CDNs still accelerate dynamic traffic through optimized routes, persistent connections, and TLS terminated near the user; and modern platforms run logic at the edge itself. The practical split: cache static assets aggressively, accelerate dynamic responses, and compute at the edge where it pays.'
  - question: 'How does a CDN protect against DDoS attacks?'
    answer: 'By being enormous and in the way. As a reverse proxy, the CDN hides your origin''s address, and its distributed capacity absorbs volumetric attacks across many points of presence — traffic that would flatten one server dissipates across a global network, with filtering applied at the edge before anything reaches you.'
  - question: 'When do you NOT need a CDN?'
    answer: 'When your audience is local to your server''s region, an extra hop through a distant edge can even add latency; when traffic is so low that caches expire between visitors (perpetual misses do nothing); and when a small dynamic app simply is not delivery-bound. A CDN is leverage on distance and volume — without either, it is configuration without benefit.'
  - question: 'What is the difference between a CDN and edge computing?'
    answer: 'A CDN moves content closer to users; edge computing moves computation closer. Delivery versus decisions: a CDN answers "serve this file fast everywhere," edge functions answer "run this logic near the user." The two converge in practice — modern CDN platforms execute code at their points of presence — but the mental model holds.'
codeLanguages: [javascript, dart, swift, kotlin]
externalAuthorities:
  - name: 'CDN — MDN Web Docs Glossary'
    url: 'https://developer.mozilla.org/en-US/docs/Glossary/CDN'
  - name: 'Content delivery network (Wikipedia)'
    url: 'https://en.wikipedia.org/wiki/Content_delivery_network'
  - name: 'HTTP Cache-Control — MDN Web Docs'
    url: 'https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Cache-Control'
  - name: 'Back4app file storage documentation'
    url: 'https://www.back4app.com/docs'
cta:
  title: 'Files served fast, from day one'
  text: 'Upload a file to Back4app and the URL you get back is CDN-friendly by default — cache-ready delivery for images, media, and downloads, with the database, auth, and APIs already managed beside it. No distribution layer to configure.'
  linkText: 'Start Free'
  linkUrl: 'https://www.back4app.com/signup'
author: 'Back4app Engineering'
publishedDate: '2026-07-24'
translationKey: cdn-content-delivery-network
---

**A CDN is a network of distributed servers that caches content close to users, so pages and files load fast everywhere.** Physics is the problem it solves: a request from São Paulo to a server in Frankfurt pays the round trip in latency, every time. A CDN answers from São Paulo instead — and one clarification saves endless confusion: it *complements* your hosting, it never replaces it.

## Key takeaways

| Question | Answer |
| --- | --- |
| What it is | Distributed edge servers holding cached copies of your content |
| Problem it solves | Distance — latency scales with the round trip to your origin |
| The mechanism | Route to nearest edge → cache hit serves instantly; miss fetches from origin once |
| The knobs | Cache-Control headers, TTL, purge or versioned filenames |
| What it isn't | A web host, or edge computing — delivery, not storage or logic |

## The knobs that make it work

The whole caching contract fits in one HTTP header — and it's the single most under-explained piece of every CDN explainer:

```text
# The origin's instruction to every cache between it and the user:
Cache-Control: public, max-age=300, s-maxage=86400, stale-while-revalidate=3600

  public                  → any cache may store this
  max-age=300             → browsers: fresh for 5 minutes
  s-maxage=86400          → CDN edges: fresh for 24 hours
  stale-while-revalidate  → serve stale instantly, refresh in background

# The other strategy: never expire, never purge — version the filename
/_assets/app.3f9c1b.css   → cache "forever"; a new build means a new URL
```

Where files come from in an app matters too — on a managed backend, an upload returns a delivery-ready URL with the caching story already sane:

**JavaScript:**

```javascript
// JavaScript / Node.js — Back4app JS SDK
// Upload once; the returned URL serves from edge cache worldwide
const file = new Parse.File('hero.webp', { base64: imageData });
await file.save();
console.log(file.url()); // CDN-backed, cache-friendly URL
```

**Flutter:**

```dart
// Flutter / Dart — Back4app Flutter SDK
final file = ParseFile(File('hero.webp'));
await file.save();
print(file.url); // CDN-backed, cache-friendly URL
```

**Swift:**

```swift
// iOS / Swift — Back4app Swift SDK
let file = ParseFile(name: "hero.webp", data: imageData)
file.save { result in
  if case .success(let saved) = result {
    print(saved.url ?? "") // CDN-backed, cache-friendly URL
  }
}
```

**Kotlin:**

```kotlin
// Android / Kotlin — Back4app Android SDK
val file = ParseFile("hero.webp", imageBytes)
file.saveInBackground { e ->
  if (e == null) Log.d("CDN", file.url) // CDN-backed, cache-friendly URL
}
```

## Anatomy of a request

```mermaid
flowchart LR
  accTitle: How a CDN serves a request
  accDescr: A user is routed to the nearest point of presence; a cache hit is served from the edge immediately, while a miss fetches from the origin server, caches the response per its TTL, and then serves it locally.
  U["User"] --> R["Routing<br/>(nearest PoP)"]
  R --> E["Edge server"]
  E -->|"cache hit"| U2["Answered in ms"]
  E -->|"cache miss"| O["Origin server"]
  O -->|"response + TTL"| E
```

The vocabulary in one pass: the **origin** is your actual server — the source of truth. A **PoP** (point of presence) is a CDN data-center location; **edge servers** are the caching machines inside it. The **cache-hit ratio** — the share of requests answered without touching the origin — is the metric the whole exercise optimizes, and the levers are the headers above. What improves for users is **TTFB** (time to first byte) and, when full pages are edge-cached, the loading metrics that follow from it.

## CDN vs. web hosting vs. edge computing

| Dimension | Web hosting (origin) | CDN | Edge computing |
| --- | --- | --- | --- |
| Role | Stores the authoritative content | Distributes cached copies | Runs logic near users |
| Answers | "Where does my site live?" | "Why is it fast in Tokyo?" | "Can I compute in Tokyo?" |
| State | Permanent | Temporary, TTL-bound | Usually stateless |
| Without it | No site | Slow site, exposed origin | Round trips for every decision |
| Typical content | Everything, once | Static assets, media, full cached pages | Personalization, auth checks, rewrites |

The [MDN definition](https://developer.mozilla.org/en-US/docs/Glossary/CDN) adds the caveat vendor pages skip: third-party CDN scripts are a supply-chain dependency (integrity attributes exist for a reason), and an extra DNS lookup to a CDN can even cost time on a first visit — leverage, not magic.

## Common use cases

- **Static assets at scale.** CSS, JavaScript, fonts, images — fingerprinted filenames plus long TTLs turn repeat visits into pure edge traffic.
- **Media and downloads.** Video segments and large files, where origin bandwidth would be the bill and the bottleneck.
- **Global audiences.** The same page served under 100 ms on four continents without running servers on four continents.
- **Traffic spikes and launches.** The edge absorbs the surge; the origin sees a fraction of it.
- **Security posture.** Origin hidden behind a reverse proxy, TLS terminated at the edge, volumetric attacks dissipated across the network.

## Do you need a CDN? A decision matrix

| A CDN pays when… | Skip (or defer) it when… |
| --- | --- |
| Users are far from your origin | Your audience is local to your server's region |
| Assets and media dominate your traffic | The app is small, dynamic, and API-bound |
| Traffic spikes are part of the business | Traffic is too low for caches to stay warm |
| Origin bandwidth is a real cost | The extra moving part outweighs the ms saved |
| You want DDoS absorption in front of origin | You'd be caching personalized responses (you can't) |

The honest row nobody prints: on a low-traffic site, cached copies expire between visitors, every request is a miss, and the CDN adds a hop for nothing. Distance and volume are the inputs; without either, fix something else first.

## Limitations and trade-offs

- **Stale content is the default failure.** Long TTLs mean yesterday's file served confidently today; the cure is purging (slow, per-CDN) or versioned filenames (better).
- **Cache invalidation is genuinely hard.** It's one of the two famous hard problems for a reason — design URLs so you rarely need it.
- **Dynamic content resists caching.** Per-user responses can't be shared; acceleration and edge logic help, but the origin still does the work.
- **A dependency in the critical path.** CDN outages are internet-weather events; when the edge is down, "your" site is down.
- **Debugging gets a layer.** Which cache served this? With which headers? Cache-status headers and per-edge behavior become part of your observability surface.

## CDNs and Back4app

Back4app is an open-source Backend-as-a-Service (BaaS) platform that combines a managed database, auto-generated REST and GraphQL APIs, authentication, file storage, and Cloud Code serverless functions. The CDN story is built into the file layer: upload through any SDK (the tabs above) and the returned URL is delivery-ready — stable, cacheable, and independent of your API's dynamic traffic, which keeps the cacheable and uncacheable halves of your app cleanly separated. Web frontends hosted on [Back4app Containers](https://www.back4app.com/container-as-a-service) sit naturally behind any CDN, with the classic pattern — long-lived fingerprinted assets, short-lived HTML — configured in one header.