Wie man Watchdog-Benachrichtigungen auswertet

Der Watchdog überwacht täglich die Geschwindigkeit der von Ihnen im PLUS-Monitoring gemessenen Webseiten. Bei Änderungen einer Schlüsselmetrik benachrichtigt Sie der Geschwindigkeits-Watchdog. In diesem Text erfahren Sie, wer und wie diese Benachrichtigungen auswerten sollte.

Eine Watchdog-Benachrichtigung ist eingetroffen. Was nun?

Wir haben den Watchdog basierend auf unseren Beratungserfahrungen für unsere Kunden optimiert und verwenden ihn selbst, aber dennoch erfordert die Auswertung seiner Benachrichtigungen ein gewisses Maß an Fachkenntnissen.

Aufgrund der Natur synthetischer Messungen kann es beispielsweise vorkommen, dass der Watchdog eine Benachrichtigung sendet, auch wenn kein ernsthaftes Problem auf der Website vorliegt.

Mit dem Wissen, das Sie in diesem Text erwerben, können Sie jedoch mit den Watchdog-Benachrichtigungen umgehen.

Wie funktioniert der Watchdog?#

In Kürze funktioniert der Watchdog folgendermaßen:

• Der Watchdog sammelt Daten aus synthetischen Messungen. (Siehe Unterschied zwischen verschiedenen Messarten.)
• Täglich testet der Watchdog alle in den Testeinstellungen eingetragenen URLs.
• Für jede Geschwindigkeitsmetrik wird aus diesen Daten eine einzige Zahl für die gesamte Website erstellt.
• Jede Metrik hat unterschiedliche Grenzwerte für zulässige Änderungen.
• Wird ein Grenzwert überschritten, erhalten Sie eine Benachrichtigung per E-Mail oder über Slack oder Teams.

Mehr über das Funktionieren des Watchdogs.

Benachrichtigungen sind hauptsächlich für Entwickler#

Wir empfehlen, das Watchdog-Monitoring hauptsächlich von Entwicklern und Personen in Ihrem Team zu verfolgen, die sich täglich mit der Geschwindigkeit der Website beschäftigen. Dies erfordert technisches Wissen und Zeit.

Für Manager, Marketingspezialisten, UX-Designer und ähnliche Berufe haben wir im PLUS-Monitoring andere Berichte. Zum Beispiel einen monatlichen E-Mail-Bericht über den Geschwindigkeitsstatus oder ein Team-Dashboard.

Managern empfehlen wir daher, die Watchdog-Benachrichtigungen zu deaktivieren:

In den E-Mail-Einstellungen können Sie die Watchdog-Benachrichtigungen deaktivieren, wenn Ihre Kollegen die Änderungen bereits überwachen.

Wie man Benachrichtigungen allgemein auswertet#

Wenn Sie eine E-Mail oder eine Benachrichtigung in Slack erhalten haben, sollten Ihre ersten Fragen zur Bewertung der Benachrichtigung wie folgt lauten:

1. Hat die Änderung auch Einfluss auf die Nutzermetriken, d. h. CrUX-Daten?
2. Wurden an den Tagen der Metrikänderung Anpassungen auf der Website vorgenommen (und sind diese in den Notizen sichtbar)?
3. Welche spezifischen Seitentypen beeinflussen diese Änderung?
4. Ist die Änderung im Detail des Testlaufs sichtbar?

Hat die Änderung Einfluss auf die Nutzermetriken?#

Die Erfahrenen unter Ihnen wissen bereits, dass nicht alle Metriken gleichwertig sind. Der Watchdog sammelt täglich Daten aus synthetischen Messungen, aber uns interessiert ihr Einfluss auf die Nutzerdaten.

Nutzerdaten (CrUX) können wir derzeit nicht täglich auswerten, da sie eine mehrwöchige Verzögerung haben.

Lassen Sie uns die Änderung im Watchdog bewerten. Werfen Sie einen Blick in den Bericht „Domänen“, wo wir Daten aus dem Chrome UX Report (CrUX) haben. Ist bei denselben Metriken ein Problem sichtbar? Dazu sind folgende Informationen hilfreich:

