Lässt sich die globale CDN-Abdeckung allein anhand der Anzahl der Knoten beurteilen?

Die globale CDN-Abdeckung lässt sich nicht allein an der Anzahl der PoPs messen. Die Gesamtzahl gibt Aufschluss über den Umfang der Infrastruktur, beantwortet aber nicht unmittelbar die Frage, ob Zielkunden die Website zuverlässig und schnell erreichen können. Bei der Auswahl ist entscheidender: Wohin werden Nutzer in den Zielmärkten geleitet, über welche Netzwerke erfolgt die Verbindung und funktioniert der Zugriff auf den Origin-Server reibungslos, wenn Inhalte nicht im Cache liegen?

Bei der Bewertung einer globalen CDN-Lösung sollte „globale Abdeckung“ in die Abdeckung der Zielregionen, die Erreichbarkeit über die jeweiligen Netzbetreiber und die im Geschäftsbetrieb gemessene Leistung aufgeschlüsselt werden. Selbst wenn zwei Anbieter eine ähnliche Anzahl von PoPs angeben, können die Zugriffsergebnisse über Festnetz- und Mobilfunknetze im selben Land deutlich voneinander abweichen.

Bei der Anzahl der PoPs muss zunächst eine einheitliche Zählweise gelten

Mit „PoP“ können Anbieter physische Rechenzentren, Edge-Zugangspunkte oder auch mehrere Bereitstellungseinheiten innerhalb derselben Stadt meinen. Ein Edge-Zugangspunkt (PoP) und die Anzahl der Server sind nicht dieselbe Kennzahl. Zahlen, die auf unterschiedlichen Zählweisen beruhen, lassen sich daher nicht direkt vergleichen.

Außerdem muss geklärt werden, ob die angegebenen Ressourcen im geplanten Tarif und mit den vorgesehenen Funktionen verfügbar sind. An manchen Standorten werden zwar Traffic-Zugang oder Sicherheitsverarbeitung angeboten, aber nicht unbedingt dieselben Caching-Funktionen. In einigen Regionen gelten zusätzliche Gebühren oder Aktivierungsbedingungen. Eine globale PoP-Karte kann daher nur als erster Orientierungspunkt dienen und ersetzt keine Angaben zum tatsächlich verfügbaren Leistungsumfang.

Aussagekräftiger als eine möglichst hohe Gesamtzahl ist es, vom Anbieter eine Aufstellung der verfügbaren Zugangspunkte, unterstützten Funktionen und Tarifbeschränkungen für die relevanten Länder und Städte anzufordern. Liegt der Geschäftsschwerpunkt in Europa und Nordamerika, sollten Standorte in anderen Regionen dem Angebot nicht allein wegen ihrer hohen Dichte zusätzliche Pluspunkte verschaffen. Umfassen die wichtigsten Märkte Südostasien, den Nahen Osten oder Lateinamerika, müssen diese Regionen jeweils separat geprüft werden. Eine Abdeckung auf Kontinentebene sagt nichts über die tatsächliche Leistung vor Ort aus.

Eine geringe geografische Entfernung bedeutet nicht automatisch einen kurzen Netzwerkpfad

Zwischen Nutzern und Edge-PoPs liegen die Zusammenschaltung der Netzbetreiber, die netzübergreifende Übertragung und die Wahl der Routing-Route. Ein PoP kann sich in einer nahe gelegenen Stadt befinden, während der Netzbetreiber des Nutzers den Verkehr über andere Regionen dorthin leiten muss. Das Zugriffserlebnis ist dann nicht unbedingt besser als bei einem weiter entfernten PoP mit direkterer Netzanbindung.

Auch der Routing-Mechanismus beeinflusst die Abdeckungsqualität. DNS-basiertes Routing kann vom Standort des rekursiven Resolvers beeinflusst werden. Bei Anycast leitet das Netzwerk Anfragen an einen Zugangspunkt weiter; das bedeutet jedoch nicht, dass dabei jedes Mal die geringste Latenz erreicht wird. Allein aus dem Einsatz einer bestimmten Technologie lässt sich keine bessere globale Zugriffsleistung ableiten.

