Welche Ursachen gibt es für eine langsame CDN-Geschwindigkeit? Ausführliche Erläuterung zur Fehlersuche und Optimierung der Website-Beschleunigung

Wechseln Sie nicht vorschnell den Dienstleister – prüfen Sie zunächst genau, an welcher Stelle die Verlangsamung auftritt

　　Bei vielen Websites zeigt das Monitoring nach der Anbindung eines CDN zwar eine „Beschleunigung“ an, doch für die Nutzer fühlt sich die Website weiterhin langsam an. Eine der häufigsten Fehleinschätzungen im Kundendienst besteht darin, alle Probleme auf unzureichende CDN-Knoten zurückzuführen. Tatsächlich ist eine Verlangsamung des CDN häufig kein Einzelproblem, sondern wird durch eine Schwachstelle bei der DNS-Auflösung, dem Verbindungsaufbau, dem Cache-Treffer, dem Origin-Retrieval oder der Organisation der Seitenressourcen verursacht.

　　Richten Sie den Blick bei der Analyse nicht sofort auf die gesamte Ladezeit der Startseite. Prüfen Sie zunächst die einzelnen Abschnitte: Wie lange dauert die DNS-Auflösung, wie lange dauern der Aufbau von TCP und TLS, wie lang ist die Time to First Byte, werden statische Ressourcen aus dem Cache bereitgestellt, betrifft die Verlangsamung alle Regionen oder nur einzelne, und sind Bilder oder Schnittstellen betroffen? Erst wenn die Verbindungskette lokalisiert ist, lassen sich nachfolgende Optimierungen durchführen, ohne dass Nacharbeiten erforderlich werden.

　　Bei der praktischen Bearbeitung empfehle ich, in der Reihenfolge „zuerst den Wirkungsbereich, dann die Trefferquote, anschließend das Origin-Retrieval und zuletzt die Ressourcengröße prüfen“ vorzugehen. Das ist deutlich effizienter.

Zuerst feststellen: Ist die gesamte Website langsam oder nur ein Teilbereich?

　　Dieser Schritt ist grundlegend, aber entscheidend. Denn je nach Art der Verlangsamung unterscheiden sich die anschließenden Prüfrichtungen vollständig.

• Sind Startseite, Listen- und Detailseiten gleichermaßen langsam, sollten zunächst DNS, Zertifikatshandshake, die Auslastung des Origin-Servers und die globale CDN-Konfiguration geprüft werden.
• Sind nur Bilder langsam, sollten in der Regel Bildgröße, Format, Cache-Regeln und häufige Origin-Anfragen untersucht werden.
• Ist nur eine Schnittstelle langsam, liegt das Problem häufig nicht beim CDN, sondern darin, dass dynamische Anfragen nicht zwischengespeichert werden können und die Verarbeitung durch den Origin-Server selbst langsam ist.
• Ist nur ein bestimmtes Land oder eine bestimmte Region langsam, sollten insbesondere die Knotenabdeckung, die Qualität grenzüberschreitender Verbindungen und Schwankungen im Netz des jeweiligen Netzbetreibers geprüft werden.

　　Im Kundendienst liefert die Aussage „Die Website ist sehr langsam“ eigentlich nicht genügend Informationen. Mindestens müssen die Zugriffsregion, die Zugriffszeit, die betroffene Seite oder Backend-Schnittstelle, das gelegentliche Auftreten sowie die Frage ergänzt werden, ob das Problem bei allen Netzbetreibern reproduzierbar ist. Je früher diese Informationen vorliegen, desto weniger Umwege sind erforderlich.

Vorhandene Knoten bedeuten nicht automatisch eine hohe Geschwindigkeit

　　Viele verstehen CDN lediglich als „Nähe zum Nutzer“. Das ist nur teilweise richtig. Eine große Anzahl von Knoten bedeutet nicht, dass die Verteilung zwangsläufig sinnvoll erfolgt; und ein Knoten in der Nähe des Nutzers bedeutet nicht, dass die Verbindung zum Origin-Server kurz ist.

