Synthetisches Monitoring testet Ihre Website oder API nach Zeitplan mit skriptgesteuerten Anfragen – unabhängig davon, ob gerade jemand auf der Seite ist. Real User Monitoring (RUM) misst, was echte Besucher erleben, über ein Skript in deren Browser, aber eben nur, wenn sie die Seite besuchen. Synthetische Checks zeigen Ihnen, dass etwas kaputt ist, oft bevor Kunden es bemerken. RUM zeigt Ihnen, wie schnell und flüssig die Website für die Menschen ist, die sie nutzen – auf ihren Geräten und in ihren Netzen. Beginnen Sie mit synthetischen Checks für die Verfügbarkeit und ergänzen Sie RUM, sobald die Performance für echte Besucher eine Frage ist, auf die Sie eine Antwort brauchen.
So funktioniert synthetisches Monitoring
Ein Monitoring-Dienst übernimmt die Rolle des Besuchers. Von einem bekannten Standort aus und nach festem Zeitplan sendet er eine Anfrage oder führt ein Skript aus und bewertet das Ergebnis. Weil er jedes Mal dasselbe tut, sind die Ergebnisse von Check zu Check vergleichbar, und ein Fehler um 03:00 Uhr wird um 03:00 Uhr entdeckt – ganz ohne Traffic. Synthetisches Monitoring gibt es in mehreren Formen:
Uptime-Checks: eine Anfrage an eine URL, einen Host oder einen Port, geprüft auf Statuscode, Antwortzeit und oft auch den Inhalt. Das ist die einfachste Form; siehe was Uptime-Monitoring ist.
API-Checks: eine Anfrage mit Methode, Headern und Body sowie Prüfungen des zurückgegebenen JSON.
Mehrstufige Flows: ein Ablauf wie Login oder Checkout, Schritt für Schritt ausgeführt – als einfache HTTP-Anfragen oder in einem echten Browser, der JavaScript ausführt.
Performance-Tests im Labor: Ein Tool wie Lighthouse lädt eine Seite auf einem simulierten Gerät und Netz und bewertet sie.
So funktioniert Real User Monitoring
Real User Monitoring bindet ein Skript in Ihre Seiten ein. Im Browser jedes Besuchers liest es Zeitwerte aus, die Browser über Standard-APIs wie Navigation Timing bereitstellen, und sendet sie an einen Collector. Über viele Besuche zusammengefasst erhalten Sie Verteilungen: wie lange Seiten zum Laden brauchen, wie schnell sie auf Klicks reagieren, welche Seiten JavaScript-Fehler werfen – aufgeschlüsselt nach Land, Gerät und Browser.
Weil die Ergebnisse Verteilungen sind, gibt RUM Perzentile statt einzelner Zahlen an. Googles Core Web Vitals werden am 75. Perzentil der Seitenaufrufe gemessen, mit diesen Schwellenwerten für eine gute Nutzererfahrung:
Largest Contentful Paint (Laden): 2,5 Sekunden oder weniger.
Interaction to Next Paint (Reaktionsfähigkeit): 200 Millisekunden oder weniger.
Cumulative Layout Shift (visuelle Stabilität): 0,1 oder weniger.
Es gibt auch RUM-Daten, die Sie nicht selbst erheben. Googles Chrome UX Report (CrUX) veröffentlicht Felddaten von Chrome-Nutzern, die dem zustimmen, pro Seite und pro Website, sobald genug Traffic vorhanden ist. Auf diese Daten stützt sich Google bei den Core Web Vitals in der Suche.
Im direkten Vergleich
Synthetisches MonitoringReal User MonitoringWer die Daten erzeugtEin Monitoring-Dienst, nach ZeitplanIhre Besucher, wenn sie die Seite besuchenBraucht TrafficNeinJaBraucht ein Skript in Ihren SeitenNeinJaErkennt einen AusfallJa, beim nächsten CheckIndirekt, wenn keine Daten mehr kommenDeckt abDie Seiten und Abläufe, die Sie skriptenJede Seite, die Menschen besuchenGeräte und NetzeEinige wenige bekannteDie aller Ihrer BesucherErgebnisseBestanden oder fehlgeschlagen, ein Zeitwert pro CheckVerteilungen und PerzentileAm besten fürVerfügbarkeit, Alarme, Regressionen nach Deployments erkennenEchte Performance, Core Web Vitals, Fehler im Browser
Was beide übersehen
Blinde Flecken synthetischer Checks
Wege, die Sie nicht geskriptet haben. Testet der Checkout-Flow ein einzelnes Produkt, bleibt eine kaputte Seite in einer anderen Kategorie unbemerkt.
Wo Ihre Besucher sind. Ein Check aus einer Stadt sieht die Route dieser Stadt zu Ihrem Server, nicht die eines Besuchers im Mobilfunknetz auf einem anderen Kontinent.
Echte Geräte. Ein langsames Smartphone, eine Browsererweiterung oder eine alte Browserversion kann eine Seite lahmlegen oder ausbremsen, die jeden Check besteht.
Blinde Flecken von RUM
Keine Besucher, keine Daten. Nachts, auf einer neuen Seite oder bei einer Website mit wenig Traffic hat RUM wenig oder gar nichts zu sagen.
Ausfälle. Ist die Website down, lädt das Skript gar nicht erst, also wird nichts gemeldet. Eine Lücke im Diagramm übersieht man leicht, und sie weckt niemanden.
Besucher, die Sie nicht messen können. Werbeblocker und Einwilligungsentscheidungen können das Skript stoppen, sodass die Daten nur die Besucher beschreiben, die es zulassen.
Gewicht. Das Skript selbst bedeutet zusätzliche Arbeit für die Seite. Laden Sie es asynchron und prüfen Sie seine Größe.
Labordaten vs. Felddaten
Dieselbe Unterscheidung findet sich bei Performance-Tools, dort heißt sie Labor- und Felddaten. Ein Lighthouse-Score ist ein Labordatum: ein einzelner synthetischer Seitenaufruf auf einem simulierten Mittelklasse-Smartphone in einem simulierten Netz. CrUX und Ihr eigenes RUM sind Felddaten: das, was echte Besuche gemessen haben. Beide weichen oft voneinander ab. Eine Seite kann im Labor schlecht abschneiden und im Feld trotzdem die Core Web Vitals bestehen, weil die meisten Besucher schnelle Geräte haben – oder umgekehrt. Nutzen Sie Labordaten, um Probleme zu finden und zu beheben und ein Release mit dem nächsten zu vergleichen, und Felddaten, um zu beurteilen, was Besucher tatsächlich bekommen. Die Tipps für eine schneller ladende Website helfen bei beidem, und was eine gute Antwortzeit ist behandelt die Serverseite.
Womit Sie anfangen sollten
Jede Website: synthetische Uptime-Checks auf der Startseite und den Seiten, die Umsatz bringen. Ein Ausfall kostet mehr als eine langsame Seite, und nur synthetische Checks alarmieren Sie zuverlässig darüber. Die Checkliste, was Sie überwachen sollten, nennt die URLs, die sich lohnen.
Shops und SaaS-Produkte: Ergänzen Sie mehrstufige Flows für Checkout oder Login, damit ein kaputter Ablauf auch dann auffällt, wenn jede einzelne Seite mit 200 antwortet.
Websites, bei denen Suchtraffic zählt: Beobachten Sie die Core Web Vitals aus CrUX und einen täglichen Labortest, damit ein langsames Release auffällt, bevor es sich in den Rankings zeigt.
Große oder internationale Zielgruppen, komplexe Frontends: Ergänzen Sie RUM, um Performance und JavaScript-Fehler nach Land, Gerät und Seite zu sehen.
Wie beide zusammenspielen
Stellen Sie sich einen Shop vor, der am Dienstagnachmittag einen neuen Checkout ausrollt. Am Mittwoch um 03:12 Uhr beginnt der Zahlungsschritt in Timeouts zu laufen. Niemand kauft ein, also zeigt RUM nichts Ungewöhnliches – doch der synthetische Checkout-Flow schlägt fehl, ein zweiter Check bestätigt es, und der Entwickler in Rufbereitschaft bekommt einen Alarm. Um 03:30 Uhr ist es behoben. Am Donnerstag zeigt RUM, dass sich die Interaction to Next Paint im neuen Checkout für Android-Besucher verdoppelt hat – etwas, das kein synthetischer Check von einem schnellen Server aus bemerkt hätte. Das eine Tool hat den Ausfall erkannt, das andere die langsame Nutzererfahrung. Das ist die übliche Arbeitsteilung.
Was Uptimecheck abdeckt – und was nicht
Uptimecheck ist ein Dienst für synthetisches Monitoring. Es bindet kein RUM-Skript in Ihre Seiten ein; für die Zeitwerte und JavaScript-Fehler Ihrer eigenen Besucher nutzen Sie daneben ein spezialisiertes RUM-Tool. Das leistet Uptimecheck:
Uptime-Monitoring: HTTP(S)-, Ping- und Port-Checks bis zu jede Minute aus Stockholm, London und New York, mit Keyword-, JSON- und Header-Prüfungen; jeder Fehler wird vor einem Alarm von einem zweiten Standort bestätigt. Antwortzeiten werden in DNS, Verbindungsaufbau, TLS, Server und Download aufgeteilt.
Flow-Monitoring: bis zu 10 Schritte wie das Öffnen einer Seite, ein Login, das Absenden eines Formulars oder ein API-Aufruf, wobei Werte von einem Schritt in den nächsten übernommen werden. Flows mit einfachen Anfragen können jede Minute laufen; Flows in einem echten Browser führen JavaScript und Klicks aus und laufen höchstens alle 15 Minuten, mit einem Screenshot des fehlgeschlagenen Schritts.
Page-Speed-Monitoring: ein täglicher Lighthouse-Test für Mobil und Desktop für die Startseite und bis zu 4 weitere Seiten sowie – für Seiten und Websites mit genug Besuchen – das, was echte Chrome-Nutzer laut Chrome UX Report in den letzten 28 Tagen erlebt haben. Sie erhalten einen Alarm, wenn der Score einer Seite unter Ihren Grenzwert fällt.
Wie Sie einen Ablauf einrichten, lesen Sie unter Login oder Checkout mit einem Flow überwachen und Page Speed prüfen. Die Tarife beginnen bei 9 € pro Monat bei jährlicher Zahlung oder 12 € bei monatlicher Zahlung, zzgl. MwSt.; siehe die Preisseite.
Erfahren Sie von Störungen, bevor Ihre Besucher es Ihnen sagen. Testen Sie Uptimecheck 14 Tage kostenlos, ohne Kreditkarte.