Ob die Startseite einer internationalen Website langsam lädt und zuerst der Server aufgerüstet oder die Bilder komprimiert werden sollten, hängt davon ab, in welchem Abschnitt Zeit verloren geht: Reagiert die Seite lange nicht, sollten zuerst Verbindung und Server geprüft werden. Wird der Text bereits angezeigt, während das Hauptbild noch auf sich warten lässt, sollten zuerst die Bildanfragen untersucht werden. Sind die Ressourcen heruntergeladen, bleibt die Seite aber weiß oder reagiert verzögert, müssen Skripte und Rendering geprüft werden. Das für die Wartung zuständige Personal sollte „langsam“ zunächst in konkrete Phasen aufteilen und erst dann entscheiden, was geändert werden muss.
Die Fehlersuche muss außerdem die Zugriffsbedingungen der Zielkunden berücksichtigen. Dass die Website im Büro in China normal lädt, beweist nicht, dass sie auch auf Mobilgeräten in Europa und den USA reibungslos funktioniert. Ob Methoden zur Optimierung der Ladegeschwindigkeit einer internationalen Website wirksam sind, sollte anhand des Zugriffs aus den wichtigsten Kundengewinnungsregionen, auf den tatsächlichen Landingpages und mit typischen Geräten beurteilt werden.
Wählen Sie zunächst eine Seite, zu der Beschwerden vorliegen, oder eine wichtige Anzeigen-Landingpage. Notieren Sie Zugriffsregion, Gerät, Netzwerkbedingungen und ob es sich um den ersten Besuch handelt. Tritt das Problem bei einer bestimmten Sprachversion oder einer URL mit Anzeigenparametern auf, sollte der ursprüngliche Link für den Test beibehalten werden. So wird vermieden, dass das Problem übersehen wird, wenn stattdessen die Startseite aufgerufen wird.
Verwenden Sie die Bereiche Network und Performance in den Browser-Entwicklertools sowie Tools wie PageSpeed Insights und achten Sie besonders auf drei Aspekte:
Einzelergebnisse aus den Tools helfen bei der Lokalisierung des Problems; reale Nutzerdaten zeigen dessen Ausmaß. Da sich Testumgebungen und Erhebungszeiträume unterscheiden, müssen die Ergebnisse nicht exakt übereinstimmen. Beobachten Sie die Werte mindestens mehrmals und halten Sie die Ergebnisse sowohl für den ersten Besuch als auch nach einem Cache-Treffer getrennt fest, damit gelegentliche Schwankungen nicht fälschlich als dauerhaftes Problem gelten.

