Begriff

agent readableMarkdown

CDN — Glossar

Q: Ersetzt ein CDN SSR oder SSG?

Nein. CDN cached und verteilt. [[entity:ssr|SSR]] und [[entity:ssg|SSG]] erzeugen das HTML. Zusammen sind sie stark — einzeln reicht keines.

Direkte Antwort

CDN: Ein CDN (Content Delivery Network) ist ein verteiltes Netz aus Cache-Servern — sogenannten Points of Presence (PoPs) —, das Dateien geografisch nah am Nutzer ausliefert. Statt jedes Bild und jedes Stylesheet vom Origin in einem Rechenzentrum zu laden, bedient ein PoP in der Nähe den Browser. Das senkt Latenz und Origin-Last. Ein CDN repariert aber weder aufgeblähtes HTML noch langsame Server-Logik.

Wichtigste Punkte

CDN = Edge-Caches nahe am Nutzer für Assets — und bei modernen Setups oft auch für HTML.
Hilft LCP und TTFB, wenn Bytes cachebar sind; ersetzt keine saubere Architektur.
Bei Modern Stack: Vercel-Edge plus SSG/SSR, nicht „CDN vor WordPress-Monster“.

— Steve Baka

Aktualisiert: 6. Oktober 2026 · Autor: Steve Baka

Was ist ein CDN?

Ein Content Delivery Network ist kein einzelner Server, sondern ein Verbund vieler Cache-Knoten weltweit oder regional. Wenn jemand in Heidelberg eine Webseite öffnet, deren Origin in Frankfurt oder den USA liegt, kann ein PoP in der Nähe Bilder, Fonts, JavaScript und CSS aus dem Cache liefern. Der Origin wird entlastet; die Round-Trip-Zeit sinkt.

Technisch speichert der CDN-Knoten Kopien von Dateien (oft mit TTL, Cache-Control und Invalidierung). Bei einem Cache-Miss holt der PoP die Datei vom Origin, speichert sie und bedient danach nachfolgende Requests lokal. Viele CDNs terminieren TLS, komprimieren Responses und bieten Image-Optimization oder HTTP/3 — das sind Zusatzfunktionen, nicht die Kernidee.

Kurz: Das CDN ist die Delivery-Schicht. Die Anwendungslogik und das HTML-Erzeugen bleiben Aufgabe von Origin, Framework und Rendering-Modell.

Wie funktioniert ein CDN im Request-Pfad?

Der Browser fordert https://beispiel.de/hero.webp an.
DNS (häufig mit Anycast) zeigt auf einen nahen PoP.
Ist die Datei im Cache und frisch genug → Antwort vom Edge.
Sonst → Origin-Fetch, Cache-Write, dann Antwort.

Für HTML gilt dasselbe Muster nur, wenn die Seite cachebar ist. Statisch generierte Seiten und viele Edge-SSR-Responses lassen sich am Edge halten. Dynamische PHP-Seiten mit Session-Cookies und unvorhersehbarem Markup profitieren oft nur bei Assets — nicht beim Dokument selbst.

Deshalb wirkt ein CDN bei Next.js auf Vercel anders als vor einem klassischen Shared-Hosting-WordPress: Im ersten Fall liegen HTML und Assets am Edge. Im zweiten Fall cached du vielleicht nur /wp-content/uploads, während die HTML-Antwort weiter durch PHP und MySQL muss.

Was ein CDN nicht löst

DOM-Bloat: 3.000 Nodes aus Elementor/Divi bleiben 3.000 Nodes — egal wie nah der Cache ist.
Render-blocking Chaos: Zwölf synchrone Scripts werden durch Edge-Nähe schneller geladen, blockieren aber weiter.
Schlechte Server-Logik: N+1-Queries und langsame Plugins bleiben Origin-Probleme.
Fehlende Extrahierbarkeit: Für GEO und KI-Antworten zählt sauberes, fertiges HTML. Ein CDN macht schlechten Content nicht zitierbarer.

Faustregel: CDN + schlanker Stack = starke Kombination. CDN + Pagebuilder-Monster = immer noch langsam und für Maschinen schwer lesbar.

Warum ist CDN für Core Web Vitals und KI relevant?

LCP hängt oft am größten sichtbaren Element — häufig ein Hero-Bild oder ein Textblock. Liegt das Bild am Edge und ist richtig dimensioniert, sinkt die Zeit bis zur Darstellung. TTFB für cachebares HTML verbessert sich ebenfalls, wenn der Edge antwortet statt der Origin.

Für Assistenten und Crawler gilt: Schnellere, stabile Responses reduzieren Timeouts und abgebrochene Fetches. Das ist kein Ersatz für strukturierte Daten oder Direct Answers — aber ohne verlässliche Delivery bricht jede Content-Strategie an der Infrastruktur.

