Was sollte nach einer Website-Analyse bei langsamen Ladezeiten zuerst geprüft werden?

Was sollte nach der Feststellung einer langsamen Ladezeit bei einer Website zuerst geprüft werden?

Wenn eine Website-Prüfung langsame Ladezeiten feststellt, reagieren viele Verantwortliche zunächst mit „Server wechseln“ oder „die Seite komplett neu gestalten“. Beides kann wirksam sein, ist jedoch oft nicht der erste notwendige Schritt. Insbesondere bei unabhängigen Websites für Kunden im Ausland bedeutet ein langsamer Zugriff nicht zwangsläufig, dass die Serverkonfiguration unzureichend ist. Ursache können auch die Region des Besuchers, Bilder im sichtbaren Bereich, Marketing-Tracking-Skripte oder sogar ein eingebettetes Formular sein. Wer ohne vorherige Lokalisierung des Engpasses direkt einen Relaunch vornimmt, investiert häufig viel, während sich die Geschwindigkeit nur geringfügig verbessert.

Eine wertvolle Website-Prüfung sollte sich nicht nur auf einen bestimmten „Score“ konzentrieren, sondern einige praktische Fragen beantworten: Reagiert der Server nur sehr langsam, oder rendert der Browser den Inhalt nach dem Empfang zu langsam? Sind alle Seiten langsam oder nur Anzeigen-Landingpages, Produktdetailseiten und mehrsprachige Seiten? Ist die Website in China langsam oder in Zielmärkten wie Nordamerika und Europa? Erst wenn diese Fragen klar getrennt werden, geraten die anschließenden Maßnahmen nicht in die falsche Richtung.

Zunächst klären: Ist die Serverantwort oder der Seitendownload langsam?

In Website-Prüfberichten finden sich häufig Kennzahlen wie Time to First Byte, Serverantwortzeit und Ladezeit der Seitenressourcen. Der häufigste Fehler in der Praxis besteht darin, jede Form von „Langsamkeit“ dem Hosting zuzuschreiben. Liefert der Server die HTML-Datei zwar schnell zurück, werden Bilder, Schriften, Videos und Skripte der Seite jedoch weiterhin geladen, sieht der Nutzer dennoch eine leere, springende oder lange nicht anklickbare Seite.

Zur Gegenprüfung können zunächst das Netzwerk-Panel der Browser-Entwicklertools oder Geschwindigkeitstests aus verschiedenen Regionen genutzt werden. Wartet die Dokumentanfrage selbst sehr lange, sollten zuerst der Standort des Hostings, die Serverauslastung, Datenbankabfragen, Cache-Trefferraten sowie möglicherweise zu lange Weiterleitungsketten geprüft werden. Beispielsweise wird nach dem Aufruf einer http-Adresse zu https weitergeleitet, dann zu einer Version mit oder ohne www und anschließend in ein Sprachverzeichnis. Bei einem einzigen Aufruf entstehen so mehrere zusätzliche Roundtrips.

Bei Websites exportorientierter Unternehmen sollte der Serverstandort insbesondere nicht allein nach dem „Preis“ ausgewählt werden. Befinden sich die wichtigsten Kunden in Europa, während sämtliche Ressourcen auf Knoten weit entfernt von den Nutzern liegen oder kein angemessenes Content Delivery Network eingerichtet ist, treten bei der Übertragung von Bildern und Skripten meist deutlichere Verzögerungen auf. Blindes Komprimieren des Codes bringt dann nur begrenzten Nutzen; zunächst sollte geprüft werden, ob der grundlegende Netzwerkpfad geeignet ist.

Bilder im sichtbaren Bereich bremsen die Geschwindigkeit oft stärker als erwartet

Bei marketingorientierten Websites besteht häufig ein Konflikt: Das Design wünscht sich im sichtbaren Bereich große Fabrikbilder, Produktvideos oder Slider, während das Kampagnenteam möchte, dass die wichtigsten Verkaufsargumente und der Anfragezugang möglichst schnell erscheinen. Das Nutzererlebnis wird in der Regel nicht dadurch beeinträchtigt, dass überhaupt Bilder verwendet werden, sondern dadurch, dass Bilder unnötig groß sind, zu viele auf einmal geladen werden oder wichtige Inhalte vollständig hinter visuellen Materialien verborgen liegen.

