Real User Monitoring: Website-Geschwindigkeit im Feld und Labor verstehen

Reale Nutzer und Lab-Tests

Real User Monitoring (RUM) erfasst, wie eine Website bei tatsächlichen Besuchen funktioniert. Ein Aufruf auf einem älteren Smartphone über Mobilfunk kann sich deutlich von einem Besuch am Desktop mit schneller Verbindung unterscheiden. Auch die genutzten Seiten und Interaktionen fließen in das beobachtete Bild ein.

Ein Lab-Test untersucht dagegen einen definierten Aufruf unter kontrollierten Bedingungen. Gerätetyp, Netzwerkbedingungen und Testablauf lassen sich für eine Untersuchung festlegen. Das erleichtert es, eine Auffälligkeit erneut hervorzurufen und mögliche Änderungen unter vergleichbaren Bedingungen zu prüfen.

Die beiden Sichtweisen beantworten unterschiedliche Fragen: Felddaten können zeigen, dass mobile Produktseiten häufig langsam erscheinen. Sie beweisen aber nicht, ob beispielsweise das Produktbild, der Renderpfad oder eine langsame Dokumentantwort dafür verantwortlich ist. Für die Ursachensuche braucht es zusätzliche Diagnosen und überprüfbare Hypothesen.

PageSpeed Insights verbindet beide Perspektiven: Es stellt verfügbare Felddaten aus dem Chrome User Experience Report Lab-Diagnosen auf Basis von Lighthouse gegenüber. Die Ergebnisse müssen nicht übereinstimmen, weil reale Besuche unterschiedliche Bedingungen und Nutzungsabläufe umfassen, während das Labor einen festgelegten Testfall betrachtet.

RUM ersetzt das Labor deshalb nicht. Umgekehrt kann ein einzelner Lab-Test nicht zeigen, wie häufig ein Problem bei tatsächlichen Besuchern auftritt. Vor einer Veröffentlichung oder bei einer kaum besuchten Website fehlen zudem möglicherweise ausreichende Felddaten; ohne reale Besuche entstehen überhaupt keine eigenen RUM-Messwerte.

So entstehen RUM-Messwerte

Eine eigene Messung braucht drei Bausteine: eine Erfassung im Browser, einen Empfänger für die übertragenen Werte und eine Auswertung. Vorab legst du fest, welche Seiten und Besuchergruppen du betrachten möchtest und wie die Daten geschützt werden. Erst aus sinnvoll zusammengefassten Einzelwerten wird eine Grundlage für Entscheidungen.

Browser stellen dafür verschiedene Performance-Schnittstellen bereit. Navigation Timing beschreibt Zeitpunkte rund um die Navigation zum Dokument, etwa die Antwort auf die Dokumentanfrage. Resource Timing liefert Zeitinformationen zu einzelnen geladenen Ressourcen, beispielsweise Bildern oder Skripten. So lassen sich unterschiedliche Abschnitte eines Ladevorgangs näher eingrenzen.

Ein PerformanceObserver beobachtet unterstützte Performance-Einträge, sobald sie verfügbar werden. Für Core Web Vitals kann die Bibliothek web-vitals die Berechnung und Meldung übernehmen. Welche Einträge und Kennzahlen verfügbar sind, hängt unter anderem vom Browser ab; ein Messskript erfasst daher nicht automatisch jeden Besuch vollständig.

Nicht jeder Wert entsteht direkt beim Laden. Für INP muss beispielsweise eine geeignete Interaktion stattfinden: Wer eine Seite nur liest und wieder verlässt, liefert dafür möglicherweise keinen Wert. Ein fehlender Messwert ist deshalb weder null noch ein Beleg für eine schnelle Reaktion.

Ein RUM-Dienst kann Erfassung, Empfang und Auswertung als Paket bereitstellen. Bei einer Eigenentwicklung musst du zusätzlich Betrieb, Speicherung und Qualitätssicherung organisieren. Dazu zählt auch, wiederholte Meldungen im Seitenlebenszyklus richtig zu behandeln, statt jede Meldung ungeprüft als unabhängigen Besuch zu zählen.

