Kann ein globales CDN die Zugriffsgeschwindigkeit auf eine eigenständige Website über Regionen hinweg verbessern?

Ein globales CDN kann die Zugriffsgeschwindigkeit einer unabhängigen Website über Regionen hinweg verbessern. Das Ergebnis hängt jedoch von der Zugriffsregion, der Netzwerkqualität zwischen dem Knoten und den Besuchern, der Cache-Trefferrate sowie davon ab, wie viele Inhalte auf den Ursprungsserver zugreifen müssen oder in Echtzeit generiert werden. Werden statische Ressourcen wie Bilder und Skripte direkt von einem geeigneten Edge-Knoten ausgeliefert, lässt sich die durch grenzüberschreitende Übertragungen verursachte Wartezeit in der Regel verringern. Anfragen für Warenkorb, Anmeldung und Echtzeit-Lagerbestand können dagegen weiterhin durch die Entfernung zum Ursprungsserver und dessen Verarbeitungsgeschwindigkeit begrenzt sein.

Eine breite Knotenabdeckung bedeutet nicht automatisch kürzere Zugriffswege

Ein CDN leitet Anfragen über die DNS-Auflösung oder das Netzwerk-Routing an verfügbare Edge-Knoten weiter. Sind die angeforderten Ressourcen dort gespeichert, muss die Antwort nicht jedes Mal regionsübergreifend vom Ursprungsserver übertragen werden. Bei einem Cache-Miss muss der Edge-Knoten die Inhalte jedoch weiterhin vom Ursprungsserver abrufen. Deshalb kann sich die Ladegeschwindigkeit beim ersten und bei späteren Aufrufen derselben Seite deutlich unterscheiden.

Bei der Beurteilung der Abdeckung reicht es nicht aus, nur auf die Länder oder Städte zu achten, in denen sich die Knoten befinden. Auch das tatsächliche Routing vom Netzwerk des Besuchers zum Knoten, die Qualität der Zusammenschaltung zwischen den Netzbetreibern und der Rückweg des Knotens zum Ursprungsserver beeinflussen das Ergebnis. Selbst ein auf der Karte nahe gelegener Knoten kann wegen eines Umwegs beim Routing eine schlechte Leistung bieten. Tests sollten daher getrennt nach Zielregion und wichtigen Netzbetreibern ausgewertet werden, statt einen einzelnen Testpunkt als repräsentativ für den gesamten Markt zu betrachten.

Auch der Standort des Ursprungsservers beeinflusst Anfragen, bei denen der Cache nicht getroffen wird. Dass ein Knoten in einer bestimmten Region zwischengespeicherte Bilder schnell ausliefern kann, bedeutet nicht, dass er dynamische Seiten ebenso schnell abrufen kann. Muss eine Seite bei jedem Aufruf auf die Generierung durch einen weit entfernten Ursprungsserver warten, wird ein Teil des Vorteils eines näher am Besucher gelegenen Knotens durch die Wartezeit beim Abruf vom Ursprungsserver aufgehoben.

Die Caching-Strategie bestimmt, welche Inhalte wie stark beschleunigt werden können

Die Seiten einer unabhängigen Website bestehen aus HTML, Stylesheets, Skripten, Schriftarten, Bildern und API-Antworten. Für Bilder und statische Dateien mit Versionsnummern lassen sich längere Cache-Zeiten festlegen. Bei Aktualisierungen können Browser und Edge-Knoten die neuen Dateien abrufen, indem der Dateiname oder die Versionskennung geändert wird. Bleibt die Dateiadresse gleich und wird die Datei lediglich auf dem Ursprungsserver überschrieben, können veraltete Inhalte weiterhin im Cache liegen.

Beim HTML-Caching muss die Häufigkeit von Seitenänderungen berücksichtigt werden. Für öffentlich zugängliche Produktbeschreibungen und Kategorieseiten kann Caching geprüft werden. Werden Preise, Lagerbestände, Währungen oder regionsabhängige Inhalte jedoch vom Server für jede Anfrage generiert, müssen die entsprechenden Bedingungen im Cache-Schlüssel berücksichtigt werden. Andernfalls kann eine Seite für eine Region an Besucher aus einer anderen Region ausgeliefert werden. Zu viele Unterscheidungsmerkmale wiederum senken die Cache-Trefferrate. Besonders leicht bereiten Abfrageparameter Probleme: Nicht relevante Tracking-Parameter teilen dieselbe Seite in mehrere Cache-Objekte auf. Werden hingegen Parameter ignoriert, die den Inhalt beeinflussen, kann es zu falschen Inhalten kommen.

Warenkorb, Kontoinformationen, Ergebnisse des Bezahlvorgangs und Antworten mit personenbezogenen Daten müssen gemäß den Datenschutz- und Geschäftsregeln der Anwendung behandelt werden, damit sie nicht in gemeinsam genutzten Caches landen. Es sollten nicht für alle Seiten dieselben Caching-Regeln erzwungen werden, nur um die Zahl der Zugriffe auf den Ursprungsserver zu verringern. Nach dem Einrichten oder Ändern der Regeln muss außerdem geprüft werden, ob Antworten für Anfragen mit angemeldetem Status sowie für unterschiedliche Sprachen und Regionen voneinander getrennt bleiben.