Bei der Prüfung sollte zunächst kontrolliert werden, ob die tatsächliche Anzeigegröße des größten Bildes im sichtbaren Bereich annähernd der Größe des Originalbildes entspricht. Wird ein Bild, das nur in einem Bannerbereich angezeigt wird, weiterhin direkt als übergroßes Original ausgegeben, verlangsamt dies die Seite in Mobilfunknetzen leicht. Auch bei Produktbildern muss nach Verwendungszweck unterschieden werden: Das Hauptbild im sichtbaren Bereich sollte vorrangig klar und in einer kontrollierbaren Dateigröße sein; hochauflösende Bilder auf Detailseiten können bei Bedarf geladen werden; Bilder außerhalb des sichtbaren Bereichs sollten per Lazy Loading geladen werden. Besonders Slider sollten geprüft werden: Während Nutzer nur das erste Bild sehen, könnten im Hintergrund bereits vier oder fünf große Bilder heruntergeladen worden sein.

Videohintergründe sind eine weitere häufige Problemquelle. Sie wirken eindrucksvoll, sind jedoch für Besucher mit durchschnittlicher Netzverbindung nicht besonders nutzerfreundlich. Ist ein Video nicht unbedingt erforderlich, um den Produktionsprozess oder die Verwendung des Produkts zu erklären, ist ein optimiertes Titelbild die bessere Wahl; das Video sollte erst abgespielt werden, nachdem der Nutzer es aktiv anklickt. Auf B2B-Anfrageseiten müssen Einkäufer zuerst die Produktkompetenz, den Lieferumfang und die Kontaktmöglichkeit sehen, statt darauf zu warten, dass ein automatisch abgespieltes Video vollständig gepuffert ist.

Anschließend den Codeumfang prüfen: Nicht möglichst wenige Plugins, sondern möglichst wenig unnötiges Laden

Eine weitere wesentliche Ursache für langsame Seitenladezeiten sind zu viele Stylesheet- und Skriptdateien. Beim Aufbau einer Website bringen ein neues Pop-up, Formular, Sprachumschalter oder Animationsmodul häufig zusätzliche Ressourcen mit sich. Das Problem liegt nicht in der Anzahl der Funktionen selbst, sondern darin, ob diese Ressourcen auf jeder Seite und von jedem Besucher heruntergeladen werden müssen.

Eine praktische Prüfmethode besteht darin, eine langsame Seite zu öffnen und die Ressourcen nach Dateigröße und Ladezeit zu sortieren. Werden bestimmte Skripte nur für ein Aktions-Pop-up auf der Startseite verwendet, aber ebenso auf Produktdetailseiten, Artikelseiten und Datenschutzseiten geladen, sollte eine Aufteilung nach Seiten erwogen werden. Bei Websites mit vielen älteren Templates und Plugins ist es nicht empfehlenswert, den gesamten Code auf einmal zu löschen oder zu ändern. Werden zunächst in einer Testumgebung die größten nicht erforderlichen Ressourcen bearbeitet und anschließend Formulare, Sprachversionen, Warenkorb und Tracking seitenweise geprüft, ist das Risiko deutlich geringer.

Auch Schriftdateien verdienen Aufmerksamkeit. Auslandswebsites laden häufig verschiedene Schriftstärken und Zeichensätze, um ein einheitliches Markenbild zu gewährleisten. Die Anforderungen an Schriften unterscheiden sich jedoch je nach Sprachversion, etwa für Chinesisch, Japanisch, Russisch oder Arabisch. Ohne sprachspezifische Anpassung kann eine Seite Schriftressourcen herunterladen, die der Nutzer überhaupt nicht benötigt. Bei der Performance-Optimierung mehrsprachiger Websites kann nicht nur dieselbe Seitenstruktur kopiert werden; auch die Ressourcenstrategie muss an die Zielsprache angepasst werden.

Drittanbieter-Skripte sind ein verstecktes Performance-Risiko

Anzeigen-Pixel, Online-Kundendienst, Karten, Social-Media-Feeds, Bewertungswerkzeuge und Buchungssysteme sind häufig verwendete Drittanbieterdienste im Website-Marketing. Sie unterstützen Attribution und Conversion, doch jede zusätzliche Funktion schafft eine weitere externe Abhängigkeit. Reagiert ein Drittanbieterdienst instabil, kann die Website ausgebremst werden, selbst wenn ihr eigener Server schnell ist.

Dieser Bereich sollte nicht einfach pauschal „abgeschaltet“ werden. Auf Anzeigen-Landingpages muss das erforderliche Conversion-Tracking in der Regel erhalten bleiben, da Optimierungsteams sonst nicht feststellen können, woher Anfragen stammen. Langfristig ungenutzte Chat-Tools, doppelt eingebundene Statistikcodes oder Komponenten, die vollständige Social-Media-Inhalte laden, sollten jedoch bereinigt werden. Ein häufiges Problem ist, dass eine Website mehrfach überarbeitet oder der Dienstleister gewechselt wurde, ohne den alten Code zu entfernen. Dadurch werden Ereignisse derselben Art mehrfach gesendet, was nicht nur die Geschwindigkeit beeinträchtigt, sondern auch die Datenauswertung stört.

