Wie lässt sich untersuchen, warum Kunden in Mexiko länger als 5 Sekunden auf den Website-Aufruf warten?

Wenn ein mexikanischer Kunde meldet, dass sich eine Website erst nach mehr als 5 Sekunden öffnet, muss das nicht an einer unzureichenden Serverleistung liegen. Auch die grenzüberschreitende Netzwerkverbindung, ein Cache-Fehlzugriff oder langsame Werbeskripte können die Seite ausbremsen. Bei der Bearbeitung von Supportfällen wird häufig vorschnell der Server gewechselt. Wenn jedoch der Browser des Kunden hauptsächlich Zeit für das Herunterladen von Bildern oder die Ausführung von Skripten benötigt, löst ein Umzug das Problem möglicherweise nicht. Klären Sie zuerst, wo die Verzögerung entsteht, und entscheiden Sie dann, was geändert werden soll.

Die vom Kunden genannten „5 Sekunden“ zu einem reproduzierbaren Problem machen

Um die Ursachen für Ladezeiten von mehr als 5 Sekunden auf einer Website für Kunden in Mexiko zu ermitteln, müssen die jeweilige Seite und die Zugriffsbedingungen berücksichtigt werden. Mit „fertig geladen“ kann der Kunde meinen, dass der sichtbare Bereich beim ersten Aufruf angezeigt wird, oder dass alle Bilder und das Chatfenster auf der Seite erschienen sind. Diese beiden Fälle erfordern unterschiedliche Prüfungen. Bitten Sie den Kunden um die URL, den Zeitpunkt des Auftretens, den Standort, das Gerätemodell, den Browser und die Netzwerkart. Fragen Sie außerdem, ob die Seite weiß bleibt oder ob der Inhalt im sichtbaren Bereich nur langsam vollständig angezeigt wird. Wenn möglich, ist eine Bildschirmaufnahme hilfreicher als die pauschale Aussage „Die Website ist sehr langsam“.

Testen Sie anschließend dieselbe URL auf der Startseite, der vom Kunden gemeldeten Produktseite oder der Anzeigen-Landingpage und unterscheiden Sie dabei zwischen dem ersten und einem erneuten Aufruf. Berücksichtigen Sie möglichst sowohl lokale Mobilfunk- als auch Festnetze. Wenn nur ein Fernzugriffstest möglich ist, sollten Sie den Testknoten und die Netzwerkbedingungen dokumentieren. Die Messergebnisse eines Büros in China dürfen nicht mit dem tatsächlichen Nutzungserlebnis eines Kunden in Mexiko gleichgesetzt werden.

Prüfen Sie außerdem, ob die Test-URL Werbeparameter, einen Sprachpfad oder eine Weiterleitung enthält. Der tatsächliche Link nach einem Anzeigenklick kann sich von der direkt aufgerufenen Startseite unterscheiden. Wird das übersehen, kommt es leicht zu Fällen, in denen „der Supporttest normal verläuft, der Zugriff des Kunden aber weiterhin langsam ist“. Screenshots und Protokolle sollten vor der Weitergabe anonymisiert werden, wenn sie Kontoinformationen oder personenbezogene Kundendaten enthalten.

Die Zugriffskette aufschlüsseln: Ist die Verbindung langsam oder das Rendering der Seite?

Öffnen Sie im Browser die Entwicklertools und dort den Netzwerkbereich. Leeren Sie den Cache und laden Sie die Seite erneut. Prüfen Sie das Wasserfalldiagramm der Anfragen. Betrachten Sie zuerst die DNS-Auflösung, den Verbindungsaufbau und die erste Dokumentanfrage, anschließend Ressourcen wie Bilder und Skripte. Wenn Sie die Dauer der einzelnen Schritte vergleichen, lässt sich die Ursache leichter eingrenzen, als wenn Sie nur die gesamte Ladezeit betrachten.

Die Antwort auf das erste Dokument ist langsam: Prüfen Sie die DNS-Auflösung, den Verbindungsaufbau, Weiterleitungen und die Verarbeitungszeit des Servers. Die Time to First Byte (TTFB) gibt die Wartezeit vom Absenden der Anfrage bis zum Empfang des ersten Antwortbytes an. Sie kann jedoch sowohl Netzwerk- als auch Serverzeit umfassen. Allein anhand dieses Werts lässt sich daher nicht auf eine langsame Datenbank schließen. Zur weiteren Aufschlüsselung können Sie Serverprotokolle, die Antwortzeit der Anwendung und Testergebnisse aus verschiedenen Regionen heranziehen.

