Wie kann Core Web Vitals LCP mithilfe eines CDN verbessern?

Ein CDN kann den LCP verbessern, vorausgesetzt, dass das größte Inhaltselement der Seite tatsächlich durch „regionsübergreifende Übertragung, Antwortzeiten des Ursprungsservers oder den Download statischer Ressourcen“ beeinträchtigt wird. Bei B2B-Websites für internationale Kunden, mehrsprachigen Websites oder Werbe-Landingpages ist dies sehr häufig der Fall: Nutzer befinden sich weit vom Ursprungsserver entfernt, und große Bilder im sichtbaren Bereich, Produkt-Key-Visuals oder wichtige Schriftarten müssen grenzüberschreitend abgerufen werden, wodurch sich der LCP verlängert. Werden Ressourcen auf Edge-Knoten bereitgestellt, die näher am Nutzer liegen, lassen sich die Start- und Abschlusszeiten des Ressourcendownloads häufig verkürzen.

Ein CDN ist jedoch kein Werkzeug, das Core-Web-Vitals-Werte mit einem Klick „auf Grün“ setzt. Wenn das LCP-Element selbst zu groß ist, das Bildformat ungeeignet ist, die Seite JavaScript benötigt, um Inhalte im sichtbaren Bereich zu erzeugen, oder der Server HTML nur sehr spät zurückgibt, ist der Nutzen einer reinen CDN-Integration begrenzt. Verantwortliche sollten zunächst feststellen, in welcher Phase der LCP blockiert wird, und erst dann entscheiden, welche Rolle die CDN-Konfiguration übernehmen soll.

Warum CDN den LCP beeinflussen kann

LCP misst die Zeit, die das größte Inhaltselement im Viewport des Nutzers benötigt, um vollständig gerendert zu werden. Bei Marketing-Websites handelt es sich dabei meist um ein Bannerbild im sichtbaren Bereich, ein Produktbild, ein Video-Cover oder ein großflächiges Hintergrundbild; gelegentlich kann es auch ein größerer Textblock sein. Vom Abruf der Seite bis zur Anzeige dieses Elements durchläuft der Browser grob vier Schritte: HTML anfordern, die LCP-Ressource erkennen, die Ressource herunterladen und die Seite vollständig rendern.

CDN hilft insbesondere bei den ersten drei Schritten. Nachdem Edge-Knoten HTML, Bilder, CSS, JavaScript und Schriftarten zwischengespeichert haben, müssen Nutzer die Dateien nicht bei jedem Aufruf erneut vom Hauptserver abrufen. Insbesondere wenn sich der Ursprungsserver nur in einer Region befindet und Besucher in Nordamerika, Europa, dem Nahen Osten oder Südostasien verteilt sind, schlagen sich Unterschiede bei der Netzwerk-Round-Trip-Zeit direkt auf das Laden des sichtbaren Bereichs nieder.

Im praktischen Zusammenspiel von Core Web Vitals und CDN liegt der Wert eines CDN nicht nur in „mehr Bandbreite“. Wichtiger ist die Verkürzung der Verbindungswege, die Wiederverwendung des Caches, die Verringerung der Antwortlast des Ursprungsservers zu Spitzenzeiten sowie die frühere Bereitstellung kritischer Ressourcen für den sichtbaren Bereich im Browser. Bei Websites, die Kunden über die Google-Suche, Anzeigenklicks oder Weiterleitungen aus sozialen Medien gewinnen, haben Besucher oft wenig Geduld beim Warten. Ob der sichtbare Bereich schnell erscheint, beeinflusst, ob sie Formulare, Produktseiten und Kontaktinformationen weiter ansehen.

Zuerst prüfen: In welchem Abschnitt ist der LCP langsam?

Vor der Bereitstellung oder Anpassung eines CDN sollte die Zusammensetzung des LCP mithilfe von PageSpeed Insights, dem Performance-Panel von Chrome DevTools oder Tools zur Überwachung realer Nutzer geprüft werden. Unterschiedliche Probleme erfordern unterschiedliche Maßnahmen; nicht jede Verzögerung darf dem Cache zugeschrieben werden.