Um festzustellen, ob die Abdeckung tatsächlich ausreicht, sollte geprüft werden, welcher Zugangspunkt im Zielnetz tatsächlich verwendet wird und wie sich Verbindungsdauer, Paketverlust und Schwankungen zu Spitzenzeiten entwickeln. Traceroute kann bei der Fehlersuche hilfreich sein. Eine ausbleibende Antwort eines Routers auf dem Pfad oder Paketverlust auf einem einzelnen Hop ist jedoch kein ausreichender Beleg für eine Störung der geschäftskritischen Verbindung. Maßgeblich bleibt das Ergebnis der Ende-zu-Ende-Anfrage.

Die Cache-Treffergeschwindigkeit sagt nichts über die Geschwindigkeit der gesamten Website aus

CDN-Demos zeigen häufig besonders eindrucksvoll die Beschleunigung statischer Dateien. Websites für internationale Märkte bestehen jedoch nicht nur aus Bildern und Stylesheets. Produktdetailseiten, mehrsprachige Seiten, die interne Suche, Anfrageformulare oder Warenkörbe können unterschiedliche Caching-Regeln erfordern oder sogar in Echtzeit auf den Origin-Server zugreifen müssen.

Bei einem Cache-Treffer verläuft die Anfrage hauptsächlich zwischen „Nutzer und Edge-PoP“. Bei einem Cache-Fehler kommt der Pfad „Edge-PoP und Origin-Server“ hinzu. Befindet sich der Origin-Server weit von den wichtigsten Märkten entfernt oder ist die Verbindung dorthin instabil, bleiben der erste Aufruf und Seiten mit geringer Zugriffshäufigkeit langsam. Mehr PoPs garantieren außerdem nicht, dass alle Inhalte überall im Cache liegen, und beseitigen Engpässe beim Zugriff auf den Origin-Server nicht automatisch.

Bei Tests zur Anbieterauswahl müssen warmer Cache, kalter Cache und dynamische Anfragen getrennt betrachtet werden. Warme Cache-Einträge dienen dazu, die Auslieferung am Edge zu prüfen; kalte Cache-Einträge zeigen die Verbindung zum Origin-Server. Mit dynamischen Anfragen wird geprüft, ob Verbindungswiederverwendung und Übertragungsoptimierungen die Geschäftsabläufe tatsächlich verbessern. Hierarchisches Caching oder Optimierungen für den Zugriff auf den Origin-Server können bestimmte wiederholte Anfragen reduzieren. Die Wirkung hängt jedoch von der Konfiguration und den Eigenschaften der Inhalte ab und ist kein automatisch eintretender Vorteil.

Auch die Regeln für Cache-Keys, Query-Parameter, Cookies und Sprachversionen müssen überprüft werden. Eine hohe Trefferquote bedeutet nicht zwangsläufig, dass die Konfiguration korrekt ist: Werden personalisierte Inhalte fälschlich gemeinsam im Cache gespeichert, kann die Geschwindigkeitssteigerung zu geschäftlichen oder datenschutzbezogenen Risiken führen.

Aus dem „Abdeckungsversprechen“ einen reproduzierbaren Test machen

Die Teststandorte sollten anhand des tatsächlichen Traffics, der Kundenverteilung und der geplanten Zielmärkte ausgewählt werden. Dabei sollten repräsentative Festnetz- und Mobilfunknetze vor Ort berücksichtigt werden. Messpunkte auf Cloud-Servern eignen sich für die kontinuierliche Überwachung, ersetzen jedoch nicht vollständig die Netzwerke der Endnutzer. Wenn möglich, sollten die Ergebnisse daher durch Messungen bei echten Nutzern ergänzt werden.

