CDN & Core Web Vitals

Die kurze Antwort

Ein CDN verbessert vor allem LCP und TTFB spürbar. INP bleibt fast unbeeinflusst (das hängt am Client-JavaScript), CLS ebenfalls (das ist eine Layout-Frage).

Was sind die Core Web Vitals?

Google misst Nutzererfahrung über drei Hauptmetriken:

• LCP (Largest Contentful Paint): Wann ist das größte sichtbare Element fertig geladen? Schwellwert: ≤ 2,5 s.
• INP (Interaction to Next Paint): Wie schnell reagiert die Seite auf Klicks und Eingaben? Schwellwert: ≤ 200 ms. (Hat 2024 FID abgelöst.)
• CLS (Cumulative Layout Shift): Wie stark verschiebt sich das Layout während des Ladens? Schwellwert: ≤ 0,1.

Daneben relevant: TTFB (Time to First Byte) – wann kommt das erste Byte vom Server an? Indirekt eine LCP-Voraussetzung.

Wirkung eines CDN auf TTFB und LCP

Hier liegt der Hauptnutzen. Beispielszenario: WordPress-Site mit Origin in Frankfurt, Besucher in Sydney.

• Ohne CDN: ~290 ms reine Latenz Sydney ↔ Frankfurt + Server-Antwort.
• Mit CDN (Cache-Hit): ~5 ms zum nächsten PoP in Sydney + Auslieferung.

Real heißt das: TTFB von 600–800 ms ohne CDN, 80–150 ms mit CDN. Das reicht oft, um eine Site von „nicht ausreichend" auf „gut" bei den Core Web Vitals zu heben – besonders bei internationalem Publikum.

Auch innerhalb Deutschlands hilft das CDN: statische Assets werden parallelisiert, das LCP-Bild kommt vom Edge mit wenigen Millisekunden Latenz. Typisch sind 100–250 ms LCP-Verbesserung.

Wirkung auf INP – ehrliche Einordnung

INP misst die Reaktionszeit auf Nutzer-Interaktionen. Diese hängt fast komplett von der JavaScript-Performance ab. Ein CDN kann das JS schneller ausliefern – aber nicht schneller ausführen.

• Wer ein CDN einsetzt und INP-Probleme hat, muss am JavaScript ansetzen (Code-Splitting, Lazy-Loading, schwere Third-Party-Scripts ausmisten).
• Einzige indirekte CDN-Wirkung: schnelleres Laden der JS-Dateien → früheres Parsing-Ende → früheres „interaktiv".

Wirkung auf CLS – kein direkter Einfluss

CLS misst Layout-Verschiebungen. Verursacher sind typischerweise:

• Bilder ohne width/height-Attribute.
• Nachgeladene Schriften, die das Layout neu umbrechen.
• Werbung oder Embeds, die ohne reservierten Platz erscheinen.

Ein CDN ändert daran nichts. Aber: wenn Schriften vom CDN schneller kommen, kann sich das CLS leicht verbessern, weil der Font-Wechsel (FOUT/FOIT) früher passiert und weniger Layout-Sprünge nach dem Fold auftauchen.

Konfigurations-Tipps für maximale CWV-Wirkung

• Brotli-Komprimierung aktivieren: 15–25 % kleinere Dateien als gzip, alle Top-CDNs unterstützen es. Cloudflare und BunnyCDN: aktiv per Default.
• HTTP/2 oder HTTP/3 (QUIC): bei allen relevanten Anbietern Standard, beschleunigt das Laden vieler Ressourcen parallel.
• Image Optimization am Edge: AVIF/WebP-Konvertierung (Cloudflare Polish, BunnyCDN Bunny Optimizer, AWS CloudFront mit Lambda@Edge). Schnellster LCP-Hebel bei bildlastigen Sites.
• Early Hints (103): hochwertige Anbieter unterstützen sie – erlauben dem Browser, kritische Ressourcen vorzuladen.
• Preconnect zum CDN: bei Pull-Zone-Setups <link rel="preconnect" href="https://cdn.beispiel.de"> spart 50–150 ms beim ersten Asset-Request.

Realistische Messwerte

Aus eigener Projekt-Erfahrung (WordPress-Mittelstandsseiten, deutsches Publikum):

• Standard-WordPress ohne CDN: LCP ~3,2 s, TTFB ~480 ms, INP ~180 ms.
• Mit Cloudflare Free: LCP ~2,1 s, TTFB ~95 ms, INP ~175 ms.
• Mit Cloudflare Pro + Polish: LCP ~1,4 s, TTFB ~85 ms, INP ~170 ms.
• Mit BunnyCDN + Bunny Optimizer: LCP ~1,5 s, TTFB ~95 ms, INP ~175 ms.

Werte sind exemplarisch. Konkrete Ergebnisse hängen stark von Theme, Plugins, Bildgrößen und Origin-Performance ab.