Weitere Neuerungen in Test PLUS (stabile Infrastruktur, „Technischer“ Bericht und Anmerkungen in Diagrammen)

Martin MichálekMartin Michálek22.2.202411 Minuten Lesen

Neben dem Geschwindigkeitswächter und Benachrichtigungen bringt Monitoring PLUS viele weitere Neuerungen, die die Überwachung und Bewertung der Geschwindigkeit Ihrer Websites erleichtern.

In diesem Text konzentrieren wir uns besonders auf drei davon:

  1. Eigene stabile Testinfrastruktur.
  2. Neuer „Technischer“ Bericht.
  3. Anmerkungen in Diagrammen.

Stabile Zahlen (eigene Lighthouse und Testinfrastruktur)

In der PLUS-Version steht Ihnen unsere eigene Testinfrastruktur zur Verfügung, auf der das Open-Source-Tool Lighthouse täglich Ihre Website testet.

Warum ist eine eigene Infrastruktur für professionelles Geschwindigkeitstesten so entscheidend? Es gibt zwei Hauptgründe:

  • Stabilität der Ergebnisse, die Ihre Tests weniger von externen Faktoren beeinflussen lässt.
  • Möglichkeit, zusätzliche Funktionen zu nutzen, wie zum Beispiel das Speichern des Trace-Berichts.

Lassen Sie uns nun im Detail erklären, warum das so wichtig ist.

Stabilität der Ergebnisse

In der kostenlosen Version unseres Testers liefern wir seit Beginn der Entwicklung Ergebnisse aus der PageSpeed Insights API, die Google kostenlos zur Verfügung stellt.

Es gibt jedoch ein Problem: Die Ergebnisse der PageSpeed Insights API sind instabil.

Vergleich des Tests derselben Website und derselben Metrik (LCP) in der kostenlosen und der PLUS-Version.

Google erhält die Ergebnisse aus PageSpeed Insights zu unterschiedlichen Zeiten, an verschiedenen Orten und aus unterschiedlichen Teilen seiner Infrastruktur. Daher sind die gewonnenen Daten eher für einmalige Tests oder zur Beobachtung langfristiger Trends geeignet, nicht jedoch für tägliche Änderungen.

Die Testergebnisse von Lighthouse aus unserer eigenen Infrastruktur sehen Sie im unteren Bild. Die Daten sind weitaus stabiler, sodass Sie besser unterscheiden können, was eine vernachlässigbare Schwankung und was eine dauerhaftere Änderung der Metrik ist.

Endergebnisse und JSON, Trace, HAR

In der PLUS-Version können Sie den konkreten Ergebnissen einzelner Lighthouse-Tests weitaus mehr Vertrauen schenken. Und darüber hinaus haben wir sie um die Möglichkeit erweitert, Quelldateien herunterzuladen, die Sie zur weiteren Suche nach Möglichkeiten zur Beschleunigung Ihrer Website nutzen können.

Die Ergebnisse des Lighthouse-Tests sind in der neuen Version um mehrere Funktionen erweitert. Die Ergebnisse des Lighthouse-Tests sind in der neuen Version um mehrere Funktionen erweitert.

Was verbirgt sich hinter den geheimnisvollen Abkürzungen JSON, Trace und HAR, die Sie im Bild sehen?