Core Web Vitals richtig lesen

Die Core Web Vitals beschreiben drei unterschiedliche Aspekte der Nutzererfahrung. Largest Contentful Paint (LCP) misst, wann das größte relevante Inhaltselement sichtbar wird. Auf einer Produktseite kann das etwa ein großes Produktbild sein: Erscheint es spät, wirkt die Seite trotz früher sichtbarer Navigation möglicherweise noch nicht fertig geladen.

Interaction to Next Paint (INP) betrachtet die Verzögerung von Interaktionen bis zur nächsten sichtbaren Aktualisierung. Reagiert ein Produktfilter erst spürbar nach einem Klick, kann INP auf dieses Problem hinweisen. Cumulative Layout Shift (CLS) beschreibt dagegen unerwartete Verschiebungen sichtbarer Inhalte, etwa wenn ein nachträglich eingeblendetes Element einen Button versetzt.

Für die Bewertung in PageSpeed Insights gilt ein LCP bis einschließlich 2,5 Sekunden, ein INP bis einschließlich 200 Millisekunden und ein CLS bis einschließlich 0,1 als gut. CLS ist ein einheitenloser Wert. Die Schwellen gelten für die jeweilige Kennzahl und sollten nicht mit der Dauer eines einzelnen Seitenaufrufs verwechselt werden.

Entscheidend für die Feldbewertung ist das 75. Perzentil (p75): Mindestens etwa 75 Prozent der berücksichtigten Erfahrungen liegen beim jeweiligen Wert nicht darüber. Ein guter Durchschnitt allein kann hingegen verdecken, dass ein beträchtlicher Teil der Besuche langsam ist. Betrachte Mobil und Desktop getrennt, damit Unterschiede zwischen den Gerätegruppen sichtbar bleiben.

Time to First Byte (TTFB) ergänzt diese Kennzahlen bei der Suche nach einer langsamen Dokumentantwort. Der Wert ist aber keine reine Server-Rechenzeit: Auch Netzwerk und weitere Stationen bis zum Eintreffen des ersten Antwortbytes wirken mit. Navigation Timing und gegebenenfalls bereitgestellte Server-Timing-Daten helfen, die beteiligten Abschnitte genauer zu untersuchen.

CrUX, eigenes RUM und Labor

Für den Einstieg musst du nicht sofort ein eigenes Messsystem betreiben. PageSpeed Insights verbindet Felddaten aus dem Chrome User Experience Report (CrUX) mit einer Lighthouse-Labordiagnose. Die beiden Ansichten beantworten unterschiedliche Fragen: Die eine beschreibt erfasste Erfahrungen, die andere untersucht eine Seite unter kontrollierten Bedingungen.

Die CrUX-Felddaten in PageSpeed Insights beschreiben ein zurückliegendes Fenster von 28 Tagen. Reichen die Daten für eine konkrete URL nicht aus, kann der Bericht stattdessen Daten der Origin anzeigen. Diese umfassen die zugehörige Website-Origin und sind nicht mit Erfahrungen genau auf der eingegebenen Seite gleichzusetzen. Achte deshalb darauf, welche Ebene der Bericht tatsächlich ausweist.

CrUX berücksichtigt nur Nutzer von Chrome, die die jeweiligen Voraussetzungen erfüllen; andere Browser und nicht berechtigte Nutzer fehlen. Auf einer kleinen oder nicht öffentlichen Website können CrUX-Daten fehlen. Eine eigene, rechtlich und technisch geeignete Erfassung kann dort dennoch Einblicke ermöglichen, bleibt bei wenigen Besuchen aber statistisch eingeschränkt.

Synthetisches Monitoring wiederholt definierte Prüfungen, auch wenn gerade niemand die Website besucht. Es eignet sich, um einen Ablauf regelmäßig unter ähnlichen Bedingungen zu beobachten. Ob Nutzer mit anderen Geräten oder Netzen dasselbe erleben, muss eine Feldmessung beantworten; ein einzelner synthetischer Ablauf ersetzt diese Sicht nicht.