• Es ist gut zu wissen, dass CrUX-Daten kumulativ für knapp einen Monat rückwirkend berechnet werden, sodass in den Domain-Daten möglicherweise nur eine kleine Änderung sichtbar ist. Aber selbst diese kann verdächtig sein.
• Außerdem ist es gut zu wissen, dass eine Änderung in den Nutzerdaten manchmal erst drei Tage nach der tatsächlichen Änderung auf der Website auftreten kann.
• Schließlich vergessen Sie nicht, dass nicht alle von Nutzern erfassten Metriken synthetisch gemessen werden können. Siehe Anleitungen zu spezifischen Metriken weiter unten in diesem Text. Beispielsweise kann die synthetische TBT-Metrik (aber nicht unbedingt) Einfluss auf die Interaktionsgeschwindigkeit, also INP haben.

Vergessen Sie nicht, dass Nutzerdaten (CrUX) kumulativ für die letzten 28 Tage berechnet werden und eine mehrtägige Verzögerung haben können.

Fahren Sie mit den nächsten Schritten der Auswertung nur fort, wenn Sie Änderungen sowohl im Watchdog als auch in den Nutzerdaten sehen.

Metriken im Watchdog können manchmal wilde Schwankungen aufweisen, aber in den CrUX-Daten sehen Sie das nicht. In einem solchen Fall besteht kein Grund zur Panik und zur Suche nach einem Problem. Wichtiger ist die langfristige Entwicklung. Siehe auch Bericht „Domänen“.

Handelt es sich um ein zyklisches Problem?#

Ein weiterer häufiger Muster in den Daten ist die Saisonalität, also die zyklische Wiederholung bestimmter Probleme. Wie erkennt man ein solches Problem?

Im Watchdog-Bericht betrachten Sie den langfristigen Trend (mindestens 3 Monate). Einige Metriken (wie TBT) neigen dazu, sich zyklisch zu verschlechtern und zu verbessern.

Auch die saisonale Besucherzahl kann in Ihrem Fall eine Rolle spielen, was sich oft z. B. in der Server-Reaktionszeit, TTFB zeigt.

Wie man einzelne Metriken auswertet#

Im folgenden Abschnitt des Textes sehen Sie spezifische Anleitungen zum Vorgehen bei einzelnen Metriken. Sie mögen sich ähnlich erscheinen, aber das gilt nicht immer. Achten Sie auf jede einzelne Metrik.

Backend (TTFB)#

Time To First Byte (TTFB) zeigt die Server-Antwortzeit, aber in der Metrik wird auch Ihre gesamte Server-Infrastruktur sowie die Verbindungsgeschwindigkeit der Nutzer berücksichtigt.

Es handelt sich um eine sehr wichtige Metrik, deren Verschlechterung sich direkt auf die Core Web Vitals auswirkt, insbesondere auf die Ladegeschwindigkeit (LCP). Aufgrund des Crawl-Budgets, also der Fähigkeit des Googlebots, Ihre Website zu durchforsten, beeinflusst die TTFB-Metrik auch das SEO.

Wie bewertet man Benachrichtigungen über Änderungen der Server-Antwortzeit (TTFB)?

1. Hat es auch Einfluss auf die Nutzermetriken?
   Vergleichen Sie die Entwicklung der Metrik im Watchdog mit dem TTFB-Wert bei den Nutzern (Bericht „Domänen“ > Entwicklung der Metrikverteilung). Siehe Abschnitt Wie entwickeln sich die Nutzermetriken? oben.
2. Wurden an den Tagen der Metrikänderung Anpassungen auf der Website vorgenommen?
   Hilfreich können Notizen in den Grafiken sein, mit denen Sie wichtige Implementierungen auf der Website markieren können.
3. Welche spezifischen Seitentypen haben Einfluss auf diese Änderung?
   Schauen Sie sich den Bericht „Seiten“ an, in dem die Entwicklung der TTFB-Metrik für die einzelnen Seitentypen Ihrer Website sichtbar ist. Auf synthetischen und CrUX-Daten sehen Sie, ob das Problem die gesamte Website oder nur bestimmte Teile betrifft.