Alle drei Dateien sind ein wichtiges Hilfsmittel für jeden Geschwindigkeitsoptimierer, wenn es darum geht, Ursachen für Veränderungen oder Chancen zur Verbesserung zu finden.

  • JSON: Transportables Ergebnis des Lighthouse-Berichts. Öffnen Sie es z.B. im Lighthouse Report Viewer oder vergleichen Sie es mit einem anderen Test im Lighthouse Diff. Dies wird nützlich sein, um zwei Geschwindigkeitstests im Falle einer Änderung zu vergleichen oder um einen Test zu speichern, der unerwartet positive oder negative Ergebnisse für zukünftige Zwecke zeigt.
  • Trace: Detaillierter Leistungsbericht der Seite. Er kann in der Performance-Registerkarte in den Chrome DevTools oder in einem Tool wie Trace.Café geöffnet werden. Trace betrachten wir in unserem Beratungsdienst zur Webgeschwindigkeit als das wesentlichste Abbild der tatsächlichen Ladegeschwindigkeit und der anschließenden Leistungsfähigkeit der Seite.
  • HAR: Bericht über das Herunterladen der Seite. Öffnen Sie es beispielsweise in der Netzwerk-Registerkarte innerhalb der Chrome DevTools. Es ist ein ergänzender Bericht, der Ihnen detailliert mögliche Probleme beim Laden der Seite zeigt, einschließlich der Priorisierung von Elementen, ihrer Ladequellen, des verwendeten Protokolls oder der Kompression.

Wir freuen uns, Ihnen diese unsere bevorzugten Werkzeuge in der PLUS-Version zur Verfügung stellen zu können.

Wie testen wir genau mit Lighthouse?

Basierend auf unseren Erfahrungen mit anderen Werkzeugen im Rahmen der Beratung zur Webgeschwindigkeit und vielen Experimenten, die wir während der Entwicklung der neuen Tester-Version durchgeführt haben, sind wir zu folgendem Verfahren für das Testen jeder URL gekommen:

  • Nächtliche Stunden Für die kurzfristige (Tage) und langfristige (Monate) Überwachung halten wir nächtliche Zeiten für Best-Practice. Nachts sind Ihre Server weniger belastet, wir können sie in Ruhe testen und sehen so den langfristigen Trend der Verbesserung oder Verschlechterung der Geschwindigkeit. Die Serverantwortgeschwindigkeit beeinflusst schließlich die Nutzermetriken, auf die wir achten, wie LCP oder FCP. Wir haben die Erfahrung gemacht, dass nächtliche Ergebnisse viel stabiler sind und Ihnen mehr über die Entwicklung der Metriken im Laufe der Zeit verraten. Wenn Ihnen nächtliche Zeiten nicht zusagen, beispielsweise weil die Tests während einer laufenden Wartung Ihrer Website durchgeführt werden, können Sie in den Einstellungen den Startzeitpunkt des Tests ändern.
  • Fünfmal kurz hintereinander Wir wissen, dass einmalige Tests, wie PageSpeed Insights in unseren kostenlosen Tests, sehr ungenaue Ergebnisse zeigen können. Durch Experimentieren haben wir festgestellt, dass fünf Tests notwendig sind, um die meisten Ungenauigkeiten zu beseitigen und maximale Zahlstabilität zu erreichen. Die Tests erfolgen im Abstand von wenigen Minuten, die genauen Zeiten sehen Sie immer im Detail des Lighthouse-Tests.
  • Einmal täglich Jede URL wird also standardmäßig im Abstand von wenigen Minuten getestet, und diese Tests führen wir immer einmal täglich durch, meist in der Nacht. Es ist gut zu wissen, dass unser Ziel nicht die Überwachung der Verfügbarkeit ist, die weit häufigere Tests erfordert, sondern die Beobachtung der Entwicklung von Nutzermetriken wie LCP, CLS oder INP.

Das Testen erfolgt auf der europäischen Infrastruktur von Amazon Web Services (AWS), aber in Zukunft können unsere Tests praktisch von überall durchgeführt werden.

„Technischer“ Bericht

Das moderne Fachgebiet der Webgeschwindigkeitsoptimierung verfolgt nicht mehr vorrangig technische Indikatoren wie das Datenvolumen von Seitenelementen oder die Anzahl der vom Server kommenden Dateien.

Aus der Praxis unserer Beratung zur Webgeschwindigkeit wissen wir sehr gut, dass auch Websites, die große Datenmengen herunterladen, dank guter Optimierung der ersten Ansichten letztendlich schnell für den Nutzer sein können.

