Ladezeiten-Abweichungen beim Web Performance Monitoring: Ursachen und Lösungen

Wenn du dir die Performance von Website, Webservice oder API über einen Zeitraum ansiehst, wirst du in der vom Prüfobjekt berichteten Performance Schwankungen feststellen. Du stellst eventuell auch Unstimmigkeiten zwischen den von unterschiedlichen Prüfobjekten berichteten Performance-Daten fest. Warum? Worin liegt der Grund, dass du Spitzen in deinen Diagrammen siehst? Gibt es Probleme, die es zu lösen gilt? Vielleicht. Manchmal sind diese Performance-Spitzen oder Schwankungen normal und manchmal kannst du sie im Rahmen deiner Prüfobjekt-Einstellungen behandeln.

In diesem Blog-Beitrag sehen wir uns einige Ursachen an, die zu Schwankungen der Performance bei Website oder Service führen, die vom Monitoring gemeldet werden. Wir sprechen über die Schritte, die du unternehmen kannst, um beständigere Ergebnisse zu erhalten und zu verstehen, warum die Schwankungen auftauchen.

Latenz aufgrund der Checkpoint-Auswahl außerhalb deines Servicegebiets

Du weißt natürlich, dass die Ladezeiten steigen, je weiter du von der Quelle entfernt bist. Latenzprobleme zu erkennen und sie zu beheben, ist einer der Gründe, weshalb du die Performance deiner Website überwachst. Als Erstes solltest du dir den Teststandort ansehen, wenn du eine Spitze in der Performance siehst.

Uptrends verfügt über 200 globale Checkpoints, sodass du so nahe wie möglich an den Standorten deiner tatsächlichen Nutzer testen kannst. Wenn du deine Monitoring-Standorte nicht an die von dir bedienten geografischen Standorte ausgerichtet hast, wirst du höchstwahrscheinlich Performance-Probleme bei Checkpoints außerhalb deines Servicegebiets sehen.

Wenn du gemäß deinem Uptrends-Plan keine einzelnen Checkpoints auswählen kannst, kannst du immer noch Checkpoints außerhalb deines Servicegebiets ausschließen, die die Ergebnisse aus deinen Berichten verschlechtern. Klicke innerhalb deines Dashboards den Punkt Checkpoints im Schnellmenü und wähle nur die von dir gewünschten Checkpoints.

Unterschiede in der Internet-Infrastruktur

Deine Nutzer und unsere Checkpoints existieren innerhalb einer Internet-Infrastruktur auf Basis ihres Standorts. Obwohl unsere Checkpoints in Datenzentren hoher Qualität eingerichtet sind, wird die Ladezeit direkt durch die Qualität der umgebenden Architektur beeinflusst, sobald eine Anfrage den Checkpoint verlässt. Du wirst langsamere Zeiten in langsameren lokalen Infrastrukturen bemerken. Beispielsweise können deine Testergebnisse aus der Türkei, einem Staat mit durchschnittlicher Download-Geschwindigkeit von 4,9 Mbit/s, sich erheblich von Testergebnissen aus Singapur, einem Staat mit durchschnittlicher Geschwindigkeit von 60,39 Mbit/s, unterscheiden.

Fluktuationen im Netzwerk-Traffic

Wie Latenz sind Spitzen bei der Serverlast etwas, das du bei deiner Website überwachen solltest. Wenn du erhebliche Verzögerungen zu Spitzenzeiten bemerkst, ist es Zeit, deiner Website Schwung zu geben oder ein CDN einzusetzen, um sie zu entlasten. Wenn du bereits weißt, dass du die Bandbreite und Funktionalität besitzt, um rund um die Uhr eine leistungsstarke Website zu bieten, sind es eventuell externe Probleme wie die lokale Infrastruktur, die die Performance beeinträchtigen können.

Geografisch gezielter Inhalt wirkt sich auf die Performance aus