　　Sie können zunächst zwei Aspekte prüfen: Erstens, ob die Unterschiede bei der Time to First Byte zwischen verschiedenen Regionen besonders groß sind; zweitens, ob die Edge-Knoten, auf die bestimmte Regionen bei jeder Auflösung geleitet werden, stabil bleiben. Wird dieselbe Region häufig zu ungeeigneten Knoten geleitet, schwankt das Nutzungserlebnis stark. Das lässt sich nicht einfach durch „mehr Knoten“ lösen. Vielmehr müssen die Routing-Strategie, der Leitungstyp und die Qualität der lokalen Abdeckung betrachtet werden.

　　Bei internationalen Websites tritt dieses Problem noch häufiger auf. Wenn die Nutzer einer Website in Nordamerika, Europa und Südostasien weit verteilt sind, reicht eine Optimierung für nur eine Region nicht aus. Die wichtigsten Märkte müssen separat getestet werden. Im Kundendienst sollte man nicht ausschließlich über ein lokales Netzwerk testen und daraus allgemeine Schlussfolgerungen ziehen.

Niedrige Cache-Trefferquote: Das CDN ist praktisch nur zur Hälfte wirksam

　　Dies ist eine der häufigsten Ursachen. Zwar ist die Website an ein CDN angebunden, doch die Cache-Regeln sind nicht korrekt konfiguriert. Dadurch werden zahlreiche Anfragen weiterhin an den Origin-Server weitergeleitet, sodass die Nutzer kaum eine Beschleunigung wahrnehmen.

　　Bei der Analyse sollten insbesondere folgende Punkte geprüft werden:

1. Enthalten statische Ressourcen zufällige Parameter, sodass dieselbe Datei als unterschiedliche URL behandelt wird?
2. Ist die Cache-Dauer für Bilder, JS und CSS zu kurz, sodass die Ressourcen nur wenige Minuten oder überhaupt nicht zwischengespeichert werden?
3. Enthalten die Antwort-Header Steuerfelder, die das Caching beeinträchtigen?
4. Befinden sich Ressourcen, die eigentlich zwischengespeichert werden könnten, in Pfaden, die eine Authentifizierung erfordern oder Cookies enthalten?

　　Eine sehr praktische Einschätzungsmethode lautet: Wenn die Zugriffszahl statischer Ressourcen nicht niedrig ist, die Bandbreite und die Anfragezahl des Origin-Servers jedoch dauerhaft hoch bleiben, liegt das Problem mit großer Wahrscheinlichkeit bei der Trefferquote. Im Kundendienst sollte man nicht nur prüfen, „ob der Cache aktiviert ist“, sondern auch, „wie viele Anfragen getroffen haben, welche nicht getroffen haben und warum nicht“.

Ein langsamer Origin-Server beeinträchtigt das Nutzungserlebnis oft stärker als ein Knotenproblem

　　Viele Seiten werden beim ersten Öffnen langsam geladen und nach dem Aktualisieren schneller. Das ist in der Regel kein unerklärliches Browserverhalten, sondern auf eine hohe Dauer des Origin-Retrievals zurückzuführen. Wenn ein CDN-Knoten keine Inhalte im Cache hat, muss er diese vom Origin-Server abrufen. Verarbeitet der Origin-Server Anfragen langsam, ist die Ausgangsbandbreite knapp oder ist die regionsübergreifende Verbindung weit, verlängert sich der erste Zugriff deutlich.

　　Bei dieser Art von Problem empfiehlt sich folgende Reihenfolge:

　　Bei manchen Websites ist der Origin-Server zwar korrekt bereitgestellt, doch das Content Management, der Dokumentendownload und Berichtsseiten enthalten zahlreiche große Dateien. Dadurch kann die Belastung des Origin-Servers plötzlich ansteigen. Wird beispielsweise im Dokumentationszentrum eine Dokumentseite wie 研究 zu Steuerplanungsfragen von Stromnetzunternehmen eingebunden, kann eine große Originaldatei in Verbindung mit einer kurzen Cache-Dauer den Origin-Server leicht überlasten. In diesem Fall sollten für Download-Ressourcen separate Cache-Strategien eingerichtet werden, anstatt sie mit gewöhnlichen Seiten zu vermischen.

Die Konfiguration ist korrekt, aber die Ressourcen selbst sind zu umfangreich

　　Ein CDN verbessert die Übertragungseffizienz, ersetzt jedoch keine Frontend-Optimierung. Wenn eine Seite langsam ist, prüfen viele Wartungsmitarbeiter zunächst die Dienstkette. Am Ende stellt sich jedoch häufig heraus, dass das Problem in der Seite selbst liegt: Das große Bild im sichtbaren Bereich wurde nicht komprimiert, es gibt zu viele Karussellbilder, zu viele Skripte oder zu viele nachgeladene Drittanbieter-Codes.

　　Ist das Ressourcenvolumen zu groß, muss der Browser selbst bei einer schnellen Antwort des Knotens Zeit für Download, Analyse und Ausführung aufwenden. Für den Nutzer wirkt die Seite weiterhin langsam. In dieser Phase sollte nicht die CDN-Konsole, sondern das Wasserfalldiagramm der Seitenanfragen geprüft werden: Welche Ressource ist am größten, welche wird zuletzt geladen, welche blockiert das Rendering und welche wird wiederholt geladen? Besonders Marketing-Websites und mehrsprachige Websites enthalten leicht wiederholt Skripte in unterschiedlichen Sprachvorlagen, was nur schwer erkennbar ist.

HTTPS, Weiterleitungen und Protokolldetails können den ersten Seitenaufbau ebenfalls verlangsamen

　　Die vom Nutzer beschriebene „langsame Ladezeit“ tritt häufig auf, bevor der Seiteninhalt erscheint. Beispielsweise können eine Weiterleitung von HTTP zu HTTPS, von der Root-Domain zu www oder von einem alten Pfad zu einem neuen Pfad die Ladezeit deutlich verlängern, wenn mehrere Weiterleitungen aufeinanderfolgen.

　　Auch eine zu lange Zertifikatskette, wiederholte Handshakes nach Fehlern oder eine instabile Protokollaushandlung können die Time to First Byte verzögern. Bei der Wartung können die Weiterleitungskette in den Browser-Entwicklertools oder in den Ergebnissen eines Geschwindigkeitstests direkt geprüft werden. Wenn die Anfrage der Startseite bereits zwei- oder dreimal weitergeleitet wurde, bevor sie den eigentlichen Geschäftsinhalten erreicht, handelt es sich nicht um ein kleines Problem. Die Weiterleitungen sollten möglichst auf einen einzigen Schritt reduziert werden.

Dynamische Schnittstellen, die fälschlicherweise als CDN-Problem betrachtet werden, nicht übersehen

　　Manche Backend-Mitarbeiter gehen davon aus, dass auch Schnittstellen schnell sein müssten, sobald die gesamte Website über ein CDN läuft. Tatsächlich eignen sich dynamische Anfragen wie Anfragen mit Login-Status, Echtzeitangebote, Bestandsabfragen und Formularübermittlungen häufig nicht für das Caching. Die Ursache ihrer Langsamkeit liegt meist auf der Anwendungsebene, in der Datenbank, in der Logik zur Zusammenführung von Schnittstellen oder bei Aufrufen von Drittanbieterdiensten.

　　Die Beurteilung ist einfach: Werden statische Ressourcen sofort geladen, während die Schnittstelle lange wartet und insbesondere die Wartezeit auf die Serverantwort deutlich verlängert ist, sollte die Fehlersuche nicht weiter auf die Knoten konzentriert werden. Prüfen Sie zunächst die Antwortzeit der Schnittstelle, langsame Abfragen und die Anwendungsprotokolle. Anschließend kann entschieden werden, ob Edge-Caching, eine Aufteilung der Schnittstelle oder eine Herabstufung der Funktionalität erforderlich ist.