Dennoch freuen wir uns sehr, Ihnen den „Technischen“ Bericht vorstellen zu können, der genau diese sekundären Indikatoren überwacht. Das Datenvolumen, die Anzahl der Anfragen und andere Metriken sind aus anderen Gründen wertvoll zu beobachten:

  • Technische Metriken eignen sich, um Zusammenhänge zwischen den Änderungen der Werte von Nutzermetriken (z.B. LCP, CLS, INP) und Änderungen bei der Webentwicklung (z.B. Datenvolumen von Bildern oder Größe blockierender JavaScripts) zu finden.
  • Die Datenvolumenersparnis betrachten wir als Höflichkeit gegenüber Nutzern, die möglicherweise begrenzte Datenressourcen auf ihrem Handy haben.
  • Es gilt oft, je weniger Daten übertragen werden, desto mehr spart der Website-Betreiber an Infrastruktur.

Im Test PLUS sehen Sie den „Technischen“ Bericht für alle Typenseiten, die Sie in die Testeinstellungen einfügen.

Wie aus dem unten stehenden Diagramm ersichtlich, zeigen wir Ihnen sowohl den aktuellen Zustand der Metrik als auch ihre Entwicklung im Laufe der Zeit. Getrennt für Mobil- und Desktopgeräte.

Tester und sein technischer Bericht Es ist ein wenig voluminös, aber zumindest stabil voluminös. Es sind Bilder.

Basierend auf unseren Beratungserfahrungen haben wir dem „Technischen“ Bericht folgende Informationen hinzugefügt:

  • Datenvolumen HTML Entwicklung des Datenvolumens von HTML für einzelne Seiten. Dies ist der Zustand, in dem HTML im Testbrowser ankommt, also bereits nach Gzip- oder Brotli-Kompression. Je kleiner das HTML-Datenvolumen, desto besser. Wir empfehlen eine Größe von bis zu 20 kB. Es beeinflusst Metriken wie FCP oder LCP.
  • Anzahl der DOM-Knoten Entwicklung der Anzahl der DOM-Knoten für einzelne Seiten über die Zeit. Ein komplexer DOM-Baum erschwert die Arbeit von JavaScript, was Metriken wie TBT oder INP beeinflussen kann. Google empfiehlt maximal 1.400 DOM-Knoten.
  • Datenvolumen CSS Entwicklung des Datenvolumens von CSS-Dateien für einzelne Seiten über die Zeit. Dies ist der Zustand nach eventueller Gzip- oder Brotli-Kompression auf Ihrem Server. CSS ist in der Regel eine Ressource, die das erste Rendern blockiert, und seine Größe hat somit Einfluss auf Metriken wie FCP oder LCP. Halten Sie das Datenvolumen von CSS idealerweise unter 50 kB.
  • Anzahl blockierender JS Entwicklung der Anzahl der JS-Dateien, die das erste Rendern blockieren. JavaScript muss nicht blockierend sein, im Gegensatz zu CSS. Je weniger blockierende JS Sie haben, desto besser für Metriken wie FCP oder LCP.
  • Datenvolumen JS Entwicklung des Datenvolumens von JS-Dateien für einzelne Seiten über die Zeit. Hier sind sowohl die Dateien, die das erste Rendern blockieren, als auch die nicht blockierenden aufgeführt. Im Diagramm sehen Sie den Zustand nach eventueller Gzip- oder Brotli-Kompression auf Ihrem Server. Je kleiner das JS, desto weniger Code muss vom Browser verarbeitet und ausgeführt werden. Es hat Einfluss auf Interaktionsmetriken wie TBT oder INP. Blockierende JS beeinflussen auch FCP und LCP, also das erste Rendern.
  • Datenvolumen von Drittanbieter-JS Entwicklung des Datenvolumens von JavaScript-Drittanbietern für einzelne Seiten über die Zeit. In diese Kategorie fällt JS, das außerhalb Ihrer Hauptdomäne ausgeführt wird, sodass es sein kann, dass Sie hier auch Ihre eigenen Dateien sehen, die außerhalb der Hauptdomäne platziert sind. In der Regel finden Sie hier das Datenvolumen fremden Codes für Komponenten wie Analysetools, Chats, A/B-Tests, Werbung usw. Auch dieser Code hat Einfluss auf Interaktionsmetriken wie TBT oder INP. Es ist daher wichtig, ihn so klein wie möglich zu halten.
  • Datenvolumen von Schriftarten Entwicklung des Datenvolumens von Schriftarten für einzelne Seiten über die Zeit. Schriftarten sind in der Regel eine Ressource, die für das Rendern von Inhalten benötigt wird und somit Einfluss auf die Metrik LCP haben. Wir empfehlen, ihr Datenvolumen unter 50 kB zu halten.
  • Datenvolumen von Bildern Entwicklung des Datenvolumens von Bildern für einzelne Seiten über die Zeit. Bilder sind oft eine Ressource, die für das Rendern von Inhalten benötigt wird und somit Einfluss auf die Metrik LCP haben kann. Wir empfehlen, ihr Datenvolumen für jede Seite unter 100 kB zu halten.
  • Gesamtes Datenvolumen Entwicklung des Datenvolumens aller heruntergeladenen Dateien für einzelne Seiten über die Zeit. Das gesamte Datenvolumen muss keinen Einfluss auf Metriken und das Nutzererlebnis haben, dennoch empfehlen wir, es für jede Seite unter 0,5 MB zu halten.

