LCP-Alarm (Pagespeedy)
Meldet, wenn das p75 des Largest Contentful Paint über dem Schwellwert liegt. Meist der erste Einzelmetrik-Alarm, den du aktivierst.
Voreinstellung: p75 über 2.500 ms (2,5 s), RUM und CrUX
Core-Web-Vitals-Monitoring für Shopware 6
Langsame Seiten kosten Conversion und Rankings. Monitorio holt echte Nutzermesswerte (RUM) und Google-Felddaten (CrUX) zu den Core Web Vitals aus Pagespeedy Watch, hält sie als Verlauf vor und alarmiert – bei festen Schwellwerten ebenso wie bei Verschlechterung gegenüber deinem 28-Tage-Schnitt.
- 7 Alarme
- RUM-Daten alle 15 Minuten
- Kein Monitorio-Plugin nötig
- Pagespeedy-Watch-Projekt nötig
Welche Web Vitals Monitorio überwacht
Monitorio misst hier nichts selbst. Die RUM-Werte entstehen bei echten Besuchern deines Shops und liegen in Pagespeedy Watch, die CrUX-Werte kommen von Google und beschreiben immer die letzten 28 Tage. Monitorio ruft beides ab – die RUM-Daten im Standard alle 15 Minuten, die CrUX-Daten etwa einmal täglich –, legt einen Verlauf an und vergleicht ihn mit deinen Schwellwerten. Überwacht wird jeweils das p75.
LCP – Largest Contentful Paint
Wie lange es dauert, bis das größte sichtbare Element der Seite geladen ist. Von den drei Core Web Vitals der wichtigste fürs Ranking.
INP – Interaction to Next Paint
Wie schnell die Seite auf Klicks, Taps oder Tastatureingaben reagiert. INP hat FID als Core Web Vital abgelöst und ist besonders auf interaktionsreichen Seiten wie Warenkorb und Checkout relevant.
CLS – Cumulative Layout Shift
Wie stark sich Inhalte der Seite unerwartet verschieben.
FCP – First Contentful Paint
Wie lange es dauert, bis überhaupt das erste Element der Seite sichtbar gerendert wird.
TTFB – Time to First Byte
Wie lange es dauert, bis das erste Byte der Serverantwort eintrifft – hier aus echten Nutzer- und CrUX-Felddaten statt synthetisch gemessen.
Eine Quelle reicht für den Alarm
Ein Schwellwert-Alarm feuert, sobald eine der aktivierten Quellen anschlägt. Bei RUM müssen alle betrachteten, aktuellen und ausreichend befüllten Stunden-Buckets über der Schwelle liegen, bei CrUX genügt ein einzelner frischer Form-Factor (Gerätetyp).
7 Alarme für feste Schwellwerte und Verschlechterung
Fünf Einzelmetrik-Alarme prüfen das p75 von LCP, INP, CLS, TTFB und FCP gegen einen festen Schwellwert. Schwellwert und Datenquelle (RUM/CrUX) stellst du je Instanz unabhängig ein; für RUM gelten voreingestellt mindestens 10 Samples je Stunden-Bucket und 1 Stunden-Bucket in Folge über der Schwelle. Zwei relative Alarme vergleichen das p75 mit deinem 28-Tage-Schnitt.
INP-Alarm (Pagespeedy)
Meldet, wenn das p75 der Interaction to Next Paint über dem Schwellwert liegt – wichtig auf interaktionsreichen Seiten wie Warenkorb und Checkout.
Voreinstellung: p75 über 200 ms, RUM und CrUX
CLS-Alarm (Pagespeedy)
Meldet, wenn das p75 des Cumulative Layout Shift über dem Schwellwert liegt. Er gehört zur empfohlenen Basis, wird ohne verbundenes Pagespeedy-Watch-Projekt aber nicht vorgeschlagen.
Voreinstellung: p75 über 0,1, RUM und CrUX
TTFB-Alarm (Pagespeedy)
Meldet, wenn das p75 der Time to First Byte über dem Schwellwert liegt. Er ergänzt den synthetisch messenden TTFB-Alarm im Bereich „TTFB & Performance“ um echte Nutzer- und CrUX-Felddaten.
Voreinstellung: p75 über 800 ms, RUM und CrUX
FCP-Alarm (Pagespeedy)
Meldet, wenn das p75 des First Contentful Paint über dem Schwellwert liegt – wenn es also zu lange dauert, bis überhaupt etwas auf der Seite erscheint.
Voreinstellung: p75 über 1.800 ms (1,8 s), RUM und CrUX
Akute Web-Vitals-Verschlechterung (Pagespeedy)
Vergleicht je Metrik das p75 der letzten 24 Stunden mit deinem 28-Tage-Schnitt, ausschließlich aus RUM-Daten. Der richtige Alarm für die Frage, ob dein letztes Deployment oder Plugin-Update die Seite langsamer gemacht hat.
Voreinstellung: mehr als 30 % über dem 28-Tage-Schnitt, mindestens 10 Samples je Vergleichsfenster
Schleichende Web-Vitals-Verschlechterung (Pagespeedy)
Vergleicht je Metrik das p75 der letzten 7 Tage mit dem 28-Tage-Schnitt und erkennt langsame Verschlechterung ohne klaren Sprung, etwa durch wachsende Bildgrößen oder immer mehr Third-Party-Skripte.
Voreinstellung: mehr als 15 % über dem 28-Tage-Schnitt, mindestens 10 Samples je Vergleichsfenster
Praxisbeispiele: So setzt du die Web-Vitals-Alarme ein
Mit dem LCP-Alarm anfangen
Er trifft die Metrik mit dem größten Ranking-Gewicht und schlägt bei den meisten Shops als erster an.
Veränderung statt Absolutwert
Interessiert dich weniger der absolute Wert als die Veränderung nach einem Deployment, nimm statt fester Schwellwerte die relativen Alarme: akute Verschlechterung (24 Stunden gegen 28 Tage) und schleichende Verschlechterung (7 Tage gegen 28 Tage).
Stille ist keine Entwarnung
Alle Alarme brauchen frische Daten. Liefert keine der aktivierten Quellen welche, bleibt der Alarmzustand unverändert – einen Alarm dafür, dass nichts ankommt, gibt es nicht.
Wenig Traffic, keine RUM-Werte
Ein Stunden-Bucket zählt für RUM erst ab „Mindest-Samples je Stunden-Bucket“, voreingestellt 10. Kleine Shops und Nachtstunden fallen damit regelmäßig heraus.
CrUX ist träge
Googles Felddaten decken 28 Tage ab und rücken nur langsam nach. Ein Deployment von heute Mittag steht dort noch lange nicht – dafür sind die RUM-Werte da.
Leere Statistik nach dem Aktivieren
Fehlen Shop-ID oder API-Key in den Projekteinstellungen, überspringt Monitorio das Projekt still: keine Fehlermeldung, keine Messwerte, keine Alarme. Bleibt die Statistik dauerhaft leer, sieh dort zuerst nach.
Ursachen in Pagespeedy Watch suchen
Die Werte sind so aktuell und so vollständig wie das, was Pagespeedy Watch liefert. Die Ursachenanalyse einer schlechten Metrik passiert dort, in Monitorio läuft die Überwachung.
Was du für die Web-Vitals-Überwachung brauchst
Die Überwachung braucht zwei Dinge: die zentrale Watch-Instanz, die Monitorio einmalig hinterlegt, und je Projekt Shop-ID und API-Key in den Projekteinstellungen – also ein verbundenes Pagespeedy-Watch-Projekt. Ein Monitorio-Plugin im Shop ist nicht nötig. Die Überwachung steht für Shopware-6-Projekte zur Verfügung; Verlauf und Einstellungen findest du im Projekt unter „Statistiken → Web Vitals (Pagespeedy)“.
Häufige Fragen
Was brauche ich, um Core Web Vitals mit Monitorio zu überwachen?
Ein verbundenes Pagespeedy-Watch-Projekt: Je Projekt hinterlegst du dafür Shop-ID und API-Key in den Projekteinstellungen, die zentrale Watch-Instanz hinterlegt Monitorio. Ein Monitorio-Plugin im Shop ist nicht nötig. Fehlt eine der Angaben, überspringt Monitorio das Projekt still – ohne Fehlermeldung, Messwerte und Alarme.
Misst Monitorio die Web Vitals selbst?
Nein. Die RUM-Werte entstehen bei echten Besuchern deines Shops und liegen in Pagespeedy Watch, die CrUX-Werte kommen von Google und beschreiben immer die letzten 28 Tage. Monitorio ruft die RUM-Daten im Standard alle 15 Minuten ab, die CrUX-Daten etwa einmal täglich, legt einen Verlauf an und alarmiert.
Welche Schwellwerte sind voreingestellt?
Für das p75: LCP 2.500 ms, INP 200 ms, CLS 0,1, FCP 1.800 ms und TTFB 800 ms. Die relativen Alarme melden voreingestellt, wenn das p75 mehr als 30 % (letzte 24 Stunden) beziehungsweise mehr als 15 % (letzte 7 Tage) über dem 28-Tage-Schnitt liegt.
Merke ich, wenn ein Deployment meinen Shop langsamer gemacht hat?
Dafür ist „Akute Web-Vitals-Verschlechterung (Pagespeedy)“ gedacht: Der Alarm vergleicht je Metrik das p75 der letzten 24 Stunden mit deinem 28-Tage-Schnitt, ausschließlich aus RUM-Daten. CrUX hilft hier nicht – ein Deployment von heute Mittag steht dort noch lange nicht.
Was passiert, wenn mein Shop wenig Traffic hat?
Für RUM zählt ein Stunden-Bucket erst ab 10 Samples (Voreinstellung), kleine Shops und Nachtstunden fallen damit regelmäßig heraus. Ohne frische Daten bleibt der Alarmzustand unverändert – es gibt keinen Alarm dafür, dass nichts ankommt.
Was unterscheidet den TTFB-Alarm (Pagespeedy) vom TTFB-Alarm im Bereich „TTFB & Performance“?
Der TTFB-Alarm im Bereich „TTFB & Performance“ misst synthetisch von einem eigenen Collector aus. Der TTFB-Alarm (Pagespeedy) nutzt echte Nutzer- und CrUX-Felddaten aus Pagespeedy Watch und ergänzt ihn damit.
Weitere Features
- JavaScript-Fehler Ein kleines Skript erfasst JavaScript-Fehler im Browser deiner Besucher – Alarm bei neuen Fehlern, auffälliger Fehlerrate und Fehlern, die zurückkehren.
- Bestell-Monitoring Einbrüche bei Bestellanzahl und Bestellwert erkennen – und Bestellungen, die zu lange in einer Kombination aus Bestell-, Zahlungs- und Lieferstatus hängen, auf Wunsch je Zahlungsart.
- Lagerbestand Bestandshistorie je Artikel – Alarm, wenn ausgewählte Artikel ihren Meldebestand erreichen oder insgesamt zu viele knapp werden.
- Message Queue Backlog der Shopware-Message-Queue im Blick – Alarm, wenn er zu lange über dem Limit liegt oder eine Queue nicht mehr abgearbeitet wird.
- Scheduled Tasks Meldet Scheduled Tasks von Shopware, die länger als erlaubt überfällig sind – voreingestellt nach einer Stunde.
- Shop-Log Holt Log-Einträge aus dem Shop und meldet Fehler ab dem gewählten Level sowie Log-Dateien, die zu groß werden oder zu schnell wachsen.
- SEO Meta Aktive Produkte und Kategorien ohne Meta-Title und Meta-Description – pro Sprache gezählt, als Liste mit CSV-Export und mit Alarm ab Schwellwert oder bei Anstieg.
- Google Search Console Klicks, Impressionen, Positionen und Indexierung aus der Search Console – Alarm bei Einbrüchen, noindex-Sprüngen oder 5xx-Fehlern.
- Product Feeds Prüft Feeds (XML/CSV) auf Erreichbarkeit und Lesbarkeit und meldet, wenn die Produktanzahl unter eine Mindestanzahl fällt oder stark vom letzten erfolgreichen Lauf abweicht.
Schluss mit Shop-Down-Calls um 3 Uhr morgens.
Nach 5 Minuten kommen die ersten Messwerte – und du schläfst wieder durch, während Monitorio die Shops im Auge behält.