Die Dokumentantwort ist normal, aber der sichtbare Bereich wird weiterhin nur verzögert angezeigt: Prüfen Sie insbesondere das große Bild im sichtbaren Bereich, Stylesheets, Schriftarten und Skripte, die das Rendering blockieren. Verwendet beispielsweise eine Website für Exportgeräte ein unkomprimiertes Produktbild in voller Größe als Banner, muss das Smartphone eine große Datei herunterladen und dekodieren, bevor es sie anzeigen kann. Dass sich die Seite öffnen lässt, bedeutet nicht, dass der Kunde bereits die wichtigsten Inhalte sieht.

Der sichtbare Bereich wird angezeigt, aber die Seite zeigt weiterhin einen Ladevorgang an: Prüfen Sie, ob Anfragen von Drittanbieter-Tracking, Werbe-Conversion-Codes, dem Live-Chat oder Videos nicht abgeschlossen werden. Beobachten Sie dabei auch, ob Schaltflächen und Formulare funktionieren. Ein dauerhaft rotierendes Ladesymbol bedeutet nicht unbedingt, dass der Kunde nicht auf der Seite navigieren kann. Wenn die Skriptausführung jedoch den Hauptthread auslastet, kann die Seite sichtbar, aber nicht bedienbar sein.

Langsame Zugriffe aus Mexiko: Diese Punkte zuerst prüfen

Die grenzüberschreitende Netzwerkverbindung ist ein häufiger Ansatzpunkt bei der Fehlersuche, die Ursache sollte jedoch nicht pauschal auf die „große Entfernung“ zurückgeführt werden. Das Ergebnis hängt auch vom Standort des Ursprungsservers, den Leitungen der Netzbetreiber, der Zuweisung von Knoten und dem aktuellen Netzwerk des Kunden ab. Dauern die Verbindungs- oder Downloadphasen bei mehreren Testpunkten in Mexiko länger, während andere Regionen vergleichsweise normal abschneiden, sollten Sie prüfen, ob das Content Delivery Network (CDN) den Zielbereich abdeckt, die Domain korrekt eingebunden ist und welchen Cache-Status die Antwortheader angeben. Die Cache-Statuskennzeichnungen unterscheiden sich je nach Anbieter. Maßgeblich ist daher dessen Dokumentation.

Es reicht nicht aus, nur zu bestätigen, dass „CDN aktiviert“ ist. Produktbilder können im Cache gespeichert sein, während HTML-Seiten bei jedem Aufruf vom Ursprungsserver abgerufen werden. Auch Werbelinks mit Abfrageparametern können je nach Cache-Regeln zu unterschiedlichen Ergebnissen führen. Unterscheiden Sie bei der Prüfung zwischen statischen Ressourcen und dynamischen Seiten: Bilder und Stylesheets eignen sich in der Regel zum Caching gemäß einer festgelegten Aktualisierungsstrategie. Inhalte mit Anmeldestatus, Warenkorb oder Kundendaten dürfen dagegen nicht ohne Weiteres öffentlich zwischengespeichert werden. Prüfen Sie vor Änderungen den Cache-Schlüssel, die Invalidierungsmethode und die Regeln für den Abruf vom Ursprungsserver.

Priorisieren Sie bei den Seitenressourcen Dateien, die im Wasserfalldiagramm groß sind, früh geladen werden und die Darstellung des sichtbaren Bereichs beeinflussen, anstatt alle Bilder pauschal zu komprimieren. Erstellen Sie Bilder in der jeweils angezeigten Größe und aktivieren Sie Lazy Loading für Bilder außerhalb des sichtbaren Bereichs. Das Hauptbild im sichtbaren Bereich sollte normalerweise nicht ohne Prüfung verzögert geladen werden, da sonst die wichtigsten Inhalte später erscheinen könnten. Als Hintergrundvideo können Sie ein Titelbild verwenden und das Video erst nach einer Benutzeraktion laden. Das eignet sich besonders für mobile Anzeigen-Landingpages.

