CDN und Ladezeit: was es für LCP, INP und CLS bringt

Ein CDN beschleunigt den Transport. Es bringt Dateien näher an die Besucher und nimmt dem eigenen Server Arbeit ab ^[1]. Was im Browser passiert, nachdem eine Datei angekommen ist, ändert es nicht. Daraus folgt, auf welche Messwerte es wirkt und auf welche kaum. Die Core Web Vitals im Allgemeinen und wie du sie für die Suche verbesserst, erklärt der Beitrag Core Web Vitals: LCP, INP und CLS verbessern. Hier geht es nur um den Anteil des CDN.

Die drei Messwerte und ihre Grenzwerte

Google bewertet die Nutzererfahrung über drei Messwerte. Der Largest Contentful Paint (LCP) misst, wann das größte sichtbare Element geladen ist, und sollte höchstens 2,5 Sekunden betragen. Interaction to Next Paint (INP) misst, wie schnell die Seite auf Klicks und Eingaben reagiert, gut sind 200 Millisekunden oder weniger. Der Cumulative Layout Shift (CLS) misst, wie stark sich der Inhalt beim Laden verschiebt, und sollte bei 0,1 oder darunter liegen. Eine Seite gilt als gut, wenn sie alle drei Werte bei 75 Prozent der Seitenaufrufe erreicht, getrennt nach Mobilgeräten und Desktop ^[2]. INP hat am 12.03.2024 den früheren Messwert First Input Delay abgelöst ^[3].

Daneben spielt die Time to First Byte (TTFB) eine Rolle. Sie zählt nicht zu den drei Kernwerten, steckt aber im LCP. Google nennt 0,8 Sekunden oder weniger als guten Wert und alles über 1,8 Sekunden als schlecht, versteht das aber ausdrücklich als grobe Orientierung ^[4].

TTFB: hier wirkt ein CDN am stärksten

Die TTFB setzt sich aus dem Verbindungsaufbau und der Antwortzeit des Servers zusammen. Beides lässt sich senken ^[4]. Ein CDN setzt an beiden Stellen an. Der Verbindungsaufbau mit TCP und TLS läuft zu einem Standort in der Nähe statt zu deinem Server, der vielleicht in einem anderen Land steht. Liegt die angefragte Datei im Cache, entfällt die Arbeit des Servers ganz, denn der Cache-Server antwortet statt des Origins ^[1].

Für die HTML-Seite selbst gilt das aber nur, wenn das CDN sie zwischenspeichern darf. Viele Anbieter tun das nicht von sich aus. Cloudflare etwa speichert HTML standardmäßig nicht im Cache ^[5]. Dann geht jede Seitenanfrage weiter zum Origin, und ein langsamer Server bleibt langsam. Wer eine träge Datenbank oder viele Plugins hat, muss zuerst dort ansetzen. Was Hosting und CDN jeweils leisten, erklärt der Beitrag CDN oder Hosting: wer macht was?.

LCP: kürzere Wege für das größte Element

Google teilt den LCP in vier Abschnitte, die nacheinander ablaufen: die TTFB, die Verzögerung bis das LCP-Element zu laden beginnt, die Ladedauer dieses Elements und die Verzögerung bis zur Anzeige. Als Richtwert sollen TTFB und Ladedauer je etwa 40 Prozent ausmachen, die beiden Verzögerungen je weniger als 10 Prozent ^[6].

Ein CDN verkürzt zwei dieser vier Abschnitte. Die TTFB sinkt aus den oben genannten Gründen. Die Ladedauer sinkt, weil das LCP-Element, meist ein großes Bild, einen kürzeren Weg zurücklegt. Google empfiehlt dafür ausdrücklich ein CDN und hebt Bild-CDNs hervor, weil sie die Dateien zusätzlich verkleinern ^[6]. Nach Googles Angaben sparen Websites durch ein Bild-CDN 40 bis 80 Prozent an Bildgröße. Solche Dienste liefern je nach Browser AVIF, WebP oder JPEG aus ^[7].