Zeigt deine Website unterschiedliche Inhalte auf Grundlage des Ortes. Dann erzeugen Änderungen am Inhalt Änderungen an der Performance. Wenn dein Unternehmen Geo-Targeting nutzt, solltest du vielleicht deine Berichte anhand der Checkpoint-Optionen im Schnellmenü filtern, benutzerdefinierte Dashboards für jede Region erstellen oder unterschiedliche Prüfobjekte einrichten.

Screenshot: Nutze die Checkpoint-Auswahl, um Berichte für bestimmte Standorte oder Regionen anzupassen.

Pop-ups, Chatbots, Analysen und Umfragen

Viele Websites und Webseiten beinhalten Pop-up-Fenster für Werbung, Abonnement-Bedingungen, Benutzerumfragen und Chatbots. Üblicherweise werden diese Pop-ups bei den meisten Websites verzögert angezeigt. Je nach Verzögerungszeit können die Pop-ups in den Performance-Ergebnissen beim Real Browser Monitoring und Full Page Check auftauchen und spiegeln die Verzögerungszeit wider. Wenn die Verzögerung nicht einheitlich ist, wirst du Schwankungen in der Performance sehen. Damit diese Pop-ups und im Hintergrund laufende Skripte sich nicht auf die Ergebnisse auswirken, kannst du unser Blockieren von URLs Google Analytics einsetzen.

Wenn du Google Analytics oder Uptrends RUM nutzt, kannst du sie einfach in den Prüfobjekt-Einstellungen auf dem Tab Erweitert über die Kontrollkästchen blockieren.

Andere URLs kannst du über das Feld URL/Bestandteile blockieren aufnehmen. Sie werden immer noch im Wasserfallbericht erscheinen, aber durchgestrichen sein, um anzuzeigen, dass das Prüfobjekt sie nicht angefragt hat.

Screenshot: Wasserfallbericht mit blockierten Analytics-URLs

Wissen, welche Performance-Metrik zugrunde liegt

Unsere Prüfobjekte messen Performance auf sehr unterschiedliche Weise, je nach Prüfobjekttyp und was überwacht werden soll. Wir empfehlen den Full Page Check für das Website Performance Monitoring, Transaktions-Monitoring für deine Webanwendungen und Multi-step API Monitoring für deine Webservices oder APIs. Alle drei liefern Performance-Metriken.

Full Page Check
Uptrends bietet den Full Page Check für das Website Performance Monitoring. Das Prüfobjekt verwendet einen echten Browser, um den gesamten Inhalt deiner Seite abzurufen und zu laden. Während der Browser den Inhalt abfragt, lädt und darstellt, verfolgt das Prüfobjekt wichtige Werte zu jedem Element (sogar Elemente von Dritten). Du kannst den Verlauf dem Wasserfalldiagramm des Prüfobjekts entnehmen. Du erhältst auch Durchschnittszahlen für die gesamte Seite und eine Auflistung der Inhaltstypen sowie die zusammengefassten Ladezeiten.

Transaktions-Monitoring
Transaktionsprüfobjekte liefern dir Performance-Daten für jeden Schritt. Ein Transaktionsprüfobjekt gibt dir zudem Performance-Daten für die ursprüngliche Seitenladezeit und jede weitere Ladezeit oder jeden Schritt der Transaktion. Optional kannst du für jeden Schritt Wasserfallberichte erhalten.

Multi-step API
Das Multi-step API Monitoring zeigt dir die Performance auf Grundlage der Antwortzeit zu jedem Serveraufruf, ähnlich wie das Transaktions-Monitoring. Du erhältst die Gesamtzeit für den Test (sowie alle Wartezeiten, die du für das Prüfobjekt eingesetzt hast). Bei jedem Bericht siehst du die für jeden Schritt benötigte Zeit und du kannst für diese Zeiten Prüfpunkte festlegen, um eine Warnmeldung zu erhalten, wenn ein API-Aufruf länger als erwartet dauert.

