Was sollte zuerst geprüft werden, wenn die Website trotz aktivierter CDN-Beschleunigung langsam bleibt?

Nach der Aktivierung der CDN-Beschleunigung melden Nutzer weiterhin „Die Startseite lädt langsam“, „Produktbilder erscheinen erst nach langer Zeit“ oder „Das Backend läuft gelegentlich in ein Timeout“. Viele Verantwortliche vermuten dann sofort eine unzureichende Node-Abdeckung oder eine schlechte Leistung des CDN-Anbieters. Bei der tatsächlichen Fehlersuche zeigt sich jedoch oft, dass ein CDN statische Ressourcen lediglich näher zum Nutzer bringt. Es kann Verzögerungen im Programm des Ursprungsservers, unwirksame Cache-Regeln, Umwege bei der Domainauflösung oder Probleme durch Drittanbieter-Skripte, die den First Screen verlangsamen, nicht automatisch beheben.

Insbesondere bei mehrsprachigen Unternehmenswebsites für Auslandsmärkte, B2B-Anfrageseiten und grenzüberschreitenden Onlineshops verteilen sich Besucher auf verschiedene Regionen wie Nordamerika, Europa und Südostasien. Dass dieselbe Seite in Peking normal getestet wird, bedeutet nicht, dass sie auch über ein mobiles Netzwerk in den USA schnell lädt. Im After-Sales-Support ist es meist effektiver, „langsame Website“ zunächst in überprüfbare Übertragungswege zu zerlegen, als wiederholt CDN-Pakete zu wechseln.

Zuerst klären, wo die Verzögerung liegt: Eine langsame Seite bedeutet nicht unbedingt ein langsames CDN

Es wird empfohlen, zunächst ein Browser-Wasserfalldiagramm eines realen Zugriffs zu speichern und dabei drei Zeitpunkte zu prüfen: DNS-Abfrage, Time to First Byte (TTFB) und Downloadzeit der wichtigsten Ressourcen. Wenn das HTML-Dokument selbst lange auf die Antwort wartet, während Bilder, CSS und JS anschließend normal heruntergeladen werden, liegt das Problem höchstwahrscheinlich beim Ursprungsserver, der Anwendung oder der Datenbank und nicht bei den Edge-Nodes. Wenn das Dokument hingegen schnell zurückgegeben wird, große Bilder, Schriftarten oder Skripte jedoch beim Download warten, sollten Cache-Strategie, Ressourcengröße und paralleles Laden genauer geprüft werden.

Ein häufiger Irrtum ist, dass bei einem Seitenstatus wie „CDN eingebunden“ automatisch alle Inhalte beschleunigt werden. Tatsächlich können dynamische Schnittstellen, Bildlinks mit Parametern, Backend-Pfade und bestimmte Download-Dateien aufgrund von Regeleinstellungen auf den Ursprungsserver zurückgeführt werden. Verantwortliche sollten den Cache-Status in den Response-Headern direkt prüfen, etwa Kennzeichnungen für Treffer, Nichttreffer oder Cache-Umgehung. Die Bezeichnungen unterscheiden sich je nach Anbieter; entscheidend ist jedoch, ob die Anfrage tatsächlich von einem Edge-Node beantwortet wird oder jedes Mal zum Ursprungsserver zurückkehrt.

Die Antwort des Ursprungsservers hat höchste Priorität – nicht von „eingebunden“ täuschen lassen

Ein langsamer Ursprungsserver zeigt sich meist auf mehrere Arten: Der TTFB steigt zu Spitzenzeiten deutlich an; derselbe Seitenaufruf ist beim ersten Besuch langsam und nach dem Aktualisieren etwas schneller; nach der Veröffentlichung von Inhalten im Backend treten im Frontend kurzfristig häufig Timeouts auf; API-Anfragen verbleiben lange im Wartestatus. Dahinter können ausgelastete CPU-, Arbeitsspeicher- oder Verbindungsressourcen des Servers stehen, aber auch Verzögerungen durch CMS-Plugins, Template-Abfragen, Suchschnittstellen oder ungeeignete Datenbankindizes.