Eine Einschränkung nennt Google ebenfalls: Kommt das Bild von einer fremden Domain, muss der Browser eine zusätzliche Verbindung aufbauen. Am besten liefert deshalb ein CDN aus, das unter deiner eigenen Domain vor dem Origin steht ^{[6, 7]}. Bei Pull-Zonen auf einer eigenen Subdomain wie cdn.example.de fällt diese zusätzliche Verbindung an.

INP: das CDN liefert JavaScript, ausführen muss es der Browser

INP teilt eine Interaktion in drei Abschnitte: die Wartezeit, bis die Ereignisbehandlung startet, die Dauer dieser Behandlung und die Zeit bis zum nächsten gezeichneten Bild. Fast alle Ursachen für schlechte Werte liegen im Hauptthread des Browsers, etwa lange Aufgaben durch große Skripte oder aufwendige Ereignisbehandlungen ^[8].

Ein CDN kann JavaScript schneller ausliefern, aber nicht schneller ausführen. Wer schlechte INP-Werte hat, muss am Code ansetzen: Skripte aufteilen, weniger Arbeit in Klickbehandlungen, schwere Fremdskripte entfernen. Ein CDN ändert an diesem Messwert wenig.

CLS: kein direkter Einfluss

Layoutverschiebungen entstehen durch Bilder und Videos ohne Angabe von Breite und Höhe, durch Werbung, eingebettete Inhalte und iFrames ohne reservierten Platz, durch nachträglich eingefügte Inhalte und durch Webschriften, die beim Laden ausgetauscht werden ^[9]. Das sind Fragen des Seitenaufbaus. Ein CDN behebt keine davon. Kommt eine Schrift schneller an, kann der Austausch früher passieren, an der Ursache ändert das nichts.

Einstellungen, die beim CDN etwas bringen

Neben dem Cache selbst haben CDNs Funktionen, die Ladezeit sparen. Am Beispiel Cloudflare:

• Komprimierung: Cloudflare komprimiert Antworten an Besucher mit Gzip, Brotli oder Zstandard. Im Free-Tarif ist Zstandard voreingestellt, in Pro und Business Brotli. Welches Verfahren greift, hängt auch davon ab, was der Browser unterstützt ^[10].
• HTTP/3: Das Protokoll steht in allen Tarifen zur Verfügung, setzt aber ein Zertifikat bei Cloudflare voraus ^[11].
• Early Hints: Während der Origin noch rechnet, schickt Cloudflare dem Browser eine vorläufige Antwort mit dem Statuscode 103 und Link-Headern, damit er wichtige Dateien schon laden kann. Das gibt es in allen Tarifen. Voraussetzung ist, dass deine Seite Link-Header mit "preload" oder "preconnect" sendet ^[12].
• Bildoptimierung: Polish entfernt Metadaten und komprimiert Bilder, ist aber erst ab dem Tarif Pro enthalten ^[13].

Die größte Wirkung haben trotzdem sauber gesetzte Cache-Regeln. Wie du sie festlegst, steht im Beitrag CDN einrichten in sieben Schritten.

Die Trefferquote entscheidet über den Gewinn

Ein CDN beschleunigt nur die Anfragen, die es aus dem eigenen Speicher beantworten kann. Jede andere Anfrage reicht es an deinen Server weiter, und die Antwort dauert so lange wie ohne CDN, manchmal etwas länger. Cloudflare zeigt das im Header "cf-cache-status": Bei "HIT" kam die Datei aus dem Cache, bei "MISS" und "EXPIRED" vom Origin. "BYPASS" und "DYNAMIC" bedeuten, dass die Datei gar nicht zwischengespeichert wird ^[15]. Bei "STALE" lieferte Cloudflare eine abgelaufene Kopie aus, weil der Origin nicht erreichbar war ^[15].