Einige der technischen Indikatoren, die wir überwachen. Im tatsächlichen Bericht gibt es noch weit mehr. Einige der technischen Indikatoren, die wir überwachen. Im tatsächlichen Bericht gibt es noch weit mehr.

Die Überwachung technischer Indikatoren kann Ihnen sehr helfen, wenn Sie sich entschließen, sich auf eine der oben genannten Metriken und eine der spezifischen Typenseiten zu konzentrieren.

Anmerkungen in Diagrammen

Während der Entwicklung einer Website gibt es viele Änderungen, die Einfluss auf die Geschwindigkeit und Metriken haben.

Anmerkungen in den Diagrammen unseres Geschwindigkeitstesters ermöglichen es Ihnen, wichtige Momente in der Entwicklungsgeschichte Ihrer Website zu markieren, damit Sie Verbesserungen oder Verschlechterungen der Metriken besser nachvollziehen können. Dies können beispielsweise folgende Ereignisse sein:

  • Sie setzen eine neu gestaltete Version der Website ein.
  • Sie führen größere Änderungen im Backend durch.
  • Sie implementieren eine spezifische Geschwindigkeitsoptimierung.
  • Sie fügen der Website eine neue Drittanbieterkomponente hinzu.
  • Sie ändern die Messung durch Anpassung der überwachten URLs.

In der PLUS-Version können Sie zu jedem Tag in jedem Diagramm eine Anmerkung hinzufügen:

Haben Sie Cloudflare implementiert? Alles wird in der Webhistorie sichtbar. Haben Sie Cloudflare implementiert? Eine wichtige Änderung muss in der Webhistorie festgehalten werden.

Diese wichtigen Änderungen sehen Sie dann in den Diagrammen, was Ihnen einen wichtigen Kontext für Ihre weitere Arbeit und die Bewertung von Anpassungen bietet.

Etwas hat sich verändert. Hatte es Einfluss auf die Geschwindigkeitsmetriken? Etwas hat sich verändert. Hatte es Einfluss auf die Geschwindigkeitsmetriken?

