Wie lässt sich die globale Zugriffsgeschwindigkeit einer Photovoltaik-Website für den Außenhandel überprüfen?

Am Montagmorgen öffnet ein Mitarbeiter aus dem Marketing die englischsprachige Website für Photovoltaikprodukte, um europäischen Kunden einen Link zu senden. Im Büronetz lädt die Seite nahezu sofort; der Kunde antwortet jedoch, dass die Produktparameterseite sehr lange geladen habe und auf dem Mobiltelefon sogar zeitweise leer geblieben sei. Solche Fälle sind nicht selten: Das Website-Team hält bei der Abnahme in China alles für in Ordnung, doch der Zugriff aus dem Ausland ist instabil. Erst wenn Anzeigen bereits geschaltet sind und Anfragen ausbleiben, wird deutlich, dass das Problem nicht nur darin besteht, dass „die Website etwas langsam ist“.

Für Photovoltaikunternehmen übernimmt die Website häufig Aufgaben wie den Download von Modulspezifikationen, das Anzeigen von Projektbeispielen, die Abfrage von Parametern für Wechselrichter oder Montagesysteme sowie das Absenden von Anfragen. Besucher können Dachinstallateure, Einkäufer oder EPC-Auftragnehmer sein und Produkte möglicherweise über ein Mobilfunknetz aufrufen. Wenn das Laden beim ersten sichtbaren Bereich hängen bleibt, PDFs nicht geöffnet werden oder das Absenden eines Formulars keine Rückmeldung liefert, brechen Nutzer den Besuch ab. Um die Frage „Wie lässt sich die globale Zugriffsgeschwindigkeit einer Außenhandelswebsite für Photovoltaik und neue Energien prüfen?“ zu beantworten, geht es nicht darum, einmal einen Score zu messen, sondern reale Regionen, reale Geräte und reale Zugriffspfade zu simulieren.

Zunächst unterscheiden: Messen Sie die Geschwindigkeit im Backend oder die Geschwindigkeit für ausländische Nutzer?

Viele öffnen eine Seite direkt im Website-Backend oder prüfen sie nur einmal im lokalen Browser und beurteilen die Website dann als leistungsfähig. Das zeigt lediglich, dass zwischen dem lokalen Standort und dem Server möglicherweise keine offensichtliche Blockierung besteht; es steht jedoch nicht für die Nutzererfahrung in Deutschland, den USA, dem Nahen Osten oder Südostasien. Die globale Zugriffsgeschwindigkeit wird gemeinsam durch den Standort des Besuchers, die DNS-Auflösung, Serverknoten, Netzwerkrouten, die Herkunft der Seitenressourcen und die Endgeräteleistung beeinflusst.

Vor dem Test sollten zunächst die Seiten aufgelistet werden, die tatsächlich geprüft werden müssen, statt nur die Startseite zu testen. In der Regel sollten mindestens folgende Seiten enthalten sein: die Startseite, eine Produktdetailseite, eine Projektbeispielseite mit großen Bildern oder Videos, eine Download-Seite sowie eine Anfrage- oder Kontaktseite. Falls die Website mehrsprachige Versionen hat, sollten auch die einzelnen Sprachseiten stichprobenartig geprüft werden, da Übersetzungs-Plugins, Schriftdateien, Weiterleitungsregeln und Code von Drittanbietern möglicherweise nicht identisch sind.

Auch „Erstbesuch“ und „erneuter Besuch“ sollten getrennt betrachtet werden. Beim ersten Öffnen verfügt der Browser über keinen Cache und muss Bilder, Skripte und Schriftarten anfordern; beim erneuten Öffnen kann die Seite durch den Cache deutlich schneller sein. Da Einkäufer häufig erstmals über eine Suche oder Anzeige auf die Seite gelangen, kommt dies dem ersten Fall am nächsten. Deshalb verdient die Ladezeit beim Erstbesuch besondere Aufmerksamkeit.

Tests nach Regionen einrichten, statt beliebig einen Knoten auszuwählen

Wählen Sie Teststandorte zunächst anhand Ihrer tatsächlichen Märkte aus. Wenn Sie hauptsächlich den deutschen, niederländischen und andere europäische Märkte bedienen, sollten Knoten in Westeuropa vorrangig geprüft werden. Bei vielen Kunden in Nordamerika sollten die Ost- und Westküste der USA getrennt betrachtet werden. Für den Nahen Osten, Südostasien oder Lateinamerika sollten ebenfalls die entsprechenden Regionen ausgewählt werden. Schließen Sie nicht aus einem guten Ergebnis in einer einzelnen Stadt darauf, dass die gesamte Region problemlos ist, denn die Unterschiede zwischen Netzbetreibern und Netzwerkrouten können erheblich sein.