Für die Ladezeit heißt das: Je mehr Anfragen mit HIT beantwortet werden, desto größer der Effekt. Die Trefferquote steigt, wenn die Cache-Zeiten lang genug sind und Dateien nicht unnötig in vielen Varianten abgerufen werden. Mit der Angabe "s-maxage" kannst du gemeinsam genutzten Zwischenspeichern wie dem CDN eine eigene, längere Lebensdauer vorgeben als dem Browser, denn sie hat dort Vorrang vor "max-age" ^[16]. So bleibt eine Datei im CDN länger frisch, während der Browser sie öfter neu anfragt.

Richtig messen: Labor und echte Besucher

PageSpeed Insights zeigt zwei Arten von Daten. Die Labordaten stammen aus einem simulierten Seitenaufruf auf einem einzigen Gerät mit festen Netzbedingungen. Sie helfen bei der Fehlersuche, bilden aber nicht jeden Engpass ab. Die Felddaten aus dem Chrome User Experience Report stammen von echten Nutzern und decken die vergangenen 28 Tage ab ^[14].

Für ein CDN heißt das: Den Effekt siehst du in den Labordaten sofort, in den Felddaten erst nach und nach, weil dort noch Aufrufe aus der Zeit vor der Umstellung einfließen. Prüfe außerdem, von wo du misst. Eine Messung von einem Standort nahe an deinem Server zeigt den Gewinn kaum, eine Messung aus einem anderen Kontinent sehr deutlich. Für eine schnelle Messung eignet sich PageSpeed.de.

Wann ein CDN wenig bringt

Ein CDN ist kein Allheilmittel für langsame Seiten. Sein Nutzen schrumpft, wenn fast alle Besucher nahe am Server sitzen und der Server schnell antwortet. Er schrumpft auch, wenn die HTML-Seiten nicht zwischengespeichert werden und der Server für jede Seite lange rechnet. Bei Problemen mit INP oder CLS hilft es praktisch nicht. Am meisten bringt es bei Besuchern aus vielen Regionen, bei vielen und großen Bildern und bei Lastspitzen, die den eigenen Server sonst überfordern würden ^[1].

1. Organisation What is a CDN?. Amazon Web Services. Stand ohne Datum. abgerufen am 29.10.2026
2. Organisation Web Vitals. web.dev (Google). Stand ohne Datum. abgerufen am 29.10.2026
3. Organisation Interaction to Next Paint becomes a Core Web Vital on March 12. web.dev (Google). Stand 2024. abgerufen am 29.10.2026
4. Organisation Time to First Byte (TTFB). web.dev (Google). Stand ohne Datum. abgerufen am 29.10.2026
5. Organisation Default cache behavior. Cloudflare Docs. Stand ohne Datum. abgerufen am 29.10.2026
6. Organisation Optimize Largest Contentful Paint. web.dev (Google). Stand ohne Datum. abgerufen am 29.10.2026
7. Organisation Use image CDNs to optimize images. web.dev (Google). Stand ohne Datum. abgerufen am 29.10.2026
8. Organisation Optimize Interaction to Next Paint. web.dev (Google). Stand ohne Datum. abgerufen am 29.10.2026
9. Organisation Optimize Cumulative Layout Shift. web.dev (Google). Stand ohne Datum. abgerufen am 29.10.2026
10. Organisation Content compression. Cloudflare Docs. Stand ohne Datum. abgerufen am 29.10.2026
11. Organisation HTTP/3 (with QUIC). Cloudflare Docs. Stand ohne Datum. abgerufen am 29.10.2026
12. Organisation Early Hints. Cloudflare Docs. Stand ohne Datum. abgerufen am 29.10.2026
13. Organisation Polish. Cloudflare Docs. Stand ohne Datum. abgerufen am 29.10.2026
14. Organisation About PageSpeed Insights. Google for Developers. Stand ohne Datum. abgerufen am 29.10.2026
15. Organisation Cloudflare cache responses. Cloudflare Docs. Stand ohne Datum. abgerufen am 29.10.2026
16. Organisation Cache-Control header. MDN Web Docs. Stand ohne Datum. abgerufen am 29.10.2026

Zuletzt geprüft am 29.10.2026, nächste Prüfung spätestens im Oktober 2027. Fehler entdeckt? Schreib uns.