Diese Unterscheidung ist wichtig. Beispielsweise kann das Bild im sichtbaren Bereich bereits schnell von einem CDN-Knoten zurückgegeben werden, während die Seite dennoch warten muss, bis ein Karussell-Widget, Tracking-Skripte und Tags von Drittanbietern ausgeführt wurden, bevor das Bild angezeigt wird. Der LCP kann dann weiterhin schlecht sein. Zusätzliche CDN-Knoten oder höhere Bandbreitenkontingente führen in diesem Fall in der Regel nicht zum gewünschten Effekt.

Die wirksamste CDN-Konfiguration für LCP ist mehr als nur „Caching aktivieren“

Erstens sollte sichergestellt werden, dass das LCP-Bild eine cachefähige statische Ressource ist und eine angemessene Cache-Control-Strategie erhält. Produkt-Hauptbilder, visuelle Elemente im sichtbaren Bereich und allgemeine Webfonts eignen sich üblicherweise für längere Cache-Zeiten. Bei Dateiaktualisierungen sollten URLs mit inhaltsbasierten Versionsnummern verwendet werden, beispielsweise durch versionsabhängige Dateinamen oder Abfrageparameter. So können Browser und CDN Ressourcen langfristig wiederverwenden, während zugleich verhindert wird, dass Nutzer nach einer Bildaktualisierung weiterhin alte Dateien sehen.

Zweitens muss zwischen HTML-Caching und Ressourcen-Caching unterschieden werden. Öffentliche Seiten, Artikelseiten und Landingpages von B2B-Websites können häufig Edge-Caching oder kurzfristiges Caching verwenden, sofern ihre Inhalte nicht vom Anmeldestatus oder von Echtzeit-Personalisierungsinformationen abhängen. So kann das CDN HTML bei Seitenanfragen schneller zurückgeben, und der Browser erkennt Bilder im sichtbaren Bereich früher. Für Seiten mit Angeboten, Konten, Warenkörben, regionalen Preisen oder dynamischen Lagerbeständen sollten Cache-Regeln dagegen sorgfältig konfiguriert werden, damit individualisierte Inhalte nicht zwischengespeichert und anderen Besuchern bereitgestellt werden.

Drittens muss die LCP-Ressource über den richtigen Ressourcenpfad ausgeliefert werden. Ein häufiger Fehler besteht darin, dass das Hauptbild der Seite weiterhin auf eine alte Domain, einen Bildhoster eines Drittanbieters oder eine nicht CDN-beschleunigte Object-Storage-Domain verweist. Während andere Dateien der Seite bereits beschleunigt sind, wird das wichtigste Bild weiterhin grenzüberschreitend vom Ursprungsserver abgerufen. Im Network-Panel des Browsers sollten die Domain der endgültigen Anfrage für das Hauptbild, der Cache-Status, die Protokollaushandlung und die Response-Header überprüft werden, statt nur darauf zu achten, ob die CDN-Konsole „integriert“ anzeigt.

Viertens sollte das Hauptbild im sichtbaren Bereich nicht in Lazy Loading einbezogen werden. Bild-Lazy-Loading eignet sich für Inhalte unterhalb des sichtbaren Bereichs. Wenn das größte Inhaltsbild loading="lazy" verwendet, kann der Browser die Anfrage verzögern und damit den Übertragungsvorteil des CDN aufheben. Das Bild im sichtbaren Bereich sollte direkt im HTML erscheinen, eindeutige Abmessungen haben und möglichst eine reguläre <img>-Struktur verwenden, statt dynamisch per Skript erstellt zu werden. Für Key-Visuals, die tatsächlich vorab geladen werden müssen, können Ressourcenhinweise mit Bedacht gesetzt werden. Sie sollten jedoch nur eine klar definierte LCP-Kandidatenressource abdecken und nicht eine große Anzahl von Bildern vorladen.