Andere Monitoringtypen
Unsere anderen Prüfobjekte (HTTP, HTTPS, DNS, E-Mail, Datenbanken und externes Server-Monitoring) stellen ebenfalls Performance-Daten aufgrund erster Antwortzeiten bereit. Beispielsweise zeigt dir das HTTPS-Prüfobjekt nur die Antwortzeit für die erste Anfrage. Das Prüfobjekt lädt die Antwort nicht in einen Browser und erfasst daher nie die anderen Seitenelemente. Ein DNS-Monitoring bietet dir nur Informationen zur Auflösungszeit und ein externes Server-Monitoring sagt dir die Dauer des Verbindungsaufbaus mit dem Server. Wenn du also Ergebnisse der Prüfobjekttypen vergleichst, bedenke, dass sie nicht über dasselbe Ereignis berichten.

Individuelle Monitoring-Einstellungen wirken sich auf Performance-Berichte aus

Deine Prüfobjekt-Einstellungen können ebenfalls die Ladezeiten beeinflussen. Berücksichtige also deine Prüfobjekt-Einstellungen, wenn du die Performance bei mehreren Prüfobjekten derselben Art vergleichst: Kleine Unterschiede bei den Einstellungen können zu unterschiedlichen Ergebnissen führen.

IPv4- und IPv6-Einstellungen
Wenn du sowohl die IPv4- als auch die IPv6-Version deiner Website oder deines Service beibehältst und du Unterschiede in der Performance zwischen verschiedenen Prüfobjekten desselben Typs bemerkst, sieh nach, welche Version des Protokolls verwendet wird, um sicherzustellen, dass sie dieselbe Version der Website testen. IPv6- und IPv4-Anfragen haben sehr unterschiedliche Routing-Pfade, die Performance-Ergebnisse beeinflussen. Bei Uptrends hast du auch die Option, nur die Checkpoints zu nutzen, die nativ IPv6 unterstützen oder bei Checkpoints emulieren, die nur IPv4 unterstützen.

Das folgende Diagramm zeigt den Unterschied zwischen den zwei Versionen beim Aufruf von https://www.google.com mit IPv4 und IPv6.

Diagramm: Der Performance-Unterschied zwischen IPv4 und IPv6

Browser-Typ und Geräteeinstellungen

Prüfobjekte von Uptrends ermöglichen die Änderung des User Agents und bei unseren Prüfobjekten, die echte Browser verwenden, kannst du zwischen Firefox, IE, Chrome und Phantom JS wählen. Deine Wahl des Browsers und User Agents beeinflusst deine Performance Monitoring-Ergebnisse. In dem folgenden Diagramm siehst du, wie die unterschiedlichen Browser beim Testen der Uptrends Homepage abschnitten.

Diagramm: Unterschiedliche Browser zeigen unterschiedliche Performance-Ergebnisse nach Aufruf desselben Inhalts

Bandbreiten-Drosselung

Mit der Bandbreiten-Drosselung kannst du deine Website für geringere Verbindungsgeschwindigkeiten testen. Uptrends bietet zwei Arten der Bandbreiten-Drosselung: Browser und simuliert. Browser-basierte Drosselung nutzt die Chrome-Browser-Drosselung und bei der simulierten Drosselung verwaltet Uptrends die Drosselung (verfügbar für alle Browser-Möglichkeiten). Wenn du die Performance von mehreren Prüfobjekten vergleichst, achte darauf, ob die Prüfobjekte Bandbreiten-Drosselung verwenden. Wenn das so ist, verwende die gleiche Drosselung und Art.

Das falsche Protokoll