Sie können Tools zur Prüfung der Webseitenleistung mit Knoten in mehreren Regionen verwenden. Geben Sie nach Eingabe der vollständigen URL für die Tests jeweils die Zielstadt sowie Desktop- und Mobilfunknetzbedingungen an. Jede wichtige Seite sollte am gleichen Knoten zwei- bis dreimal getestet werden: Das erste Ergebnis kann den Kaltstart widerspiegeln, während die folgenden Ergebnisse zeigen helfen, ob der Cache wirksam ist. Fällt ein Wert einmal ungewöhnlich hoch aus, sollten Sie nicht sofort ein Urteil fällen, sondern zunächst erneut testen und weitere Knoten einbeziehen.

Bei der Aufzeichnung sollte nicht nur auf die gesamte Ladezeit geachtet werden. Aussagekräftiger sind mehrere Signale während des Ladevorgangs:

• Ob die DNS-Auflösung und der Verbindungsaufbau zu lange dauern;
• ob der Server verzögert Inhalte zurückgibt oder das erste Byte schnell eintrifft;
• wann die wesentlichen Inhalte im sichtbaren Bereich erscheinen und ob Nutzer früh erkennen können, dass sie die richtige Seite aufgerufen haben;
• wann die wichtigsten Bilder, Produkttabellen und Anfrage-Buttons bedienbar werden;
• die Gesamtgröße der Ressourcen, die Anzahl der Anfragen und ob eine einzelne Datei die gesamte Seite verlangsamt.

Seitenbewertungen können Hinweise liefern, ersetzen jedoch weder ein Wasserfalldiagramm noch die tatsächliche Öffnungserfahrung. Beispielsweise kann der Score gut aussehen, während ein übergroßes Modulbild die Bandbreite im ersten sichtbaren Bereich belegt. Oder der Hauptinhalt der Seite wird bereits angezeigt, doch das Formularskript lädt weiterhin nicht, sodass beim Klicken keine Reaktion erfolgt. Solche Fälle müssen anhand der Reihenfolge der Ressourcenanfragen überprüft werden.

Bei langsamer Ladezeit nicht vorschnell nur Bilder komprimieren

Bilder sind tatsächlich eine häufige Belastung für Photovoltaik-Websites. Reale Aufnahmen von Solarkraftwerken, Moduldetaillierungen und Fabrikszenen haben oft eine sehr hohe Auflösung. Werden die Originalbilder direkt hochgeladen, werden Produktseiten im Mobilfunknetz schwerfällig. Doch große Bilder sind nicht unbedingt die einzige Ursache. Sicherer ist es, die Prüfung dort zu beginnen, wo die Verzögerung auftritt.

Wenn in mehreren ausländischen Regionen lange Wartezeiten vor oder während des Verbindungsaufbaus auftreten, sollten die DNS-Konfiguration, der Serverstandort, die korrekte Aktivierung des CDN sowie mögliche ungewöhnliche Weiterleitungen beim HTTPS-Handshake geprüft werden. Ist nur eine einzelne Region deutlich langsam, muss bestätigt werden, ob das CDN diese Region abdeckt und ob statische Ressourcen tatsächlich von Edge-Knoten zurückgegeben werden, statt weiterhin von einem einzelnen Ursprungsserver geladen zu werden.

Bei einer langsamen Serverantwort kann die Ursache in dynamischen Programmen, Datenbankabfragen, der Art der Seitenerstellung oder einem nicht greifenden Cache liegen. In diesem Fall behebt die alleinige Optimierung von Bildern häufig nur die Symptome. Technische Mitarbeiter können Seiten-Cache, API-Anfragen, Weiterleitungsketten und Fehlerprotokolle prüfen, insbesondere dynamische Bereiche wie Produktfilter, die interne Suche und Anfrageformulare.

Wenn der erste sichtbare Bereich lange nicht erscheint, sind häufig zu viele gleichzeitig geladene Slider-Bilder, automatisch startende Videos, die Darstellung blockierende externe Schriftarten oder eine große Menge an Skripten am Seitenanfang die Ursache. Die Startseite muss nicht für eine „vollständige visuelle Darstellung“ gleichzeitig alle Slider-Inhalte laden. Bilder außerhalb des ersten sichtbaren Bereichs können verzögert geladen, Videos durch ein Vorschaubild mit Wiedergabe per Klick ersetzt und nicht erforderliche Skripte später ausgeführt werden.