4. Kann Ihre Server-Infrastruktur vorübergehend stärker ausgelastet sein?
   Während Kampagnen oder in der Saison kann eine vorübergehende Verschlechterung der Server-Antwortzeiten auftreten. Wichtig ist, dass langfristig nicht die optimale Grenze von 0,8 s in den Nutzerdaten überschritten wird.
5. Sehen Sie eine kontinuierliche Verschlechterung des TTFB?
   Überwachen Sie die Speicher- und CPU-Nutzungsgrafiken Ihres Hosting-Anbieters. Aus unserer Erfahrung heraus wird das Hardware-Upgrade oft unterschätzt und kann die Lösung sein.
6. Ist die Änderung im Detail des Testlaufs sichtbar?
   Durch Klicken auf den Graphen mit den Ergebnissen synthetischer Messungen gelangen Sie in den Detail des Testlaufs mit dem Lighthouse-Bericht. Vergleichen Sie die Ergebnisse mit dem Detail des Testlaufs vom Vortag. Im Lighthouse-Bericht finden Sie auch spezifische Ursachen für Probleme und Optimierungsmöglichkeiten für diese Metrik. Entwickler sollten in der Lage sein, Web Vitals direkt im Browser zu messen, wo sie auch die Ausgaben aus dem Detail des Testlaufs öffnen können.

Beschäftigen Sie sich im Team mit der Optimierung der TTFB-Metrik, und zwar nicht nur reaktiv, wenn ein Problem auftritt.

Erstes Contentful Paint (FCP)#

Die Metrik First Contentful Paint (FCP) zeigt die Zeit an, die benötigt wird, um den ersten Inhalt auf Ihrer Website zu rendern.

Es handelt sich um eine wichtige Hilfsmetrik, deren Änderungen oft Auswirkungen auf die Ladegeschwindigkeit (LCP) und verschiedene Nutzermetriken wie die Absprungrate haben.

Wie bewertet man Benachrichtigungen über Änderungen der FCP-Metrik?

1. Hat es auch Einfluss auf die Nutzermetriken?
   Vergleichen Sie die Entwicklung der Metrik im Watchdog mit dem FCP-Wert bei den Nutzern (Bericht „Domänen“ > Entwicklung der Metrikverteilung). Siehe Abschnitt Wie entwickeln sich die Nutzermetriken? oben.
2. Wurden an den Tagen der Metrikänderung Anpassungen auf der Website vorgenommen? 
   Hilfreich können Notizen in den Grafiken sein, mit denen Sie wichtige Implementierungen auf der Website markieren können.
3. Welche spezifischen Seitentypen haben Einfluss auf diese Änderung?
   Schauen Sie sich den Bericht „Seiten“ an, in dem die Entwicklung der FCP-Metrik für die einzelnen Seitentypen Ihrer Website sichtbar ist. Auf synthetischen und CrUX-Daten sehen Sie, ob das Problem die gesamte Website oder nur bestimmte Teile betrifft.
4. Ist das Kernproblem mit einer anderen Metrik messbar?
   Hat sich auch die Server-Antwortzeit, also die TTFB-Metrik, in den Berichten geändert? Die Backend-Geschwindigkeit kann direkten Einfluss auf die FCP- und LCP-Metriken haben, daher finden Sie den Schuldigen oft hier.
5. Liegt das Problem in den kritischen Ressourcen und lässt sich in technischen Indikatoren finden?
   Hat sich die FCP geändert, aber nicht die TTFB? Der Unterschied zwischen diesen beiden Metriken liegt in den kritischen Ressourcen, die für das erste Rendering der Seite erforderlich sind. Änderungen sollten Sie daher im Bericht „Technische“ und in den Indikatorwerten wie Datenvolumen HTML, Datenvolumen CSS, Anzahl blockierender JS suchen… Es ist möglich, dass hier eine Änderung eingetreten ist, die die Verschlechterung des FCP verursacht hat.