Auch die Cache-Trefferrate allein erlaubt keine zuverlässige Aussage zur Geschwindigkeit. Selbst wenn kleine statische Dateien sehr häufig aus dem Cache bedient werden, kann die für die Darstellung im sichtbaren Bereich entscheidende große Bilddatei oder HTML-Seite weiterhin oft vom Ursprungsserver abgerufen werden. Die wahrgenommene Verbesserung für Besucher kann dann gering ausfallen. Um tatsächlich beeinträchtigende Anfragen zu finden, sollten Ressourcengröße, Anfragedauer und Kennzahlen zur Seitendarstellung gemeinsam betrachtet werden.

Beim Messen zwischen Netzwerkwartezeit und Seitendarstellung unterscheiden

Um die Wirkung eines globalen CDNs auf die Beschleunigung einer unabhängigen Website zu beurteilen, sollten zunächst die Testbedingungen festgelegt werden: Vor und nach der CDN-Einbindung dieselbe Seite, Region, Geräteart und Netzwerkbedingung verwenden und mehrere Messungen durchführen. Die Ergebnisse bei kaltem Cache und nach dem Aufwärmen des Caches sollten getrennt erfasst und geprüft werden, ob die Testanfragen tatsächlich über den vorgesehenen CDN-Knoten laufen. Einzelne Messungen können stark durch Netzwerkschwankungen beeinflusst werden. Der Median und die Ergebnisse langsamerer Zugriffe sind aussagekräftiger.

Die Zeit bis zum ersten Byte gibt die Wartezeit vom Absenden einer Anfrage bis zum Empfang der ersten Antwortdaten an. Sie umfasst unter anderem den Verbindungsaufbau, die Netzwerkübertragung und die Verarbeitung auf dem Server. Eine Verkürzung dieser Zeit weist auf eine Verbesserung der Anfragekette hin, bedeutet aber nicht zwangsläufig, dass die wichtigsten Seiteninhalte bereits sichtbar sind. Zusätzlich sollte die Largest Contentful Paint (LCP) beobachtet und anhand der Browser-Leistungsaufzeichnung geprüft werden, ob wichtige Bilder, Stylesheets und Skripte den sichtbaren Bereich beim ersten Laden blockieren.

Synthetische Tests erleichtern die Reproduktion von Problemen unter festen Bedingungen; Daten zu tatsächlichen Zugriffen bilden dagegen die Nutzererfahrung unter unterschiedlichen Geräte- und Netzwerkbedingungen ab. Weichen die Ergebnisse stark voneinander ab, sollten Testregion, Cache-Status, Geräteleistung und Seitenversion auf Übereinstimmung geprüft werden. Wenige langsame Anfragen sollten nicht direkt dem CDN zugeschrieben werden. Zunächst ist zu prüfen, ob die Verzögerung bei der DNS-Auflösung, dem Verbindungsaufbau, dem Warten auf die Antwort oder erst bei der Darstellung nach dem Herunterladen der Ressourcen auftritt.

Drittanbieter-Analysen, Werbung und eingebettete Inhalte verwenden möglicherweise eigene Domains und Infrastrukturen und laufen nicht automatisch über das CDN der unabhängigen Website. Selbst wenn die Ressourcen der Hauptwebsite deutlich schneller werden, können diese Anfragen die Seite weiterhin verlangsamen. Auch zu große Bilder, synchron ausgeführte Skripte und komplexe Frontend-Rendering-Prozesse verschwinden nicht automatisch durch die Einbindung eines CDNs.

Überprüfung und Rückfallmöglichkeit nach der Inbetriebnahme

Vor der Umstellung sollten die bisherigen DNS-Einträge und die Konfiguration des Ursprungsservers beibehalten werden. Zunächst sollten in einem kontrollierten Umfang HTTPS-Zertifikat, Weiterleitungen, Komprimierung, Cache-Antworten und der Abruf vom Ursprungsserver überprüft werden. Muss der Ursprungsserver die echte IP-Adresse der Besucher erkennen oder Inhalte regionsabhängig ausliefern, sind außerdem die weitergeleiteten Anfrage-Header und deren vertrauenswürdige Quelle zu überprüfen, um fehlerhafte Ratenbegrenzungen oder falsche Regionsbestimmungen zu vermeiden.

Nach der Veröffentlichung neuer Produkte, Preisänderungen oder dem Austausch von Materialien sollte der Umfang der Cache-Löschung den betroffenen Adressen entsprechen. Das Löschen des Edge-Caches entfernt nicht den Cache im Browser der Besucher. Daher ist eine Versionsverwaltung für statische Ressourcen weiterhin erforderlich. Bei Problemen sollten anhand der Antwort-Header sowie der Protokolle der Edge-Knoten und des Ursprungsservers der Cache-Status der Anfrage, ein möglicher Abruf vom Ursprungsserver und die Stelle, an der die Verzögerung auftritt, ermittelt werden. Auf dieser Grundlage lässt sich entscheiden, ob die Regeln angepasst oder die DNS-Einträge zurückgesetzt werden sollen.