Als ein Website- oder ein Webservice-Dienstanbieter hängt alles von deinen KPIs (Key Performance Indicators) ab. Hier bestimmen wir diese KPIs und unterstützen dich bei der Entscheidung, welche Tools du benötigst, um die für dich wichtigen KPIs zu überwachen und zu tracken.
Die für dein Unternehmen wichtigen KPIs sind häufig mit der Abteilung verknüpft, in der du arbeitest. Für DevOps sind Performance- und Verfügbarkeits-KPIs wichtig, Marketing achtet mehr auf die Akquisitions-, Verlust- und Konversionsraten und das Team für User Experience (UX) bzw. Kundenzufriedenheit sorgt sich mehr um Funktionalität und Benutzerfreundlichkeit. Obwohl all die verschiedenen Werte wichtig sind, sollten sich alle Teams zunächst für die Performance- und Verfügbarkeits-KPIs interessieren, denn diese wirken sich auf jeden Aspekt einer Website oder eines Service aus.
Warum sind Performance- und Verfügbarkeits-KPIs wichtig?
Eine schlechte Performance oder häufige oder lange Ausfälle unterminieren die Wahrnehmung und das Vertrauen der Nutzer. Studien haben gezeigt, dass eine Verzögerung von einer halben Sekunde die Meinung des Nutzers über eine Website verschlechtert und sogar seine Ansichten über die ästhetischen Aspekte einer Seite beeinflusst.
Website-Probleme wie langsam ladende Seiten, nicht funktionierende Webanwendungen und Ausfälle sind über das akute Problem hinaus bedenklich. Websites mit Problemen verzeichnen auch schlechtere Suchmaschinen-Positionen, höhere Absprungraten, höhere Raten bei Einkaufsabbrüchen, verringerte Nutzerbindung und geringere Nutzerzufriedenheit. Wenn du also ein SaaS-Anbieter bist, eine E-Commerce-Website oder Content Marketing Website betreibst, gilt: Du musst deine KPIs verfolgen und kennen.
Uptime-/Verfügbarkeits-KPIs
Die ersten zu beachtenden KPIs sind die, die sich direkt auf die Verfügbarkeit beziehen. Ob du einen Webservice, ein SaaS-Produkt, eine E-Commerce-Website oder eine Content Marketing Website betreibst: Wenn deine Nutzer deine Website oder deinen Service nicht aufrufen können, hast du verloren.
Verfügbarkeitsrate und hohe Verfügbarkeit
Deine Verfügbarkeit ist ein einfaches Verhältnis deiner tatsächlichen Verfügbarkeitszeit dividiert durch die Gesamtzeit minus geplante Wartungszeiten. SLAs (Service Level Agreement) versprechen üblicherweise von 98 % (7,31 Tage Ausfall pro Jahr) bis zu 99,99 % Verfügbarkeit (52,60 Minuten Ausfall pro Jahr). Je näher eine SLA an 100 % (hohe Verfügbarkeit) heranreicht, desto mehr kostet der Service den Kunden.
Monitoring und Dokumentieren der SLA-Einhaltung
Mit dem SLA Monitoring von Uptrends kannst du die Einhaltung der SLA mit einem Blick prüfen. Zuerst richtest du deine SLA-Definitionen ein, um drei wichtige KPIs zu erfassen.
- Verfügbarkeit: Gib deine erforderliche Verfügbarkeitsrate und die Rate der „Gefahrenschwelle“ ein.
- Seitenladezeit: Der vereinbarte Performance-Standard.
- Operator Reaktionszeit: Die Dauer, die ein Fehler unbeachtet bleiben darf. Ein Operator meldet sich bei Uptrends an und bestätigt, dass er von dem Problem Kenntnis hat und es bearbeitet.
Du kannst mehrere SLA-Definitionen verwenden und sie in den SLA-Dashboards ansehen. Wenn ein Prüfobjekt die Nichteinhaltung einer SLA verzeichnet, wird dies im Bericht rot angezeigt. Uptrends berechnet und speichert Daten unabhängig von den Detailberichten des Prüfobjekts und du kannst ein SLA-Dokument erstellen, das jeden gewünschten Zeitraum und jedes gewünschte Prüfobjekt repräsentiert.
Performance-KPIs
Wir haben kurz den Seitenladezeit-KPI bei der Behandlung von SLAs angesprochen. Das SLA-Tracking erfasst Seitenladezeiten, aber umfasst nicht die Details und andere KPIs, die dir möglicherweise wichtig sind, wie etwa die Ladezeit des ersten Bytes oder die Zeit zum Verbindungsaufbau.
Unten haben wir KPIs auf Elementbasis und auf Seitenebene. Obwohl viele der aufgeführten KPIs gleich aussehen, sollte man beachten, wofür sie wirklich stehen. Beispielsweise steht die DNS-Auflösungszeit für ein einzelnes Element, während die DNS-Dauer die Zeit bezeichnet, die erforderlich war, die Adressen für die gesamte Seite aufzulösen.
Webpage Performance KPIs – Anfrage für Anfrage
Jedes Seitenelement hat einen eigenen „Preis“ hinsichtlich der Performance. Die kombinierten Kosten für die KPIs jedes Elements tragen zu den KPIs der Seite insgesamt bei. Die Überwachung individueller Elemente ermöglicht dir das Identifizieren von problematischen URLs und Seitenelementen wie Bild- und Skriptdateien.
Du kannst diese KPIs Uptrends’ Web Performance-Prüfobjekten entnehmen. Das Prüfobjekt Full Page Check (FPC) startet einen echten Browser (wähle aus Chrome, Internet Explorer, Firefox und Phantom JS). Dann initiiert der FPC die erste Anfrage und das Prüfobjekt verfolgt die Performance-KPIs für jede folgende Seitenanfrage.
Du kannst diese KPIs pro Check in deinen Detailberichten von Checks anzeigen oder du kannst deine Performance-Dashboards verwenden, um zu sehen, wie deine KPIs sich im Durchschnitt über einen längeren Zeitraum verhalten. Sehen wir uns zunächst die Bedeutung dieser KPIs an, wie sie in einem Wasserfallbericht angezeigt werden und wie sie sich als Durchschnittswert in Kurvendiagrammen darstellen.
Resolve Time (Auflösungszeit)
Das Auflösen eines Domainnamens in eine IP-Adresse ist der erste Schritt beim Aufbau einer TCP/IP-Verbindung. Eine langsame Auflösungszeit weist darauf hin, dass:
- die URL umgeleitet wird und weitere DNS Lookups erfordert,
- das primäre DNS überfordert ist oder
- die TTL (Time to Live) für die Adresse zu kurz eingestellt wurde und der Browser daher weitere Lookups ausführt.
Das Dashboard des Full Page Checks zeigt, dass die Auflösungszeit über einen Zeitraum von 24 Stunden fluktuiert. Der größere Ausschlag im Diagramm zeigt, dass die Auflösungszeiten plötzlich für 15 Minuten anstiegen und die längste Auflösungszeit 2,6 Sekunden betrug.
TCP Connect (Verbindung)
Die TCP-Verbindungszeit umfasst die Zeit, die für die erste IP-Verbindung mit einem Server erforderlich ist, sowie TCP-Verbindung und HTTPS Handshake. Das Optimieren der Performance für die TCP-Verbindung ist komplex. Weitere Informationen bietet O’Reilly mit einem guten Überblick zur TCP-Performance-Optimierung.
Unten ist ein Kurvendiagramm zu sehen, das die Verbindungszeiten für einen 24-Stunden-Zeitraum zeigt. Der Ausschlag in der Mitte erfolgte aufgrund eines Time-out-Fehlers bei der Verbindung.
HTTPS Handshake
Teil der TCP-Verbindung ist der HTTPS Handshake, die Zeit, in der eine verschlüsselte Verbindung anhand SSL/TLS erstellt wird. Zur Erstellung einer sicheren Verbindung präsentiert der Server zunächst ein Zertifikat, das der Client akzeptiert. Dann tauschen der Server und der Client die Schlüssel aus, um eine sichere Kommunikation zu bilden. Sobald der HTTPS Handshake vollständig ist, kann der Client den Inhalt anfordern.
In der Kachel unten siehst du, dass der Handshake ein kleiner Teil der Verbindung ist und üblicherweise weniger als eine Mikrosekunde dauert. Der Ausschlag erfolgte aufgrund des Time-out-Fehlers bei der Verbindung (wie im Diagramm oben).
Send Time (Senden)
Sobald der Client (der Browser) und Server eine Verbindung einrichten, kann der Client den Inhalt anfordern (GET). Die Sendezeit, „Send Time“, ist die Dauer, die der Client benötigt, um die Anfrage an den Server zu packen und abzugeben. Die Send Time beträgt in der Regel weniger als eine Mikrosekunde. Wir könnten eine Grafik anzeigen, aber bei null Sekunden wäre einfach nur eine flache Linie zu sehen.
Wait Time (Warten)
Sobald der Browser eine Anfrage sendet, wartet er auf eine Antwort. Die Wartezeit ist die Zeit von Send Time bis zur Antwort. Netzwerk-Latenz und Server-Verarbeitungs-/Antwortzeiten wirken sich auf die Wait Time aus.
Im Diagramm unten sind die Wait Times wie erwartet, aber stiegen plötzlich gegen 14 Uhr an, wo die Wartezeit bis 7 Sekunden betrug.
Receive Time (Empfangen)
Die Zeit ab dem ersten Byte der Daten bis zum letzten Byte der Daten, das den Browser erreicht, ist die Receive Time/Empfangszeit. Die Empfangszeit liegt häufig unter einer Mikrosekunde, aber für größere Dateien wie Bilder kann die Empfangszeit erheblich steigen.
Im Diagramm unten ist der Ausschlag bei der Receive Time auf externe Elemente (Bilder und Stylesheets) zurückzuführen.
Und zusammengenommen?
Fasst man alle KPIs in einem Kurvendiagramm zusammen, sieht man, wie die unterschiedlichen Spitzenausschläge einander beeinflussen. Im Diagramm unten trifft der Ausschlag bei der Linie der Verbindungszeit mit der gestiegenen Linie für längere Wartezeiten zusammen.
Ein ausführlicher Blick in den FPC-Wasserfall
Mit jedem Full Page Check erhältst du einen Wasserfallbericht, mithilfe dessen du die problematischen Elemente siehst. Du siehst auch genau, welcher Teil der Kommunikation ein Problem hat. Das Wasserfall-Diagramm unten zeigt einige der langen Empfangszeiten (grüne Balken), die zu den Ausschlägen bei der Receive Time im Diagramm oben geführt haben. Die Wartezeiten sind ebenfalls etwas lang (blaue Balken).
Am Ende jedes Wasserfallberichts erhältst du die Gesamtzeit und Durchschnittszeiten für jede Metrik kombiniert für die Seite.
Alle KPIs auf Elementebene addieren sich und bilden unsere KPIs auf Seitenebene. Verwende deine Performance-Dashboards, um KPIs auf Seitenebene auf Grundlage der Durchschnittswerte jedes Prüfobjekts zu erhalten. Du kannst auch die Daten mehrerer FPC-Prüfobjekte kombinieren, um über das Performance-Dashboard die Performance-Daten auf Website-Ebene zu erhalten.
Mit dem Real User Monitoring erhältst du ebenfalls KPIs auf Seitenebene, basierend auf unterschiedlichen Nutzerumgebungen.
KPIs auf Website- und Seitenebene aus Daten des Real User Monitorings
Oben haben wir uns die KPIs auf Elementbasis für eine einzelne Seite angesehen. Mit dem Real User Monitoring (RUM) kannst du diese KPIs auf unterschiedliche, interessante Weisen betrachten, die zu nutzerspezifischen Anpassungen führen können.
Mit RUM erhältst du Erfahrungsdaten direkt von deinen Nutzern, während sie durch deine Website navigieren. Du erhältst Daten, die du nach den unterschiedlichen Umgebungsvariablen sortieren kannst, die die Erfahrung jedes Nutzers einzigartig machen. Du erhältst KPIs auf Website- oder Seitenebene basierend auf:
- Gerätetyp
- Betriebssystem (und Version)
- Browsertyp (und Version)
- Standort (Land und in einigen Fällen Bundesland oder Provinz)
Wie funktioniert RUM?
Das ist recht einfach. Zunächst richtest du eine neue RUM-Website ein. Dann fügst du das kleine erzeugte Skript zwischen den HEAD-Tags deiner Seite ein und lädst die neue Seite auf den Server. Schließlich erhältst du die reichhaltigen Nutzererlebnisdaten.
Uptrends erfasst und aggregiert die Nutzerdaten und stellt sie dir in nahezu Echtzeit bereit. In deinen RUM-Dashboards kannst du die Daten nach deinen Wünschen anordnen.
Ladezeiten-KPIs
Die Ladezeiten-KPIs sagen dir, wie schnell dein Server auf eine Anfrage antwortet und wie lange es dauert, die Seite herunterzuladen und darzustellen. Diese KPIs verdeutlichen, wie der Nutzer die Seite hinsichtlich der Ladezeit erlebt.
In der Tabelle unten sehen wir uns die Ladezeiten-KPIs auf Grundlage der benutzten Gerätetypen an. Die Kategorie „Sonstige“ enthält Daten weniger häufig genutzter Geräte. Klicke darauf, um zu sehen, welche Geräte dort vertreten sind. In diesem Fall enthält die Kategorie „Sonstige“ Fernsehgeräte (die Website funktioniert anscheinend nicht so gut bei Fernsehgeräten).
Man sieht, dass die Website auf Desktopgeräten gut läuft, aber andere Geräte zeigen viel längere Wartezeiten für den Inhalt.
Du wirst feststellen, dass die als Ladezeit berichteten Zeiten nicht die Summe der Zeit vom ersten Byte bis zum vollständigem Seitenaufbau ist. Uptrends berechnet diese Werte unabhängig voneinander auf Basis von Medianwerten. Die Zeit bis zum ersten Byte ist tatsächlich ein Teil der Zeit, die den vollständigen Seitenaufbau wiedergibt.
Time to first byte (Ladezeit des ersten Bytes, TTFB)
Wenn ein Nutzer eine Ressource anfragt, ist die Dauer ab der Anfrage bis zum Zeitpunkt, zu dem der Browser das erste Byte der Daten empfängt, die Ladezeit des ersten Bytes. Eine lange Zeitspanne zum ersten Byte ist ein Zeichen, dass die Antwortzeit des Servers langsam ist oder dass die Netzwerk-Latenz ein Problem für den Standort des Nutzers und den Verbindungstyp darstellt.
Page Ready time (Ladezeit der vollständigen Seite)
Die Ladezeit der vollständigen Seite ist die Gesamtzeit, die benötigt wurde, um die Seite komplett mit allen Elementen interaktiv darzustellen.
Netzwerk-Performance-KPIs
Deine Netzwerk-Zeit ist die Kombination der Weiterleitungs-, DNS- und Verbindungszeiten.
Bei diesem Beispiel sehen wir uns Betriebssysteme an (siehe unten). Neben jedem Eintrag siehst du eine Lupe. Wenn du auf das Symbol klickst, siehst du detailliertere Daten nach der Version des Betriebssystems.
Redirect Performance (Weiterleitung)
Wenn deine Website Nutzeranfragen von einer URL zu einer anderen weiterleitet, verlängert das die Verbindungsdauer. Weiterleitungen wirken sich wahrscheinlich nicht stark auf deine Seiten-Performance aus, aber wenn mehrere Weiterleitungen in Folge auftreten (eine Weiterleitung auf eine Seite, die wiederum weiterleitet), addieren sich diese Verzögerungen. Ein Auge auf diese Weiterleitungszeiten zu haben, zeigt dir, wenn Weiterleitungen zum Problem werden.
Bei den Beispieldaten oben siehst du, dass Weiterleitungen zu erheblich gesteigerten Verbindungszeiten führen, weil Zeit für diese Weiterleitungen aufgebracht werden musste. Die Desktopversionen bei den Betriebssystemen verzeichnen überhaupt keine Weiterleitungszeiten, aber bei einigen mobilen Betriebssystemen erfordern sie beträchtliche Zeit.
DNS-Performance
Wie bereits gesagt ist die DNS-Auflösungszeit die Zeit, die es dauert, bis der Domainname in die IP-Adresse umgewandelt wurde. Bei den meisten Seiten kommen Inhalte von mehreren individuellen URLs und jede URL erfordert eine eigene Auflösung. Die DNS-Zeit ist die kombinierte Dauer der Auflösungszeiten aller URLs einer Seite.
Im Beispiel oben haben mobile Nutzer aufgrund der Weiterleitungen eine längere Auflösungszeit.
Connect Performance (Verbindung)
Die Verbindungsdauer ist die Zeit, die für die Erstellung einer Verbindung zwischen Client und Server benötigt wird. Die Verbindungszeit umfasst den HTTPS Handshake und die TCP-Verbindung.
In unserem Beispiel oben sind die Verbindungszeiten mit weniger als einer Mikrosekunde kurz, außer bei Android und iOS.
Backend Performance
Die Backend-Zeit umfasst die Zeiten für das Senden und Empfangen von Informationen, aber nicht die Zeiten für die Verarbeitung und das Laden der Inhalte. Im Beispiel unten werden die Backend-Zeiten nach Nutzer-Standort aufgelistet. Bei den Ländern mit einer Lupe werden die Daten auf Bundesstaat-/Provinz-Ebene aufgeführt.
Send Performance
Die Sendezeit ist die Dauer, die der Client benötigt, um Daten an den Server zu packen und zu senden. Je mehr Daten vom Client gesendet werden müssen, desto länger ist natürlich die Sendedauer. Die langsamste Verbindung zwischen dem Client und einem Server bestimmt die Gesamtzeit, die benötigt wird, die Daten zu senden.
Receive Performance
Die Empfangszeit ist die Dauer, die der Server benötigt, um Daten an den Client zu senden. Die Empfangszeit ist direkt proportional zur gesendeten Menge von Daten und der Verbindungsgeschwindigkeit. Die langsamste Verbindung bestimmt die Gesamtzeit der Empfangsdauer.
Frontend Performance
Die Frontend-Zeit ist die kombinierte Zeit für das Parsen und Laden des DOM (Document Object Model) und die zur Darstellung der Seiteninhalte benötigte Zeit.
Im Beispiel unten werden die Frontend-Zeiten nach unterschiedlichen Browsern aufgelistet. Wenn du auf die Lupe klickst, siehst du detailliertere Daten nach Version des Browsers.
DOM Performance
Jede Anfrage ergibt zusätzliche Inhalte und der Browser verarbeitet diese Inhalte nach dem Empfang. Der Browser nutzt die kombinierten Antworten, um das DOM (Document Object Model) zu erstellen. Sobald der Browser das DOM erstellt hat, können die Inhalte dargestellt werden. Die DOM-Zeit ist die Zeit, die vom Browser benötigt wird, das HTML (einschließlich Skript- und CSS-Dateien) in ein DOM zu verarbeiten.
Render Performance
Die Rendering-Dauer ist die Zeit, die ein Browser benötigt, um den DOM-Inhalt auf dem Bildschirm darzustellen. Die Browser-Zeit ist die direkte Messung der Verarbeitungsdauer durch den Browser.
Download Performance
Die Gesamtzeit, die benötigt wird, um den Inhalt anzufragen, zu empfangen, zu verarbeiten und darzustellen. Die Download-Zeit endet, wenn der Browser angibt, dass das DOM die Seite vollständig geladen hat.
Die interaktive Karte unten zeigt die Download-Zeiten nach Land. Mit Klicken auf ein Land öffnet sich ein neues Dashboard mit den Daten zu dem Land.
Fazit
- Website- und Webservice-Performance- sowie Verfügbarkeits-KPIs sind wichtig für alle Abteilungen: Entwicklung, System Operations, Marketing und Vertrieb.
- Häufige oder lange Ausfälle zerstören das Vertrauen der Nutzer in die Marke.
- Wenn eine SLA mit einem Anbieter besteht oder du deinen Kunden eine SLA anbietest, ist ein SLA Monitoring zum Nachweis der Einhaltung unerlässlich.
- Synthetic und Real User Monitoring sind für das Tracking der Performance- und Verfügbarkeits-KPIs wichtig.
Leave a Reply