Die Bildoptimierung bestimmt die Obergrenze des CDN-Nutzens

Ein CDN kann Dateien schneller übertragen, kann aber nicht daran ändern, dass eine Datei selbst zu groß ist. Wird ein originales Produktbild, das für die Desktop-Anzeige geeignet ist, direkt auf ein Mobilgerät heruntergeladen, verlangsamt es den LCP weiterhin. Sinnvoller ist es, mehrere Größen entsprechend dem Anzeigebereich bereitzustellen, damit der Browser je nach Bildschirmbreite die passende Version auswählen kann. Gleichzeitig sollten moderne Formate wie WebP oder AVIF verwendet und Kompatibilitätsstrategien beibehalten werden. Die Pixelabmessungen eines Bildes sollten möglichst den tatsächlichen Anzeigeabmessungen entsprechen, damit übergroße Originalbilder nicht auf der Seite verkleinert dargestellt werden.

Viele Website-Baukästen konfigurieren Banner als CSS-Hintergrundbilder, um Textüberlagerungen und responsives Layout zu erleichtern. Diese Lösung kann durchaus verwendet werden, erfordert jedoch eine Prüfung, wann der Browser das Hintergrundbild herunterladen kann: Wenn die CSS-Datei spät geladen wird oder das Hintergrundbild durch ein späteres Skript ersetzt wird, verzögert sich die Erkennung der LCP-Ressource. Wenn die Performance im sichtbaren Bereich Priorität hat, lassen sich bei Szenarien mit semantischen Bildelementen Ladeprioritäten, responsive Bilder und reservierte Abmessungen in der Regel leichter steuern.

Einige leicht zu übersehende Ausnahmen

Regionsübergreifende Zugriffe bedeuten nicht, dass alle Ressourcen aggressiv zwischengespeichert werden sollten. Drittanbieter-Kundendienste, Karten, Videoplayer, Statistikskripte und Werbepixel stammen häufig von externen Domains, die ein CDN nicht direkt beschleunigen kann. Wenn sie das Rendering im sichtbaren Bereich blockieren, sollte geprüft werden, ob sie verzögert oder asynchron geladen oder erst nach einer Nutzerinteraktion initialisiert werden können.

Ein weiterer Irrtum besteht darin, einen Cache-Hit als Endergebnis zu betrachten. Beim ersten Besuch, nach Ablauf des Caches, bei nicht vorgewärmten Knoten oder bei geringem regionalem Traffic kann das CDN weiterhin auf den Ursprungsserver zurückgreifen. Nach dem Go-live sollten die Leistung beim Erst- und Wiederholungsbesuch für die jeweiligen Zielmärkte getrennt geprüft und die tatsächliche Anfragekette des LCP-Elements beachtet werden. Bei mehrsprachigen Websites sollte außerdem sichergestellt werden, dass Sprachpfade, Bildvarianten und Weiterleitungsregeln Besucher nicht zu einem weit entfernten Ursprungsserver leiten oder wiederholt weiterleiten.

Bei der Abnahme nach einer CDN-Optimierung sollten Verantwortliche nicht nur den Score der Startseite betrachten. Es sollten Seiten ausgewählt werden, die tatsächlich der Kundengewinnung dienen: Werbe-Landingpages, wichtige Produktseiten, Kategorieseiten und mehrsprachige Startseiten. Für diese sollten die Ressourcen im sichtbaren Bereich unter verschiedenen regionalen Bedingungen, Mobilfunknetzen und Cold-Cache-Bedingungen separat geprüft werden. Erst wenn HTML stabil und schnell zurückgegeben wird, Hauptbilder in der richtigen Größe priorisiert geladen werden und Skripte das Rendering nicht verzögern, führt ein CDN tatsächlich zu einer LCP-Verbesserung, statt lediglich eine weitere Konfiguration im Technologie-Stack zu sein.