Was ist ein CDN (Content Delivery Network)?

Ein CDN ist ein Netzwerk verteilter Server, die Inhalte nah bei den Nutzern cachen, damit Seiten und Dateien überall schnell laden. Das Problem, das es löst, ist Physik: Eine Anfrage von São Paulo an einen Server in Frankfurt bezahlt den Roundtrip jedes Mal in Latenz. Ein CDN antwortet stattdessen aus São Paulo – und eine Klarstellung erspart endlose Verwirrung: Es ergänzt Ihr Hosting, es ersetzt es nie.

Das Wichtigste in Kürze

Die Stellschrauben, die es zum Laufen bringen

Der gesamte Caching-Vertrag passt in einen einzigen HTTP-Header – und er ist das am schlechtesten erklärte Stück jeder CDN-Erklärung:

# Die Anweisung des Origins an jeden Cache zwischen ihm und dem Nutzer:
Cache-Control: public, max-age=300, s-maxage=86400, stale-while-revalidate=3600

  public                  → jeder Cache darf dies speichern
  max-age=300             → Browser: 5 Minuten frisch
  s-maxage=86400          → CDN-Edges: 24 Stunden frisch
  stale-while-revalidate  → Veraltetes sofort liefern, im Hintergrund erneuern

# Die andere Strategie: nie ablaufen, nie purgen – den Dateinamen versionieren
/_assets/app.3f9c1b.css   → "für immer" gecacht; ein neuer Build heißt eine neue URL

Woher die Dateien einer App kommen, zählt ebenfalls – auf einem verwalteten Backend liefert ein Upload eine auslieferungsfertige URL zurück, bei der die Caching-Frage bereits vernünftig gelöst ist:

// 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 — Back4app Flutter SDK
final file = ParseFile(File('hero.webp'));
await file.save();
print(file.url); // CDN-backed, cache-friendly URL

// 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
  }
}

// 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
}

Anatomie einer Anfrage

Das Vokabular in einem Durchgang: Der Origin ist Ihr tatsächlicher Server – die Quelle der Wahrheit. Ein PoP (Point of Presence) ist ein Rechenzentrumsstandort des CDN; die Edge-Server sind die Caching-Maschinen darin. Die Cache-Hit-Rate – der Anteil der Anfragen, die ohne Kontakt zum Origin beantwortet werden – ist die Metrik, auf die die ganze Übung hin optimiert, und die Hebel sind die Header oben. Für Nutzer verbessert sich die TTFB (Time to First Byte) und, wenn ganze Seiten am Edge gecacht sind, die daraus folgenden Ladekennzahlen.

CDN vs. Webhosting vs. Edge Computing

Die MDN-Definition ergänzt den Vorbehalt, den Anbieterseiten auslassen: Über fremde CDNs eingebundene Skripte sind eine Abhängigkeit in Ihrer Lieferkette (Integrity-Attribute gibt es aus gutem Grund), und ein zusätzlicher DNS-Lookup zu einem CDN kann beim ersten Besuch sogar Zeit kosten – ein Hebel, keine Magie.

Typische Anwendungsfälle

• Statische Assets in großem Maßstab. CSS, JavaScript, Schriften, Bilder – Dateinamen mit Fingerprint plus lange TTLs machen aus wiederholten Besuchen reinen Edge-Traffic.
• Medien und Downloads. Videosegmente und große Dateien, bei denen die Bandbreite des Origins Rechnung und Engpass zugleich wäre.
• Weltweites Publikum. Dieselbe Seite auf vier Kontinenten in unter 100 ms ausgeliefert, ohne auf vier Kontinenten Server zu betreiben.
• Lastspitzen und Launches. Der Edge fängt die Welle ab; der Origin sieht nur einen Bruchteil davon.
• Sicherheitsposition. Origin hinter einem Reverse Proxy verborgen, TLS am Edge terminiert, volumetrische Angriffe über das gesamte Netz verteilt.

Brauchen Sie ein CDN? Eine Entscheidungsmatrix

Die ehrliche Zeile, die niemand druckt: Auf einer Seite mit wenig Traffic laufen gecachte Kopien zwischen zwei Besuchern ab, jede Anfrage ist ein Miss, und das CDN fügt einen Sprung für nichts hinzu. Distanz und Volumen sind die Eingangsgrößen; fehlt beides, reparieren Sie zuerst etwas anderes.

Grenzen und Trade-offs

• Veraltete Inhalte sind der Standardfehler. Lange TTLs bedeuten, dass die Datei von gestern heute mit voller Überzeugung ausgeliefert wird; das Gegenmittel heißt Purge (langsam, je CDN verschieden) oder versionierte Dateinamen (besser).
• Cache-Invalidierung ist tatsächlich schwer. Sie zählt nicht ohne Grund zu den beiden berühmten schweren Problemen der Informatik – entwerfen Sie Ihre URLs so, dass Sie sie selten brauchen.
• Dynamische Inhalte widersetzen sich dem Caching. Antworten pro Nutzer lassen sich nicht teilen; Beschleunigung und Edge-Logik helfen, aber die Arbeit macht weiterhin der Origin.
• Eine Abhängigkeit im kritischen Pfad. CDN-Ausfälle sind Wetterereignisse des Internets; wenn der Edge steht, steht “Ihre” Seite.
• Debugging bekommt eine Schicht dazu. Welcher Cache hat das ausgeliefert? Mit welchen Headern? Cache-Status-Header und das Verhalten einzelner Edges werden Teil Ihrer Observability-Oberfläche.

CDNs mit Back4app

Back4app ist eine Open-Source-Plattform für Backend as a Service (BaaS), die eine verwaltete Datenbank, automatisch generierte REST- und GraphQL-APIs, Authentifizierung, Dateispeicher und Serverless-Funktionen mit Cloud Code kombiniert. Die CDN-Geschichte steckt bereits in der Dateischicht: Laden Sie über ein beliebiges SDK hoch (die Tabs oben), und die zurückgegebene URL ist auslieferungsfertig – stabil, cachefähig und unabhängig vom dynamischen Traffic Ihrer API, was die cachefähige und die nicht cachefähige Hälfte Ihrer App sauber trennt. Web-Frontends, die auf Back4app Containers laufen, fügen sich hinter jedem CDN natürlich ein – mit dem klassischen Muster aus langlebigen Assets mit Fingerprint und kurzlebigem HTML, konfiguriert in einem einzigen Header.