Der Wechsel nach HTTPS wird seit einiger Zeit vollzogen und die erfahrenen Uptrends-Nutzer müssen eventuell die Prüfobjekte aktualisieren. Wenn du ein Prüfobjekt einrichtest, gibst du eine URL ein. Wenn deine Website von HTTP nach HTTPS gewechselt hat und du deine Prüfobjekte nicht mit der neuen URL aktualisiert hast, werden deine Prüfobjekte einen Performance-Rückgang verzeichnen, da die Anfrage eine zusätzliche Weiterleitung zum korrekten Protokoll und Port verarbeitet.

Zur Illustration, wie das richtige Protokoll und Prüfobjekttyp sich auf die Performance-Ergebnisse auswirkt, haben wir drei Prüfobjekte eingerichtet:

  • HTTP-Prüfobjekt nutzt HTTP-Protokoll, um eine HTTPS-Website aufzurufen
  • HTTPS-Prüfobjekt nutzt HTTP-Protokoll, um eine HTTPS-Website aufzurufen
  • HTTPS-Prüfobjekt nutzt HTTPS-Protokoll, um eine HTTPS-Website aufzurufen

In dem folgenden Diagramm siehst du die Auswirkung der Weiterleitungen von HTTP nach HTTPS. Überprüfe bei der Untersuchung der Performance-Abweichungen, dass das Prüfobjekt das richtige Protokoll nutzt und dass die URL der Website korrekt ist.

Diagramm: Das falsche Protokoll kann zusätzliche Ladezeit in deinen Prüfobjekt-Ergebnissen zeigen.

Fehlendes „www“

Deine URL kann das Prefix „www“ vor dem Domainnamen haben oder eben nicht. Viele Unternehmen haben sich entschieden, das Prefix für einen kürzeren Domainnamen wegzulassen. So oder so, hoffentlich hast du die andere zum korrekten Domainnamen weitergeleitet. Wenn du das Monitoring einrichtest, solltest du sicherstellen, dass du auch das richtige Format nutzt. Um zu zeigen, was wir meinen, haben wir zwei HTTPS-Prüfobjekte eingerichtet, um unsere Homepage zu testen. Das eine Prüfobjekt enthält das Prefix, das andere nicht. Bei unseren Tests verdoppelte die Weiterleitung zur korrekten Version die Gesamt-Antwortzeit (siehe Diagramm unten).

Diagramm: Verwende das korrekte Prefix bei deinem Prüfobjekt, um eine Performance-Verschlechterung aufgrund von Weiterleitungen an das richtige Prefix zu vermeiden.

Fazit

Einiges von dem oben gesagten klingt nach gesundem Menschenverstand, aber bei der Lösung von Performance-Abweichungen stellst du möglicherweise fest, dass du einige Ursachen übersehen hast. Wenn du also Probleme feststellst, überprüfe das Folgende:

  1. Wurde der Checkpoint in deinem Service-Gebiet genutzt?
  2. Verfügt das Land oder die Region, in der du testest, über eine schnelle Verbindung?
  3. Besteht das Problem aufgrund größeren Traffics auf deiner Website?
  4. Wenn du Geo-Targeting nutzt, gibt es für das Land oder die Region unterschiedliche Inhalte?
  5. Beeinflussen Chatbots, Pop-up-Werbung oder Nutzerumfragen deine Performance-Ergebnisse?
  6. Vergleichst du Ergebnisse von unterschiedlichen Prüfobjekttypen? Messen sie dasselbe Ereignis?
  7. Verursacht die IP-Version eine Abweichung der Ergebnisse?
  8. Verwenden die Prüfobjekte dieselben Browser, Drosselungen, User Agents und Checkpoints?
  9. Ist die URL und Prüfobjekt-Auswahl korrekt? D. h., beeinträchtigen Weiterleitungen deine Ergebnisse?


Wenn du dann das Problem immer noch nicht lösen kannst, stehen unsere Support-Helden bereit. Reiche einfach ein Support-Ticket ein. Du findest vielleicht auch Antworten in unserer Knowledge Base.

Leave a Reply

Your email address will not be published. Required fields are marked *