Bei Marketing-Websites ist die Startseite häufig anfälliger als Unterseiten. Slider, empfohlene Produkte, Formularvalidierung, Pop-up-Tools und Tracking-Codes konzentrieren sich auf der Startseite. Wenn bei jedem Aufruf mehrere Datenbankmodule in Echtzeit geladen werden, bleibt die Zeit bis zum sichtbaren First Screen unbefriedigend, selbst wenn CSS und Bilder vollständig aus dem CDN-Cache kommen. In diesem Fall sollten Belege in den Logs des Ursprungsservers, im Application Performance Monitoring oder in langsamen Datenbankabfragen gesucht werden, statt zunächst den Cache-Bereich auszuweiten.

Mit einem „starken Cache für die gesamte Website“ sollte besonders vorsichtig umgegangen werden. Produktpreise, Bestände, Anmeldestatus, Warenkörbe und Anfrageformular-Tokens können in der Regel nicht einfach wie statische Seiten gecacht werden. Sicherer ist es, öffentliche Seiten, dynamische Schnittstellen und Backend-Pfade zu unterscheiden: Öffentliche und selten veränderte Inhalte erhalten eine angemessene Cache-Dauer; personalisierte Schnittstellen umgehen den Cache ausdrücklich; für cachefähige Seiten werden Versionsnummern oder aktive Aktualisierungsmechanismen verwendet, damit Nutzer nach Änderungen nicht weiterhin alte Inhalte sehen.

Eine niedrige Cache-Trefferrate weist häufig auf Probleme bei Regeln und Ressourcenverwaltung hin

Bei vielen Websites bleiben Dateinamen statischer Ressourcen langfristig unverändert; selbst ein aktualisiertes Bannerbild heißt weiterhin banner.jpg. Um zu verhindern, dass Nutzer das alte Bild sehen, setzen Verantwortliche die Cache-Zeit dann sehr kurz. Das ist zwar bequem, führt jedoch dazu, dass der CDN-Cache häufig ungültig wird. Besser ist es, aktualisierten Ressourcen Versionsparameter hinzuzufügen oder Dateinamen mit Inhalts-Fingerprints zu verwenden. So können Browser und Edge-Nodes alte Versionen bedenkenlos cachen, während neue Versionen zeitnah wirksam werden.

Ein weiterer oft übersehener Punkt sind Abfrageparameter. Manche Systeme hängen automatisch Zeitstempel, Sprachparameter oder Tracking-Parameter an Bilder und Skripte an. Wenn das CDN jede Parameterkombination als neue URL behandelt, wird der Cache stark fragmentiert. Werden hingegen pauschal alle Parameter ignoriert, kann dies Produktfilter, Bildverarbeitung oder Sicherheitsprüfungen beeinträchtigen. Bei der Analyse sollten die in realen Anfragen am häufigsten vorkommenden Parameter aufgelistet und je nach Ressourcentyp Regeln zum Beibehalten, Ignorieren oder Normalisieren festgelegt werden.

Auch bei Bildern reicht es nicht aus, sie einfach „ins CDN zu legen“. Unkomprimierte Produktoriginalbilder, automatisch abspielende Videos im First Screen und das gleichzeitige Laden von Dutzenden Bildern auf Detailseiten beanspruchen Bandbreite und den Hauptthread. Für Darstellungsbilder können passende Größen entsprechend der Gerätegröße ausgegeben werden; Bilder außerhalb des First Screen können verzögert geladen werden; für Videos eignen sich Vorschaubilder und eine nutzergesteuerte Wiedergabe besser. Der Zielkonflikt ist hier real: Das Designteam wünscht sich Klarheit, das Marketingteam vollständige Informationen, und die Wartung muss akzeptable Dateigrößen und Ladeprioritäten festlegen, statt alles pauschal bis zur Qualitätsminderung zu komprimieren.

DNS-Auflösung und Domain-Konfiguration sind häufig versteckte Risiken bei regionsübergreifenden Zugriffen

Selbst bei zahlreichen CDN-Nodes ist Voraussetzung, dass Nutzer korrekt dorthin geleitet werden. Ein nicht vollständig wirksamer CNAME der Domain, Konflikte in DNS-Einträgen, gleichzeitig vorhandene A-Records und CDN-Einträge oder uneinheitliche IPv6-Konfigurationen können dazu führen, dass manche Nutzer das CDN umgehen und direkt den Ursprungsserver aufrufen. Typisch ist: In einigen Regionen ist die Website schnell, in anderen dauerhaft langsam; im Büronetzwerk funktioniert alles normal, über das Mobilnetz der Kunden treten jedoch häufig Fehler auf.