6. Ist die Änderung im Detail des Testlaufs sichtbar?
   Durch Klicken auf den Graphen mit den Ergebnissen synthetischer Messungen gelangen Sie in den Detail des Testlaufs mit dem Lighthouse-Bericht. Vergleichen Sie die Ergebnisse mit dem Detail des Testlaufs vom Vortag. Im Lighthouse-Bericht finden Sie auch spezifische Ursachen für Probleme und Optimierungsmöglichkeiten für diese Metrik. Entwickler sollten in der Lage sein, Web Vitals direkt im Browser zu messen, wo sie auch die Ausgaben aus dem Detail des Testlaufs öffnen können.

Beschäftigen Sie sich mit der Optimierung der FCP-Metrik, und zwar nicht nur reaktiv, wenn ein Problem auftritt.

Größtes Contentful Paint (LCP)#

Die Metrik Largest Contentful Paint (LCP) zeigt die Zeit an, die benötigt wird, um den Hauptinhalt auf einer bestimmten Seite Ihrer Website zu rendern.

Es ist eine der drei wichtigsten Metriken, Teil der Core Web Vitals, und ein Indikator, der sehr oft beispielsweise bei Online-Shops mit der Konversionsrate korreliert.

Wie bewertet man Benachrichtigungen über Änderungen der LCP-Metrik?

1. Hat es auch Einfluss auf die Nutzermetriken?
   Vergleichen Sie die Entwicklung der Metrik im Watchdog mit dem LCP-Wert bei den Nutzern (Bericht „Domänen“ > Entwicklung der Metrikverteilung). Siehe Abschnitt Wie entwickeln sich die Nutzermetriken? oben.
2. Wurden an den Tagen der Metrikänderung Anpassungen auf der Website vorgenommen?  
   Hilfreich können Notizen in den Grafiken sein, mit denen Sie wichtige Implementierungen auf der Website markieren können.
3. Welche spezifischen Seitentypen haben Einfluss auf diese Änderung?
   Schauen Sie sich den Bericht „Seiten“ an, in dem die Entwicklung der LCP-Metrik für die einzelnen Seitentypen Ihrer Website sichtbar ist. Auf synthetischen und CrUX-Daten sehen Sie, ob das Problem die gesamte Website oder nur bestimmte Teile betrifft.
4. Ist das Kernproblem mit einer anderen Metrik messbar?
   Hat sich auch die Server-Antwortzeit, also die TTFB-Metrik, in den Berichten geändert? Die Backend-Geschwindigkeit kann direkten Einfluss auf die FCP- und LCP-Metriken haben, daher finden Sie den Schuldigen oft hier.
   Das Problem finden Sie oft auch in Änderungen der FCP-Metrik, siehe oben. Wenn sich die TTFB nicht geändert hat, aber FCP und LCP, bedeutet das, dass das Problem bei FCP liegt. Der Schuldige könnte die Verschlechterung des Datenvolumens kritischer Ressourcen sein.
5. Liegt das Problem in den Ressourcen für LCP-Elemente und lässt sich in technischen Indikatoren finden?
   Wenn Sie keine Änderungen der TTFB- oder FCP-Metriken sehen, kann das Problem im Unterschied zwischen FCP und LCP liegen, der durch das Herunterladen und Rendern der größten Seitenelemente entsteht. Diese sind oft asynchron – es handelt sich um Bilder, JavaScript-Komponenten, Webfonts und andere. Änderungen sollten Sie daher im Bericht „Technische“ und in den Indikatorwerten wie Datenvolumen JS, Datenvolumen Fonts oder Datenvolumen Bilder suchen.
6. Ist die Änderung im Detail des Testlaufs sichtbar? Klicken Sie auf den Graphen mit den Ergebnissen synthetischer Messungen, um den Detail des Testlaufs mit dem Lighthouse-Bericht aufzurufen. Vergleichen Sie die Ergebnisse mit dem Detail des Testlaufs vom Vortag. Im Lighthouse-Bericht finden Sie auch spezifische Ursachen für Probleme und Optimierungsmöglichkeiten für diese Metrik. Entwickler sollten in der Lage sein, Web Vitals direkt im Browser zu messen, wo sie auch die Ausgaben aus dem Detail des Testlaufs öffnen können.