Prüfen Sie bei mehrsprachigen Websites auch die Sprachweiterleitungen. Wenn Besucher aus Mexiko zunächst auf der Startseite in der Standardsprache landen und dann nach der Ländererkennung auf die spanische Seite weitergeleitet werden, verlängert der zusätzliche Redirect die Wartezeit. Besser ist es, Anzeigen und Links aus sozialen Medien direkt auf die Zielseite in der passenden Sprache zu verweisen und zugleich einen gut erkennbaren Spracheinstieg beizubehalten. Prüfen Sie vor Änderungen an Pfaden bestehende Suchmaschinenindexierungen sowie Weiterleitungen und Tracking-Einstellungen der Anzeigenlinks.

Vermeiden, dass Optimierungen Anfragen und die Zuordnung von Anzeigen beschädigen

Website-Erstellung, SEO und Anzeigen werden häufig von unterschiedlichen Personen betreut. Besonders Probleme mit Skripten treten daher leicht wiederholt auf. Ein typischer Fall: Auf einer Landingpage werden mehrere Tracking-Codes, Werbe-Conversion-Tags und Live-Chat-Plugins eingebunden. Jede einzelne Komponente mag nützlich sein, zusammen können sie jedoch die Anzeige des sichtbaren Bereichs verzögern. Listen Sie vor der Bearbeitung die Verantwortlichen und den Zweck der Skripte auf. Entfernen Sie zunächst Codes, deren Nutzung eingestellt wurde oder die doppelt vorhanden sind, und prüfen Sie anschließend, welche Skripte später geladen werden können.

Eine verzögerte Ausführung ist nicht ohne Folgen: Werden Skripte zu spät geladen, können Conversions unregistriert bleiben oder Formular- und Chatfunktionen beeinträchtigt werden. Nehmen Sie die Änderungen am besten einzeln in einer Testumgebung vor. Prüfen Sie nach der Veröffentlichung, ob Werbeparameter erhalten bleiben, Formulare abgesendet werden können, Anfragenachrichten ankommen und Conversion-Ereignisse wie erwartet ausgelöst werden. Bei Projekten, die integrierte Website- und Marketingplattformen wie 易营宝 nutzen, sollten Sie außerdem klären, ob die betreffenden Einstellungen von der Plattform oder auf Kundenseite verwaltet werden, damit keine doppelten Änderungen vorgenommen oder Tracking-Codes versehentlich gelöscht werden.

Nach der Behebung unter denselben Bedingungen erneut testen und die Ergebnisse dokumentieren

Führen Sie den erneuten Test möglichst mit derselben Seite, Region, demselben Gerät und denselben Netzwerkbedingungen durch und erfassen Sie die Ergebnisse sowohl beim ersten Zugriff als auch nach einem Cache-Treffer. Vergleichen Sie neben der gesamten Ladezeit auch die Time to First Byte, den Zeitpunkt, zu dem die wichtigsten Inhalte im sichtbaren Bereich erscheinen, und ob Benutzer normal klicken und Formulare absenden können. Ein einzelner Test zeigt nur die Situation zum jeweiligen Zeitpunkt. Wenn die Ergebnisse stark schwanken, wiederholen Sie den Test zu unterschiedlichen Uhrzeiten und bewahren Sie das Wasserfalldiagramm der Anfragen sowie wichtige Antwortheader auf.

Wenn nur einzelne Kunden über ein bestimmtes Netzwerk langsame Zugriffe erleben, während andere lokale Netzwerke normal funktionieren, bitten Sie sie, Mobilfunk- und Festnetzverbindungen im Wechsel zu testen. Leiten Sie die Ergebnisse zusammen mit den DNS-Auflösungen und Informationen zu fehlgeschlagenen Anfragen zur Prüfung an den Netzwerkanbieter weiter. Wenn das Problem über mehrere Zugangswege hinweg reproduzierbar ist, leiten Sie es anhand der Belege gezielt an die zuständigen Personen für Server, Website-Erstellung oder Anzeigenbetreuung weiter. Ein Ticket mit den betroffenen URLs, dem Zeitpunkt, den Testbedingungen und bereits ausgeschlossenen Ursachen lässt sich in der Regel besser bearbeiten als eine pauschale Aufforderung, „die Website schneller zu machen“.