Wenn ein Team gleichzeitig die Unternehmenswebsite, den Onlineshop und Anzeigen-Landingpages betreut, empfiehlt sich eine Skriptliste mit folgenden Angaben: Zweck des Codes, eingebundene Seiten, Verantwortlicher, Einfluss auf zentrale Conversions und aktuelle Nutzung. Sie ist nicht kompliziert, kann jedoch verhindern, dass später „niemand etwas zu löschen wagt“. Bei Seiten mit komplexen Geschäftsinhalten oder Branchenmaterialien sollte ebenso wie bei der Prüfung von Fachinhalten wie Finanzielle Risiken bei Fusionen und Übernahmen staatseigener Unternehmen sowie Gegenmaßnahmen bestätigt werden, ob externe Komponenten, Download-Dateien und eingebettete Ressourcen den Lesern tatsächlich dienen und nicht lediglich Altlasten sind.

Nicht nur die Startseite testen, sondern entlang realer Besuchspfade prüfen

Die Startseite wird in der Regel stärker optimiert, doch Kunden gelangen nicht unbedingt über sie auf die Website. Nutzer der organischen Google-Suche öffnen möglicherweise direkt eine Produktdetailseite; Anzeigenbesucher gelangen auf eine Landingpage mit Formular; Social-Media-Nutzer sehen vielleicht zuerst einen Artikel oder eine Aktionsseite. Eine Website-Prüfung sollte daher mindestens die Startseite, zentrale Produktseiten, wesentliche Anfrageseiten, Inhaltsseiten und mobile Seiten abdecken. Bei mehrsprachigen Versionen sollten auch verschiedene Sprachverzeichnisse stichprobenartig geprüft werden. Ergebnisse der chinesischen Website können nicht stellvertretend für die englische Website oder Seiten in anderen Sprachen verwendet werden.

Bei der Priorisierung empfiehlt es sich, „langsame Seiten“ zusammen mit ihrem „Geschäftswert“ zu betrachten. Eine alte Nachrichtenseite mit sehr wenig Traffic muss nicht vorrangig bearbeitet werden, selbst wenn ihr Score niedrig ist. Seiten hingegen, die Werbebudgets aufnehmen, gut ranken oder die meisten Anfragen generieren, sollten bei Ladeproblemen zuerst optimiert werden. Bei der Geschwindigkeitsoptimierung geht es nicht darum, in Testtools die Höchstpunktzahl zu erreichen, sondern darum, dass Zielkunden wichtige Informationen schneller sehen und den nächsten Schritt ausführen können.

Nach der Behebung unbedingt erneut testen – die Geschwindigkeitsoptimierung darf die Conversion nicht beeinträchtigen

Nach der Bildkomprimierung, Ressourcenbündelung und Verzögerung von Skripten sollten die Seitendarstellung, Formularübermittlungen, Telefon- oder E-Mail-Schaltflächen, der Warenkorbprozess sowie Anzeigen-Conversion-Ereignisse erneut geprüft werden. Besonders auf Mobilgeräten können bestimmte „Optimierungen“ zu falsch positionierten Bildern, nicht öffnenden Menüs oder ungültigen Captchas führen. Die Geschwindigkeit steigt oberflächlich, während die tatsächlichen Anfragen zurückgehen. Nach dem Wirksamwerden des Caches sollten Tests zudem im Inkognito-Modus und über Netzwerke aus verschiedenen Regionen wiederholt werden, damit nicht nur schnelle Ergebnisse aus dem lokalen Cache sichtbar sind.

Bei einem Dienstleistungssystem wie 易营宝, das intelligentes Website-Design, grenzüberschreitende Onlineshops, SEO, Anzeigenplatzierung und Social-Media-Betrieb abdeckt, eignet sich bei der Bearbeitung der Website-Performance eher ein Ansatz, bei dem „technische Probleme und Marketingpfade gemeinsam betrachtet werden“: Welchen Traffic trägt die Seite, welches Tracking muss erhalten bleiben und wo befindet sich der Zielmarkt? Erst dann wird entschieden, wie Ressourcen und Architektur angepasst werden. Für Verantwortliche ist vor allem eines wichtig: Zuerst die langsamsten Anfragen und die wichtigsten Seiten ermitteln, dann Maßnahmen ergreifen. Das ist stabiler als sofort den Server zu wechseln oder einen umfangreichen Relaunch vorzunehmen und führt leichter zu tatsächlichen Verbesserungen.