Beschäftigen Sie sich mit der Optimierung der LCP-Metrik, und zwar nicht nur reaktiv, wenn ein Problem auftritt.

Gesamtblockierungszeit von JS (TBT)#

Die Metrik Total Blocking Time (TBT) zeigt die gesamte Zeit an, in der JavaScript den Browser blockiert und somit die Reaktionszeiten auf Benutzerinteraktionen verlangsamen und die INP-Metrik verschlechtern kann.

Die Reaktionszeit-Metrik (INP), die ein wichtiger Bestandteil der Core Web Vitals ist, kann nur bei Nutzern gemessen werden (CrUX-Daten), daher kann der Watchdog ihre Änderungen nicht melden.

Die TBT-Metrik kann synthetisch gemessen werden, kann auf eine mögliche Verschlechterung von INP hinweisen, aber es besteht keine direkte Korrelation. Eine Verschlechterung von TBT kann INP verschlechtern, aber INP kann sich auch ohne Änderung von TBT verschlechtern. Daher empfehlen wir, sowohl die Watchdog-Benachrichtigungen (TBT) als auch die Entwicklung der Nutzerdaten (INP) zu verfolgen.

Es ist auch wichtig zu sagen, dass die TBT-Metrik die „volatilste“ von allen ist. Im Diagramm werden Ihnen die Zahlen von niedrigeren zu höheren Werten „springen“. Der Watchdog meldet intelligent nur größere Änderungen und dasselbe sollten auch Sie beobachten. Einfach die TBT-Metrik etwas mehr „mit Vorsicht“ betrachten als die anderen.

Wie bewertet man Benachrichtigungen über Änderungen der TBT-Metrik?

1. Hat es auch Einfluss auf die Nutzermetriken?
   Vergleichen Sie die Entwicklung der Metrik im Watchdog mit dem INP-Wert bei den Nutzern (Bericht „Domänen“ > Entwicklung der Metrikverteilung). Siehe Abschnitt Wie entwickeln sich die Nutzermetriken? oben.
2. Wurden an den Tagen der Metrikänderung Anpassungen auf der Website vorgenommen?
   Hilfreich können Notizen in den Grafiken sein, mit denen Sie wichtige Implementierungen auf der Website markieren können.
3. Welche spezifischen Seitentypen haben Einfluss auf diese Änderung?
   Schauen Sie sich den Bericht „Seiten“ an, in dem die Entwicklung der TBT-Metrik für die einzelnen Seitentypen Ihrer Website sichtbar ist. Auf synthetischen Daten sehen Sie, ob das Problem die gesamte Website oder nur bestimmte Teile betrifft. Ähnlich kann man sich im selben Bericht mit der Entwicklung der INP-Metrik befassen.
4. Welchen Einfluss haben Drittanbieter-Komponenten?
   Im Bericht „Seiten“ schauen Sie sich auch die Entwicklung der 3PBT-Metrik an, die den Teil von TBT zeigt, den unsere Automatik den Drittanbieter-Komponenten zugeordnet hat. Wenn der Anteil der blockierenden Zeit von Drittanbietern mehr als die Hälfte beträgt, sollten Sie unbedingt aufmerken. Im Bericht „Detail des Testlaufs“ erfahren Sie dann, welche spezifischen Drittanbieter hier problematisch sind.
5. Ist die Änderung im Detail des Testlaufs sichtbar?
   Durch Klicken auf den Graphen mit den Ergebnissen synthetischer Messungen gelangen Sie in den Detail des Testlaufs mit dem Lighthouse-Bericht. Vergleichen Sie die Ergebnisse mit dem Detail des Testlaufs vom Vortag. Im Lighthouse-Bericht finden Sie auch spezifische Ursachen für Probleme und Optimierungsmöglichkeiten für diese Metrik. Entwickler sollten in der Lage sein, Web Vitals direkt im Browser zu messen, wo sie auch die Ausgaben aus dem Detail des Testlaufs öffnen können.

Im Allgemeinen gilt – wenn die INP-Metrik in Ordnung ist, sich aber die TBT- oder 3PBT-Metriken erheblich verschlechtert haben, müssen Sie diese Änderungen nicht als kritisch betrachten.