Für die Auswahl zählt daher die Frage, die du beantworten möchtest: Ein öffentlicher Bericht ist schnell verfügbar, ein eigenes System erlaubt eine gezieltere Erfassung. Ein Dienst kann Betriebsarbeit abnehmen, während Labor und synthetische Prüfungen kontrollierte Untersuchungen ermöglichen. Auch ein Dienst benötigt aber eine bewusste Auswahl von Daten und Auswertungsgruppen.

Eigene Messung sicher vorbereiten

Lege zuerst eine konkrete Frage fest, etwa ob mobile Produktseiten häufiger einen hohen LCP aufweisen als andere Seitentypen. Bestimme dann, welche Seiten und Geräteklassen du unterscheiden willst, welche Metriken dafür nötig sind und wie lange du Daten sammeln möchtest. Erst danach entscheidest du über Messskript, Empfänger und Auswertung.

Für einen ersten technischen Schritt kannst du die Bibliothek web-vitals lokal in einem Browserprojekt einbinden und die Ausgabe in den Entwicklerwerkzeugen betrachten. Das folgende JavaScript verwendet die veröffentlichte Paketversion 6.2.3. Es setzt voraus, dass diese Version im Projekt installiert ist und der Build die Modulimporte verarbeitet. Das Beispiel sendet keine Daten an einen Server und aktiviert keine separate Messung von Soft Navigations.

import {onCLS, onINP, onLCP} from 'web-vitals';

onCLS(console.log);
onINP(console.log);
onLCP(console.log);

Die Konsolenausgabe ist eine Möglichkeit, die Einbindung zu prüfen, kein Nachweis für die Geschwindigkeit deiner Besucher. Öffne die Projektseite und interagiere beispielsweise mit einem Filter. Ein INP-Wert setzt eine geeignete Interaktion voraus und muss nicht sofort erscheinen; ohne passende Interaktion kann er ganz fehlen. Auch Browserunterstützung und Seitenlebenszyklus beeinflussen die Ausgabe.

Plane für eine spätere Auswertung den Seitenlebenszyklus ein: Rückmeldungen können mehrfach erfolgen, etwa wenn eine Seite verborgen und später wieder angezeigt wird. Zähle diese Meldungen nicht pauschal als unabhängige Besuche. Die Bibliothek stellt Metrik-IDs bereit, mit denen Meldungen derselben Metrik zugeordnet werden können.

Auch eine Wiederherstellung aus dem Back/Forward-Cache braucht eine definierte Behandlung. Sie kann eine neue Metrikmeldung auslösen, obwohl das Dokument aus dem Cache zurückkehrt. Lege fest, wie du solche Wiederherstellungen in deinem Bericht von gewöhnlichen Navigationen unterscheidest, und prüfe die konkreten Bibliothekshinweise, bevor du eine produktive Erfassung einrichtest.

Messwerte nach Segmenten auswerten

Ein Gesamtwert für den Shop kann verdecken, dass gerade mobile Produktseiten langsamer sind. Teile die Messwerte deshalb mindestens nach Seitentyp und Geräteklasse auf und betrachte für jede Metrik einen festgelegten Zeitraum. So vergleichst du beispielsweise mobile Produktseiten mit mobilen Kategorieseiten, statt unterschiedliche Nutzungssituationen unbemerkt zu vermischen.

Für jedes Segment ist das 75. Perzentil aussagekräftiger als ein bloßer Mittelwert: Es zeigt den Wert, den mindestens etwa 75 Prozent der berücksichtigten Erfahrungen nicht überschreiten. Ein niedriger Durchschnitt kann dagegen verdecken, dass eine relevante Gruppe lange wartet. Vergleiche p75 jeweils nur für dieselbe Metrik und mit passender Einheit.

Die Anzahl gültiger Werte gehört unmittelbar zum Ergebnis. Besteht ein Segment nur aus wenigen Messungen, können einzelne Erfahrungen das Perzentil stark beeinflussen; eine Veränderung muss dann nicht auf ein allgemeines Problem hindeuten. Wähle bei Bedarf einen längeren Zeitraum oder fasse fachlich ähnliche Seiten zusammen, ohne die Vergleichbarkeit zu verlieren.