Beim Vergleich verschiedener Lösungen sollten Origin-Server, Dateiinhalte, Cache-Regeln und Testzeitraum möglichst gleich bleiben. Außerdem sind der tatsächlich verwendete Zugangspunkt und der Cache-Status zu protokollieren. Die Ergebnisse eines warmen Caches bei einem Anbieter sollten nicht mit der ersten Anfrage bei einem anderen Anbieter verglichen werden. Auch ein einzelner Screenshot eines Geschwindigkeitstests reicht nicht als Entscheidungsgrundlage.

• Zeiten aufschlüsseln: DNS-Auflösung, Verbindungsaufbau, TLS-Handshake, Time to First Byte und Downloadzeit erfassen. So lässt sich vermeiden, eine langsame Verarbeitung auf dem Origin-Server fälschlich als unzureichende Edge-Abdeckung einzuordnen.
• Auf die Werte im oberen Perzentil achten: Neben dem Median auch P95, Fehlerrate und Zeitüberschreitungsrate berücksichtigen und die Werte nach Region und Netzbetreiber aufschlüsseln. Globale Durchschnittswerte können Probleme in wichtigen Märkten verdecken.
• Reale Geschäftsobjekte verwenden: Kleine Seitenressourcen, große Bilder oder Dokumente sowie tatsächlich verwendete dynamische Schnittstellen testen. Eine einzelne kleine Datei reicht nicht aus, um die gesamte Website zu bewerten.
• Kontinuierlichen Zugriff und Störfälle abdecken: Über mehrere Zeiträume hinweg wiederholt testen, das Umschalten bei Störungen eines PoP oder des Origin-Servers überprüfen und kontrollieren, ob bei der Wiederherstellung deutlich erkennbare Fehler auftreten.

Zur Bewertung des Seitenerlebnisses sollten auch Kennzahlen im Browser, beispielsweise LCP, herangezogen werden. Eine kürzere Time to First Byte bedeutet nicht zwangsläufig, dass die Hauptinhalte schneller angezeigt werden. Auch die Skriptausführung sowie das Laden von Drittanbieter-Komponenten und Bildern können Engpässe verursachen. Nicht jedes Problem ist dem CDN zuzuschreiben.

Entscheidend sind nachweisbare Ergebnisse in den wichtigsten Märkten

Die Abnahmekriterien sollten sich am Geschäft orientieren: Welche Märkte müssen die Anforderungen erfüllen, welche Latenz und Fehlerrate sind akzeptabel und welche dynamischen Funktionen dürfen nicht beeinträchtigt werden? Es gibt keinen einheitlichen Grenzwert in Millisekunden, der für alle Websites gilt. Ebenso sollten hervorragende Ergebnisse in nicht zentralen Regionen deutliche Schwächen in den wichtigsten Märkten für die Kundengewinnung nicht ausgleichen können.

Außerdem sollte geklärt werden, ob der Anbieter Protokoll- oder Überwachungsdaten nach Region, Statuscode und Cache-Status bereitstellen kann und welche Möglichkeiten zur Fehleranalyse und Unterstützung bei regionalen Störungen bestehen. Ein Versprechen zur allgemeinen Verfügbarkeit, das konkrete Störungen in einzelnen Regionen nicht nachvollziehbar macht, reicht als Grundlage für die Bewertung der globalen Abdeckung nicht aus.

Die Anzahl der PoPs eignet sich für eine Vorauswahl. Ob eine Lösung tatsächlich passt, entscheiden jedoch die Zuverlässigkeit des Zugriffs über die Netzbetreiber der Zielmärkte, die Leistung der gesamten Verbindung bei warmem und kaltem Cache sowie die Fähigkeit, Störungen zu erkennen und zu beheben. Kann ein Anbieter lediglich eine globale Karte vorweisen, ohne diese Nachweise zu liefern, sollte ein Aufpreis nicht allein mit „mehr PoPs“ begründet werden.