Bei der Wartung sollte nicht aufgrund einer einzigen lokalen Auflösung ein Schluss gezogen werden. Das endgültige Auflösungsergebnis der Domain sollte in der Netzwerkumgebung des Zielmarkts geprüft werden. Zudem sollten www, die Root-Domain, mobile Subdomains, Bilddomains und Download-Domains jeweils verifiziert werden. Auch die HTTPS-Zertifikatskette und die Anzahl der Weiterleitungen müssen geprüft werden. Wenn eine Seite von http auf https, dann von der Root-Domain auf www und anschließend erneut auf ein Sprachverzeichnis weiterleitet, hat der Nutzer bereits mehrere Round Trips durchlaufen, bevor er tatsächlich Inhalte erhält.

Wenn eine Website gleichzeitig Nutzer in Festlandchina und im Ausland bedient, müssen zudem Bereitstellungs- und Compliance-Status abgeglichen werden. Bei Websites für Zugriffe innerhalb Chinas sollten Registrierungsinformationen und die tatsächliche Servicekonfiguration bei der Anbindung, Servermigration oder Änderung des Rechtsträgers übereinstimmen. Bei Verfahren wie einer neuen ICP-Registrierung, Änderungen oder einer Übernahme der Anbindung können Materialien und Prozessanschlüsse vorab über die Serviceplattform für ICP-Registrierungen in China geprüft werden. Dadurch lassen sich unfreiwillige Verzögerungen beim Go-live aufgrund inkonsistenter Domain-, Rechtsträger- oder Zugangsangaben vermeiden.

Drittanbieter-Ressourcen, die den First Screen verlangsamen, sind ein häufiges Problem bei Marketing-Websites

Werbe-Pixel, Online-Chat, Karten, Captchas, Social-Media-Einbettungen, Verhaltensanalysen und A/B-Test-Tools liegen in der Regel außerhalb der Kontrolle des eigenen CDN. Ein langsam antwortendes externes Skript kann das nachfolgende Rendering blockieren; mehrfach geladene Tag-Manager können das Problem verstärken. Wenn die Domain einer langsamen Anfrage nicht zur eigenen Website gehört, sollte die Verantwortung nicht vollständig der CDN-Konfiguration zugeschrieben werden.

Grundsätzlich sollten Skripte beibehalten werden, die tatsächlich zur Lead-Generierung und Attribution beitragen, während historisch verbliebener Code bereinigt wird. Tools, die die Darstellung im First Screen nicht beeinflussen, können verzögert geladen werden. Für Drittanbieterdienste mit regional eingeschränktem Zugriff oder sporadischen Ausfällen sollten Fallback-Lösungen vorbereitet werden. Gerade Außenhandelswebsites müssen darauf achten, in China gängige Komponenten nicht unverändert auf Auslandswebsites zu übertragen. Die Zugriffskette ausländischer Nutzer ist länger, und jede externe Wartezeit kann die Geduld vor dem Absenden eines Formulars unmittelbar beeinträchtigen.

Fehlersuche in derselben Reihenfolge durchführen, um wirkungslose Änderungen zu vermeiden

Bei der Bearbeitung realer Tickets kann in der Reihenfolge „Seitendokument – Cache-Status – DNS-Steuerung – Ressourcen-Wasserfall – Logs des Ursprungsservers“ vorgegangen werden. Zuerst wird bestätigt, ob HTML langsam ist, anschließend, ob statische Ressourcen aus dem Cache kommen. Nachdem geprüft wurde, ob der Zugriff tatsächlich ins CDN gelangt, werden Programm, Datenbank und Drittanbieterdienste erneut untersucht. Nach jeder Änderung sollte unter denselben regionalen und Netzwerkbedingungen erneut getestet werden, da Netzwerkschwankungen sonst leicht fälschlich als Optimierungseffekt interpretiert werden können.

Bei der langfristigen Betreuung mehrsprachiger Websites, grenzüberschreitender Onlineshops und internationaler Werbeszenarien betrachtet Yiyingbao die Website-Performance in der Regel zusammen mit Werbe-Landingpages, Indexierung und Crawling sowie Formular-Conversions in einer gemeinsamen Kette. Das CDN ist dabei nur ein Glied und kein Allheilmittel. Vorrangig sollte der Engpass gelöst werden, der durch Logs, Response-Header und reale Zugriffspfade nachweisbar ist. Erst wenn dieser Punkt genau identifiziert wurde, lassen sich Anpassungen am Ursprungsserver, an Cache-Regeln oder an der Ressourcenstrategie ohne wiederholte Nacharbeit durchführen.