In Modernisierungsprojekten messen wir vor/nach: Origin-only WordPress mit Pagebuilder liegt oft bei 2,5–4,0 s LCP; Stacks mit Edge-Delivery und schlankem HTML deutlich darunter. CDN ist dabei Hebel eins von mehreren — siehe Core Web Vitals & Modernisierung.

Praxis bei Modern Stack

Wir hosten öffentliche Sites typischerweise auf Vercel: globales Edge-Netz, Asset-Hashing, immutable Caching für _next/static, und HTML aus SSG oder SSR/ISR. Nach einer WordPress-Migration verschwindet oft die Illusion, „ein Cloudflare-CDN davor“ reiche — weil das Problem die HTML-Pipeline war.

Konkret prüfen wir:

Cache-Headers und Fingerprinting für JS/CSS
Bildformate (AVIF/WebP), Größen, Priority-Hints für LCP
Ob HTML überhaupt edge-cachebar ist
Ob der Origin nach dem Cutover noch unnötig getroffen wird

Mehr zum Hosting nach dem Umbau: Hosting nach Migration. Edge-Rendering als Modell: Edge-Rendering.

Wann brauchst du (k)ein CDN?

Ja, sinnvoll: öffentliche Marketing- und Content-Sites, internationale oder DE-weite Reichweite, viele Medien-Assets, moderne Jamstack-/Next-Setups (meist schon inklusive).

Allein nicht genug: wenn der Flaschenhals PHP, Plugins oder Pagebuilder-HTML ist. Dann zuerst modernisieren — CDN danach oder parallel als Teil des neuen Hostings.

Lokal sehr kleine Sites: ein Edge-fähiges Hosting mit CDN-Charakter ist trotzdem der Default; Extra-Komplexität brauchst du selten.

Quellen

MDN — Content delivery network (CDN) — MDN Web Docs
Neutrale Definition eines CDN als verteiltes Delivery-Netz.
web.dev — Optimize LCP — Google web.dev
Verbindet Delivery/Cache mit dem LCP-Critical Path.
Core Web Vitals & Modernisierung — Modern Stack
Praxis, wie wir Performance und Stack zusammen modernisieren.

Häufige Fragen

Was ist ein CDN in einem Satz?

Ein CDN ist ein Netz aus Cache-Servern, das Dateien nah am Nutzer ausliefert und so Latenz und Last auf dem Origin-Server senkt.

Ersetzt ein CDN SSR oder SSG?

Nein. CDN cached und verteilt. SSR und SSG erzeugen das HTML. Zusammen sind sie stark — einzeln reicht keines.

Reicht ein CDN gegen schlechten LCP?

Nur wenn große Assets oder langsame Origin-Antworten die Bremse sind. Bei 200 KB Pagebuilder-HTML hilft zuerst schlankeres Markup.

Weiterlesen

LCP
LCP (Largest Contentful Paint) ist eine der drei Core Web Vitals. Die Metrik misst die Zeit, bis das größte sichtbare Element im Viewport gerendert ist; gut sind höchstens 2,5 Sekunden.
Core Web Vitals
Core Web Vitals sind Googles drei Nutzererlebnis-Kennzahlen: LCP (Ladezeit des größten Elements), INP (Reaktionszeit auf Eingaben) und CLS (visuelle Stabilität). Sie fließen in die Suche ein und zeigen Timeout- und Abbruchrisiken auch für KI-Crawler.
Hosting nach der Migration
Nach der Migration wird kein klassisches WordPress-Hosting mehr benötigt. Die Webseite wird über eine moderne Plattform mit CDN- und Edge-Auslieferung betrieben; Domain, E-Mail und DNS können dabei getrennt und unverändert bleiben.
Edge Rendering
Edge-Rendering führt das Erzeugen von HTML oder API-Antworten auf Servern nah am Nutzer aus, statt zentral in einem Rechenzentrum. Es senkt Latenz für dynamische Antworten und ergänzt das CDN, das statische Dateien ausliefert.
SSG
SSG (Static Site Generation) erzeugt das fertige HTML jeder Seite einmal beim Build, nicht bei jedem Aufruf. Die Dateien lassen sich über ein CDN ausliefern — schnell, robust und für Crawler direkt lesbar.
SSR
SSR (Server-Side Rendering) erzeugt das HTML einer Seite auf dem Server pro Anfrage, statt es dem Browser per JavaScript zusammenbauen zu lassen. Crawler, Assistenten und Nutzer erhalten den Inhalt sofort im ersten Response.
Core Web Vitals & Modernisierung
Warum LCP, INP und CLS zur Webseite-Modernisierung gehören — und warum CDN-Caching allein selten reicht, wenn WordPress oder Pagebuilder das Markup aufblasen.
Vercel
Vercel ist eine Cloud-Plattform zum Bereitstellen von Frontend- und Fullstack-Anwendungen, besonders von Next.js: Git-Push löst den Build aus, jede Änderung bekommt eine Vorschau-URL, Auslieferung läuft über ein globales Edge-Netz mit CDN.