Dennoch ist es ratsam, sich regelmäßig mit der Optimierung der INP-Metrik zu befassen, und zwar nicht nur reaktiv, wenn ein Problem auftritt.

Kumulativer Layout-Shift (CLS)#

Die Metrik Cumulative Layout Shift (CLS) zeigt das Ausmaß unerwünschter Layout-Verschiebungen, die der Benutzer während des Ladens und der anschließenden Verwendung der Seite erlebt.

Es handelt sich um eine wichtige Metrik, eine der drei Core Web Vitals, nach denen Google Websites für SEO- und PPC-Zwecke bewertet:

Wie bewertet man Benachrichtigungen über Änderungen der CLS-Metrik?

1. Hat es auch Einfluss auf die Nutzermetriken?
   Vergleichen Sie die Entwicklung der Metrik im Watchdog mit dem CLS-Wert bei den Nutzern (Bericht „Domänen“ > Entwicklung der Metrikverteilung). Siehe Abschnitt Wie entwickeln sich die Nutzermetriken? oben.
2. Wurden an den Tagen der Metrikänderung Anpassungen auf der Website vorgenommen? 
   Hilfreich können Notizen in den Grafiken sein, mit denen Sie wichtige Implementierungen auf der Website markieren können.
3. Was tun, wenn sich CrUX und synthetische Daten für die CLS-Metrik stark unterscheiden?
   Es ist wichtig zu verstehen, dass das vom Watchdog erfasste CLS (also synthetische Messungen) sich vom aus Nutzerdaten erfassten CLS (CrUX) unterscheiden kann. Während synthetisch nur die Layout-Verschiebungen gemessen werden können, die beim ersten Laden der Seite sichtbar sind, sehen wir in den CrUX-Daten „Layout-Shifts“ auch beim anschließenden Verwenden der Seite. Wenn Sie also ein niedriges CLS in der Synthese, aber ein hohes in CrUX sehen, werden die unerwünschten Verschiebungen nicht beim ersten Laden, sondern beim anschließenden Verwenden der Seite sichtbar.
4. Welche spezifischen Seitentypen haben Einfluss auf diese Änderung?
   Schauen Sie sich den Bericht „Seiten“ an, in dem die Entwicklung der CLS-Metrik für die einzelnen Seitentypen Ihrer Website sichtbar ist. Auf synthetischen und CrUX-Daten sehen Sie, ob das Problem die gesamte Website oder nur bestimmte Teile betrifft.
5. Ist die Änderung im Detail des Testlaufs sichtbar?
   Durch Klicken auf den Graphen mit den Ergebnissen synthetischer Messungen gelangen Sie in den Detail des Testlaufs mit dem Lighthouse-Bericht. Vergleichen Sie die Ergebnisse mit dem Detail des Testlaufs vom Vortag. Im Lighthouse-Bericht finden Sie auch spezifische Ursachen für Probleme und Optimierungsmöglichkeiten für diese Metrik. Entwickler sollten in der Lage sein, Web Vitals direkt im Browser zu messen, wo sie auch die Ausgaben aus dem Detail des Testlaufs öffnen können.

Beschäftigen Sie sich mit der Optimierung der CLS-Metrik, und zwar nicht nur reaktiv, wenn ein Problem auftritt.

Zusammenfassung#

Die Auswertung der Watchdog-Benachrichtigungen ist zusammen mit der eigentlichen Überwachung ein wichtiger Bestandteil der Arbeit zur Verbesserung oder Aufrechterhaltung einer guten Web-Geschwindigkeit.

Es ist wichtig, im Team zu klären, wer die Überwachung und Auswertung der Benachrichtigungen übernimmt und regelmäßig durchführt. Dazu sind technische Fähigkeiten und Kenntnisse der Metriken und der Website erforderlich.

Wenn Sie es noch nicht getan haben, empfehlen wir Ihnen, zu lernen, wie der Watchdog funktioniert und wie Sie Benachrichtigungen per E-Mail oder Slack richtig einrichten.