Zum Schluss geben wir Ihnen einige Empfehlungen, wie Sie mit Anmerkungen arbeiten sollten:

  • Fügen Sie nur wichtige Änderungen ein, die Einfluss auf die Geschwindigkeit haben. Wenn Sie mehrmals pro Woche eine neue Version der Website veröffentlichen, ist es nicht notwendig, jedes Mal eine Anmerkung hinzuzufügen. Bald würden Sie in der Menge der Daten in den Diagrammen den Überblick verlieren.
  • Vergessen Sie nicht die Änderungen außerhalb der technischen Webentwicklung: Designanpassungen, Implementierung von Drittanbieterkomponenten, durchgeführtes A/B-Testing und so weiter.
  • Scheuen Sie sich nicht, Anmerkungen auch rückwirkend hinzuzufügen, wenn Sie größere Änderungen in den Metrikdiagrammen sehen. Diese Anmerkungen erklären am besten, welchen Einfluss welche Änderung hat, und lehren Sie, den Einfluss zukünftiger Anpassungen zu bewerten.
  • Vergessen Sie nicht, eine Anmerkung hinzuzufügen, wenn Sie die Testeinstellungen ändern. Jede Hinzufügung oder Änderung der URL wird zum Beispiel Einfluss auf die Diagramme und die Warnungen des Geschwindigkeitswächters haben.

Anmerkungen sind ein relativ unauffälliger, aber sehr nützlicher Helfer für jeden, dem die Entwicklung der Geschwindigkeit seiner eigenen Websites am Herzen liegt.

Weitere Neuerungen in der PLUS-Version

5 detailliert getestete URLs

Wir empfehlen, in einen PLUS-Test eine detaillierte Überprüfung einer Website einzufügen. Wenn Ihre Website mehrere Sprachversionen hat, empfehlen wir, die URLs aller Typenseiten der wichtigsten Website aufzunehmen.

Jede URL wird detailliert täglich getestet. Die Daten sammeln wir mithilfe von Lighthouse-Tests, die auf unserer eigenen Infrastruktur laufen, aber auch aus öffentlichen Daten des Chrome UX Report.

Die getesteten Adressen werden gleichzeitig als Quelle für die regelmäßige Geschwindigkeitsüberprüfung durch den Geschwindigkeitswächter gezählt.

5 getestete Domains

Neben detaillierten Tests ermöglichen wir Ihnen, Nutzerdaten aus dem Chrome UX Report für weitere Domains zu überwachen.

Dies ist nützlich, wenn Ihre Website mehrere Sprachversionen in Form einer Second-Level-Domain oder Subdomains als Third-Level-Domains hat. Es ist auch möglich, die Ergebnisse Ihrer Konkurrenz zu verfolgen.

Falls Sie mehr Domains überwachen müssen, empfehlen wir, Ihrem Team-Dashboard kostenlose Tests hinzuzufügen, die dies ebenfalls ermöglichen.

Möglichkeit, die Testzeit zu ändern

Unsere kostenlosen Tests erlauben es nicht, die Testzeit zu ändern, was nachteilig ist, wenn Sie nicht möchten, dass die Tests während einer laufenden nächtlichen Wartung durchgeführt werden.

In der PLUS-Version können Sie daher die ungefähre Startzeit des Tests wählen und so die Wartung umgehen.

Einjährige Datenhistorie

Während wir bei den kostenlosen Tests nur eine dreimonatige Datenhistorie verfolgen und anzeigen, können Sie in den PLUS-Tests eine bis zu einjährige Datenhistorie anzeigen lassen, wobei die Daten noch etwas länger archiviert werden.

Nicht-öffentliche Adressen

Die Daten in den kostenlosen Tests verstecken wir nicht vor Menschen und Maschinen wie dem Googlebot. In den kostenpflichtigen Tests schützen wir Ihre Privatsphäre, und die URLs Ihrer Berichte sind nicht zugänglich.

Die Daten im Bericht können jedoch über eine spezielle URL zum Teilen an nicht angemeldete Kollegen weitergegeben werden.

Werfen Sie auch einen Blick auf weitere Eigenschaften der PLUS-Tests.