Ein fehlender INP ist kein schneller INP und darf nicht als null in die Verteilung eingehen. Gib stattdessen die Zahl der gültigen INP-Werte getrennt an. Wenn viele Aufrufe keine geeignete Interaktion liefern, beschreibt die INP-Auswertung nur die erfassten Interaktionserfahrungen und nicht automatisch alle Seitenaufrufe.

Führe wiederholte Meldungen anhand der Metrik-ID sachgerecht zusammen, statt jede Rückmeldung als neue unabhängige Beobachtung zu behandeln. Dokumentiere außerdem, wie Wiederherstellungen aus dem Back/Forward-Cache gezählt werden. Damit bleibt nachvollziehbar, welche Beobachtungen im p75 und in der angegebenen Anzahl tatsächlich enthalten sind.

Vom Feldproblem zur Diagnose

Zeigen die Felddaten langsame mobile Produktseiten, grenze zunächst das betroffene Segment ein: Betrifft der schlechte LCP viele Produkte oder nur einen Seitentyp? Prüfe zugleich Zeitraum und Zahl gültiger Werte. So erhältst du einen Ansatzpunkt für die Untersuchung, aber noch keinen Beweis dafür, welches Element die Verzögerung verursacht.

Stelle anschließend im Lab-Test möglichst ähnliche Bedingungen nach, etwa mit einer mobilen Gerätekonfiguration und begrenzter Netzwerkgeschwindigkeit. Untersuche, welches Element als LCP erscheint und wann es geladen und dargestellt wird. Ein großes Produktbild, eine späte Bildanforderung oder ein blockierter Renderpfad sind mögliche Hypothesen, die du anhand der Diagnose prüfen musst.

Ergibt sich ein Hinweis auf die Auslieferung von Bildern, kannst du Dateigröße, Formate und Bereitstellung untersuchen. Ein Content-Delivery-Netzwerk ist eine mögliche Maßnahme, aber keine Garantie für einen besseren LCP. Deutet dagegen die Dokumentantwort auf einen Engpass hin, hilft ein ergänzender Server-Benchmark für PHP-Workloads, die Anwendung unter definierten Bedingungen zu untersuchen.

Bei einem verzögerten Produktfilter ist statt des Ladevorgangs die Interaktion entscheidend. Reproduziere einen Filterklick und prüfe, welche Arbeit bis zur sichtbaren Aktualisierung anfällt. Wo der Browser sie unterstützt, können Long Animation Frames Hinweise auf lange Rendering-Aktualisierungen und beteiligte Skripte liefern; sie erklären nicht automatisch jede langsame Interaktion.

Rolle eine gezielte Änderung aus und beobachte anschließend dieselbe Seitengruppe erneut im Feld. Ein besseres Laborergebnis zeigt zunächst nur die Wirkung unter den gewählten Testbedingungen. Erst die spätere Feldauswertung kann zeigen, ob sich auch die erfassten Erfahrungen realer Besucher verändert haben.

Datenqualität und Datenschutz im Betrieb

Lege vor dem produktiven Einsatz fest, welche Messwerte für deine Fragestellung nötig sind und wer sie verarbeitet. Zur Planung gehören eine sichere Übertragung zum Empfänger, Zugriffsbeschränkungen, eine begrenzte Aufbewahrungsdauer und ein Löschverfahren. Prüfe Datenschutz- und Einwilligungsfragen für die konkrete Implementierung und die geltenden Regeln fachlich, statt eine pauschale Freigabe anzunehmen.

Bei der Datenminimierung lohnt sich ein Blick auf Diagnosefelder: Vollständige URLs können in Query-Parametern sensible Informationen enthalten; auch DOM-Selektoren können Details über Seiteninhalte oder Eingaben verraten. Erfasse nach Möglichkeit einen allgemeinen Seitentyp und wenige gezielt ausgewählte Attribute. Prüfe ebenfalls, welche Angaben ein eingebundener Dienst zusätzlich erhebt oder speichert.