Wenn das Seitendokument selbst lange auf sich warten lässt, prüfen Sie zunächst in der Anforderungszeit die DNS-Auflösung, den Verbindungsaufbau, den TLS-Handshake und die Wartezeit auf die Antwort. Allein aus einer hohen TTFB auf eine „unzureichende Serverkonfiguration“ zu schließen, kann dazu führen, dass das Budget falsch eingesetzt wird: Auch die Netzwerkübertragung über große Entfernungen, der Verbindungsaufbau und die Anwendungsverarbeitung können Zeit kosten.
Lädt dieselbe Seite in der Nähe des Servers normal, ist im Zielmarkt aber deutlich langsamer, sollten zuerst der Netzwerkpfad, die CDN-Abdeckung und Cache-Treffer geprüft werden. Sind mehrere Regionen betroffen, sollten anhand der Serverprotokolle Datenbankabfragen, Template-Rendering, Wartezeiten auf Schnittstellen und Ressourcenauslastung untersucht werden.
Auch der Einsatz eines CDN bedeutet nicht, dass die Seite zwangsläufig beschleunigt wird. Bilder können aus dem Cache geladen werden, während HTML bei jedem Aufruf vom Ursprungsserver abgerufen wird. Mehrsprachige Pfade, Abfrageparameter oder Cookies können ebenfalls dazu führen, dass der Cache nicht greift. Prüfen Sie vor Änderungen, ob tatsächlich Cache-Treffer vorliegen. Bei Anmeldungen, Warenkörben oder personalisierten Inhalten müssen die Cache-Grenzen klar festgelegt werden, damit keine nutzerspezifischen Inhalte für andere Besucher zwischengespeichert werden.
Sind Überschrift und Navigation bereits sichtbar, während das große Bild im sichtbaren Bereich lange leer bleibt, suchen Sie die Anfrage für dieses Bild. Beginnt der Download früh und dauert lange, sollten Sie Bildabmessungen und Komprimierung optimieren und ein kompatibles modernes Bildformat verwenden. Für Mobilgeräte sollten außerdem Bilder bereitgestellt werden, deren Abmessungen zur angezeigten Größe passen, damit nicht das große Desktopbild heruntergeladen wird.
Startet die Bildanfrage erst spät, lässt sich das Problem durch Komprimierung allein nur teilweise beheben. Prüfen Sie, ob das Bild versehentlich mit Lazy Loading versehen wurde, als Hintergrundbild in den Styles verborgen ist oder erst nach der Ausführung eines Karussell-Skripts in die Seite eingefügt wird. Wichtige Bilder im sichtbaren Bereich sollte der Browser möglichst früh erkennen. Richten Sie bei Bedarf sinnvoll Preloading oder eine höhere Anforderungspriorität ein, weisen Sie aber nicht mehreren Karussellbildern gleichzeitig eine hohe Priorität zu.
Wird im sichtbaren Bereich ein Video verwendet, sollte außerdem geprüft werden, ob es sofort abgespielt werden muss. Ein geeignetes Vorschaubild, das zunächst den visuellen Inhalt übernimmt, und das verzögerte Herunterladen nicht notwendiger Videos lassen sich oft besser einsetzen, um die Belastung des sichtbaren Bereichs zu kontrollieren, als das Video für die automatische Wiedergabe weiter zu komprimieren.
Sieht der Netzwerk-Wasserfall nicht langsam aus, wird die Seite aber dennoch verzögert angezeigt, sollten Sie zur Performance-Zeitleiste wechseln. Die Ausführung großer Skripte, synchron geladene Stylesheets, das Warten auf Schriftarten sowie Inhalte, die erst nach einer Schnittstellenantwort generiert werden, können die Anzeige des sichtbaren Bereichs verzögern.
Live-Chat, Anzeigen-Tracking, Heatmaps und Social-Media-Komponenten sollten einzeln überprüft werden. In einer Testumgebung kann eine Drittanbieteranfrage vorübergehend blockiert und die Veränderung im sichtbaren Bereich verglichen werden. Nachdem der Einfluss bestätigt wurde, lässt sich der Auslösezeitpunkt anpassen. Entfernen Sie nicht einfach Marketing-Code und verschieben Sie auch nicht pauschal alle Skripte: Kontaktformulare, Navigation und Conversion-Tracking haben jeweils eigene Abhängigkeiten, die gemeinsam überprüft werden müssen.
Optimierungsaufgaben können danach sortiert werden, wie viele Besucher betroffen sind, welchen Anteil an der Wartezeit sie ausmachen und wie hoch das Änderungsrisiko ist. Ist eine wichtige Anzeigen-Landingpage beim ersten Besuch im Zielmarkt dauerhaft langsam, sollte sie Vorrang haben. Seiten, die nur gelegentlich von Mitarbeitern im Backend aufgerufen werden, können später behandelt werden. Bearbeiten Sie pro Durchgang zunächst den am eindeutigsten belegten Engpass, damit sich die Wirksamkeit der Änderung besser beurteilen lässt.
Liefert das Dokument beispielsweise schnell eine Antwort, beginnt der Download des großen Bildes im sichtbaren Bereich aber erst nach der Skriptausführung, sollte zuerst das Problem der verspäteten Bilderkennung behoben werden. Nimmt umgekehrt die Antwortzeit des Dokuments den größten Teil der Wartezeit ein, bringt eine weitere Feinabstimmung der Symbolgröße nur wenig. Für jede Aufgabe sollten Seite, Zugriffsbedingungen, betroffene Zeitphase und Abnahmemethode klar festgehalten werden, damit Wartungs-, Entwicklungs- und Marketingpersonal am selben Problem arbeiten können.
Testen Sie nach der Änderung erneut mit derselben Region, demselben Gerät und denselben Cache-Bedingungen. Prüfen Sie außerdem Menüs, Kontaktformulare, den Sprachwechsel und Conversion-Ereignisse von Anzeigen. Experimentelle Daten können zunächst die Richtung bestätigen; Kennzahlen realer Nutzer sollten erst nach dem Sammeln einer ausreichenden Zahl von Zugriffen ausgewertet werden. Halten Sie bei der Veröffentlichung die wichtigsten Zeiten, den Cache-Status und die Funktionsergebnisse vor und nach der Änderung fest. Melden Kunden weiterhin langsame Ladezeiten, setzen Sie die Fehlersuche bei dem Warteabschnitt fort, der noch nicht verkürzt wurde.
Verwandte Artikel
Verwandte Produkte