Verlangsamungen zu Spitzenzeiten sollten gemeinsam mit der Traffic-Struktur betrachtet werden

　　Manche Websites funktionieren im Normalbetrieb einwandfrei, werden jedoch langsam, sobald Werbung geschaltet oder eine Kampagne gestartet wird. In solchen Fällen reicht es nicht aus, nur die Bandbreitenwerte zu betrachten. Es muss auch geprüft werden, ob plötzlich zahlreiche Anfragen nach nicht im Cache befindlichen Ressourcen, bösartige Crawling-Aktivitäten, konzentrierte Zugriffe auf häufig aufgerufene Dateien oder gleichzeitig zugreifende Nutzer aus vielen Regionen auftreten.

　　Sinkt die CDN-Trefferquote während Spitzenzeiten deutlich, hat sich die Anfragestruktur verändert. Wird die Bandbreite für das Origin-Retrieval vollständig ausgelastet, müssen sowohl das Caching als auch die Belastungsauslegung des Origin-Servers angepasst werden. Sind nur bestimmte Downloadseiten langsam, kann eine separate Domain oder eine Aufteilung der Cache-Regeln erforderlich sein. Ressourcenseiten mit Inhalten wie 研究 zu Steuerplanungsfragen von Stromnetzunternehmen sollten beispielsweise separat hinsichtlich Zugriffsspitzen und Cache-Leistung beobachtet und nicht gemeinsam mit den Durchschnittswerten gewöhnlicher Seiten bewertet werden.

Eine praktische Prüfreihenfolge für Kundendienst und Wartung

　　Bei der Bearbeitung eines Tickets kann in folgender Reihenfolge vorgegangen werden:

1. Zunächst die Bedingungen für die Reproduktion erfassen: Region, Netzbetreiber, Zeitraum, Seitentyp und die Frage, ob der erste Zugriff langsamer ist.
2. Die Verbindungskette des Geschwindigkeitstests prüfen und DNS, Verbindungsaufbau, TLS, Time to First Byte und Downloadzeit aufschlüsseln.
3. CDN-Trefferquote und Anteil des Origin-Retrievals abgleichen und die Ressourcentypen mit Cache-Fehlern ermitteln.
4. Den Origin-Server direkt testen und prüfen, ob Antwortzeit, Bandbreite, gleichzeitige Verbindungen oder Sicherheitsrichtlinien des Origin-Servers die Leistung beeinträchtigen.
5. Weiterleitungen, Zertifikate und Protokollkonfiguration überprüfen und bedeutungslose Weiterleitungen reduzieren.
6. Zur Seitenebene zurückkehren und große Bilder, Skripte, Drittanbieterressourcen sowie blockierende Ladevorgänge optimieren.

　　Mit dieser Vorgehensweise lassen sich die meisten Probleme nach dem Muster „Trotz CDN ist die Website weiterhin langsam“ klar voneinander unterscheiden. Erfahrungsgemäß bringt es meist den größten Nutzen, zunächst die Trefferquote und das Origin-Retrieval zu optimieren und anschließend die Seitenressourcen zu bearbeiten. Bei Websites mit regionsübergreifenden Zugriffen und komplexen internationalen Leitungen sollten die Testpunkte auf die Zielmärkte verteilt werden. Eine einzelne Netzwerkumgebung darf nicht als Ersatz für das tatsächliche Nutzererlebnis dienen. Im Kundendienst sollte man bei CDN-Geschwindigkeitsproblemen keinesfalls vorschnell die Lösung wechseln. Am effektivsten ist weiterhin eine schrittweise Prüfung der Verbindungskette: Wo die Verlangsamung auftritt, dort sollte die Optimierung ansetzen.