Messwerte stehen nicht immer sofort zur Verfügung. Die Bibliothek web-vitals kann Rückmeldungen im Verlauf des Seitenlebenszyklus mehrfach ausgeben; eine spätere Meldung darf deshalb nicht ohne Weiteres als neuer unabhängiger Besuch zählen. Plane, wie zusammengehörige Meldungen verarbeitet und Wiederherstellungen aus dem Back/Forward-Cache behandelt werden.

Für kleine Diagnosepakete kann eine Übertragung über sendBeacon beim Ereignis visibilitychange geeignet sein. Das verbessert die Möglichkeit, Daten beim Verbergen einer Seite anzustoßen, garantiert aber keine Zustellung. Der Empfänger muss außerdem die Daten sicher annehmen und so verarbeiten, dass wiederholte Meldungen nicht unbemerkt die Auswertung verfälschen.

Berücksichtige schließlich die Erfassungslücken: Blockierte Skripte, fehlende Browserunterstützung oder verlorene Übertragungen können dazu führen, dass bestimmte Besuche fehlen. Bewerte eine geschätzte Verlustquote zusammen mit der Art der Erfassung. Die verbleibenden Messwerte beschreiben die beobachtete Gruppe und müssen nicht alle Besucher gleichermaßen abbilden.

Veränderungen prüfen und Verfahren wählen

Für einen Vergleich nach einem Deployment legst du vorher fest, welche Seitentypen, Geräteklassen und Zeiträume betrachtet werden. Vergleiche für jede Metrik das 75. Perzentil und die Anzahl gültiger Werte vor und nach der Änderung. Ähnlich lange Zeitfenster helfen bei der Einordnung; ausreichend vergleichbare Stichproben entstehen dadurch aber nicht automatisch.

Achte auf einen veränderten Besuchermix. Wenn nach einem Deployment mehr Nutzer mit langsamen Mobilverbindungen kommen, kann sich der Gesamtwert verschlechtern, obwohl die Änderung selbst nicht langsamer ist. Auch saisonale Nutzung oder andere gleichzeitige Änderungen erschweren die Zuordnung. Ein zeitlicher Zusammenhang ist daher eine Hypothese, kein Kausalitätsnachweis.

CrUX und eigenes RUM müssen nicht dieselben Ergebnisse liefern: Sie können unterschiedliche Nutzergruppen, Zeitfenster und Erfassungsbedingungen abdecken. Bei CLS kommt hinzu, dass CrUX auch Beiträge eingebetteter Frames zur Erfahrung der übergeordneten Seite berücksichtigt. Eine JavaScript-Messung im Hauptdokument erfasst diese Beiträge nicht immer vollständig. Vergleiche deshalb zuerst die Messgrundlagen, bevor du eine Abweichung als Fehler wertest.

Bei einer Single-Page-Application solltest du festlegen, ob du Dokumentnavigationen oder interne Routenwechsel untersuchen willst. Für die separate Erfassung von Soft Navigations unterstützt web-vitals ab Version 6 bei passender Browserunterstützung die Option reportSoftNavs: true. Sie muss bei den jeweiligen Metrik-Callbacks gesetzt werden. Das vorherige Konsolenbeispiel ohne diese Option aktiviert keine separate Routenmessung.

Bei aktivierter Soft-Navigation-Erfassung werden CLS und INP für die neue Navigation zurückgesetzt und getrennt betrachtet; die Werte der vorherigen Navigation werden beim Routenwechsel abgeschlossen. Solche zeitlich anders abgegrenzten Werte solltest du nicht ungeprüft mit dokumentweiten Messungen vergleichen. Ohne passende Browserunterstützung führt die Option nicht zu einer entsprechenden separaten Routenmessung.

Für die Wahl eines RUM-Dienstes prüfst du neben der Browserabdeckung, ob die benötigten Seitengruppen und Geräteklassen auswertbar sind. Frage nach Stichprobenverfahren, Datenverarbeitung, Aufbewahrung und Exportmöglichkeiten. Ebenso wichtig ist, welche Auswirkungen das Messskript selbst auf die Seite haben kann und ob sich seine Erfassung auf das für deine Fragestellung Nötige begrenzen lässt.