Wenn die Seite bereits angezeigt wird, die Bedienung jedoch ruckelt, sollten Chat-Plugins, Tracking-Code, Karten, Social-Media-Komponenten und Werbe-Tracking-Tags geprüft werden. Sie stammen üblicherweise von verschiedenen Drittanbieter-Domains; reagiert ein Dienst langsam, kann er die Seiteninteraktion beeinträchtigen. Die Lösung besteht nicht darin, alles pauschal zu entfernen, sondern Code mit eindeutigem geschäftlichem Nutzen beizubehalten und zu prüfen, ob er mehrfach installiert ist, asynchron geladen werden kann oder nur auf den erforderlichen Seiten aufgerufen werden sollte.

„Kann geöffnet werden“ in einen nachvollziehbaren Abnahmeprozess überführen

Nach der Optimierung sollten die Tests unter denselben regionalen, seitenbezogenen und netzwerkseitigen Bedingungen wie bei der Erstmessung wiederholt werden, damit Ergebnisse nicht durch einen Wechsel von Tool oder Knoten unvergleichbar werden. Empfehlenswert ist eine einfache Protokolltabelle mit Testdatum, Land oder Stadt, Seitenadresse, Geräte- und Netzwerkumgebung, Zustand des ersten sichtbaren Bereichs, Interaktionsfähigkeit, auffälligen Ressourcen und Bearbeitungsvermerken. So kann das Team bei einem späteren Theme-Wechsel, dem Hinzufügen von Videos, der Einbindung von Marketingtools oder der Aktualisierung von Produktunterlagen schnell erkennen, woher Leistungsänderungen stammen.

Neben automatisierten Prüfungen sollten auch manuelle Stichproben durchgeführt werden. Öffnen Sie Seiten über ein ausländisches Proxy-Netzwerk oder mit Unterstützung lokaler Kollegen bzw. Partner in gängigen Browsern und auf Mobiltelefonen. Prüfen Sie insbesondere, ob die Sprachweiterleitung korrekt funktioniert, Produktbilder fehlen, Download-Links verfügbar sind und das Absenden von Formularen eine klare Rückmeldung liefert. Ein „abgeschlossen“ im Leistungsbericht bedeutet nicht zwangsläufig, dass geschäftliche Nutzeraktionen reibungslos funktionieren.

Bei Landingpages für Anzeigen sollte der Test dem tatsächlichen Einstiegsszenario stärker entsprechen: Öffnen Sie sie in einem Inkognito-Fenster, ohne Cache-Einfluss, und rufen Sie einen direkten Deep Link auf, statt sich von der Startseite Ebene für Ebene durchzuklicken. Denn Anzeigenbesucher können beim ersten Besuch direkt auf einer Seite für ein bestimmtes Modulmodell landen. Lädt diese Seite langsam, kann selbst eine gute Leistung der Startseite dies nicht ausgleichen.

In welchen Fällen sollten technische Fachkräfte weiter tätig werden?

Bei folgenden Erscheinungen lassen sich Probleme allein durch die Inhaltsbearbeitung normalerweise nur schwer lösen: Verschiedene Seiten melden häufig Fehler oder lassen sich zeitweise nicht öffnen; eine bestimmte Region kann langfristig nicht stabil zugreifen; die Serverantwort wird zu Spitzenzeiten deutlich langsamer; auch nach der Ressourcenkomprimierung bestehen weiterhin zahlreiche Blockierungen; Formulare, Downloads oder Sprachwechsel beeinträchtigen den normalen Geschäftsablauf. In diesem Fall sollten Testlinks, Zeitpunkte, regionale Knoten, Screenshots von Wasserfalldiagrammen und Schritte zur Reproduktion bereitgestellt werden, damit Entwicklungs- oder Betriebsteams das Problem lokalisieren können, anstatt nur zu beschreiben, dass „die Seite im Ausland langsam geöffnet wird“.

Die globale Zugriffsgeschwindigkeit ist nicht mit einem einzigen Test vor dem Launch erledigt. Photovoltaik-Websites werden fortlaufend um neue Produktseiten, Zertifikatsunterlagen, Projektbilder und Werbecode ergänzt, und jede Änderung kann den Ladepfad verändern. Nur wenn die Geschwindigkeitsprüfung in den wichtigsten Märkten als fester Schritt vor und nach jeder Veröffentlichung integriert wird, lassen sich Probleme früher erkennen und interessierte ausländische Besucher davon abhalten, auf einer wartenden Seite stehen zu bleiben.