Felddaten statt Laborwerte: echtes Shop-Tempo messen

Ein Shop kann im Testwerkzeug eine glatte Zahl anzeigen und trotzdem langsam sein - und umgekehrt. Der Grund ist selten ein Messfehler, sondern meist eine Verwechslung zweier Datenarten: Ein Laborlauf misst eine Seite unter festgelegten Bedingungen, Felddaten sammeln, was tatsächlich bei Besuchern ankommt. Beide Zahlen können richtig sein, sie beantworten nur verschiedene Fragen. Dieser Beitrag zeigt, wie die beiden Messarten entstehen, warum das 75. Perzentil im Feld die maßgebliche Kennzahl ist, welche Grenzen der öffentliche Chrome-Datensatz hat und in welcher Reihenfolge sich eigene Erhebung und PageSpeed-Optimierung verbinden lassen.

Labor und Feld messen nicht dasselbe

Ein Laborwert entsteht, indem eine Seite in einer kontrollierten Umgebung geladen wird: ein festgelegtes Gerät, eine festgelegte Netzverbindung, ein festgelegter Standort (web.dev). Ein Feldwert entsteht anders - er erfasst, was bei jedem einzelnen Besucher tatsächlich passiert ist, und setzt daraus eine Verteilung zusammen (web.dev). Der Unterschied klingt akademisch, entscheidet aber darüber, welche Aussage eine Zahl überhaupt tragen kann. Der Laborlauf ist wiederholbar und deshalb brauchbar, um zwei Stände derselben Seite zu vergleichen. Der Feldwert ist nicht wiederholbar, dafür beschreibt er die Wirklichkeit, in der Bestellungen entstehen oder ausbleiben. Wer die beiden gegeneinander ausspielt, verliert den Nutzen von beiden. Welche drei Kennzahlen dabei gemeint sind und wie sie zustande kommen, steht in der Übersicht zu Core Web Vitals.

Der wichtigste Satz über Felddaten wird am häufigsten überlesen: Sie sind keine einzelne Zahl, sondern eine Verteilung von Zahlen (web.dev). Auf derselben Produktseite lädt ein Besucher im Büro über Glasfaser in weniger als einer Sekunde, ein zweiter im Zug über eine schwankende Mobilverbindung in acht Sekunden, ein dritter kehrt zurück und bekommt die Seite aus dem Zwischenspeicher fast ohne Wartezeit. Alle drei Erfahrungen gehören zur selben Adresse. Ein Werkzeug, das daraus eine einzige Zahl macht, hat eine Stelle aus dieser Verteilung ausgewählt - und die eigentliche Frage lautet, welche. Genau hier beginnt die Verwirrung, die in Berichten regelmäßig als Widerspruch auftaucht: Zwei Werkzeuge nennen für dieselbe Seite unterschiedliche Zahlen, obwohl beide sauber gemessen haben.

The most important thing to understand about field data is that it is not just one number, it's a distribution of numbers.

Philip Walton, web.dev: Why lab and field data can be different

Für die Arbeit am Shop folgt daraus eine Aufgabenteilung. Der Laborlauf gehört in die Entwicklung: Er zeigt wiederholbar, ob eine Änderung ein Bild später lädt, ein Skript länger blockiert oder einen zusätzlichen Zeichensatz anfordert. Der Feldwert gehört in die Bewertung: Er sagt, ob die Änderung bei den Menschen ankommt, die tatsächlich bestellen. Eine hohe Punktzahl im Testwerkzeug ist deshalb kein Ergebnis, sondern ein Zwischenstand - wie sich das Streben nach vollen Punktzahlen im Alltag auswirkt, haben wir im Beitrag zu Lighthouse-Bestwerten in Shopware beschrieben. Umgekehrt ist ein schwacher Feldwert ohne Laborlauf schwer zu beheben, weil ihm die Wiederholbarkeit fehlt, die man zur Ursachensuche braucht.

Das 75. Perzentil ist kein Mittelwert

Werkzeuge, die Core Web Vitals aus dem Feld melden, werten dafür das 75. Perzentil aus (web.dev). Das ist weder ein Mittelwert noch ein Median: Es ist der Wert, den drei von vier Seitenaufrufen erreicht oder unterboten haben. Die Wahl ist begründet. Ein Median würde die Hälfte aller Besucher unberücksichtigt lassen, ein sehr hohes Perzentil würde von wenigen Ausreißern bestimmt - bei hundert Aufrufen genügen fünf Ausreißer, damit das 95. Perzentil kippt (web.dev). Das 75. Perzentil hält beides in der Waage: Die Mehrheit der Aufrufe ist abgedeckt, einzelne Störungen bestimmen das Ergebnis nicht. Diese Auswahl gilt für alle drei Kennzahlen gleichermaßen.

Aus dieser Konstruktion folgt eine Regel, die im Alltag oft fehlt: Eine Seite gilt als gut, wenn mindestens 75 Prozent der Aufrufe die gute Schwelle einhalten (web.dev). Ein einzelner sehr langsamer Aufruf ändert daran nichts, ein Viertel langsamer Aufrufe dagegen schon. Wer ein Ziel formuliert, sollte es deshalb an dieser Stelle formulieren - nicht als Wunsch nach einer schnellen Seite, sondern als Aussage über den Anteil der Aufrufe, der eine bestimmte Schwelle einhalten soll. Die Schwellen selbst und ihre Herleitung haben wir in der Einführung zu Core Web Vitals ausführlicher beschrieben.

Für einen Shop hat das eine praktische Folge. Die Verteilung ist selten symmetrisch: Die Masse der Aufrufe liegt links, ein langer Ausläufer nach rechts entsteht durch schwache Geräte, schlechte Verbindungen und kalte Zwischenspeicher. Wer den Durchschnitt betrachtet, sieht eine Zahl, die so kaum ein Besucher erlebt. Wer das 75. Perzentil betrachtet, sieht die Grenze, ab der es für ein Viertel der Aufrufe unangenehm wird - und das ist die Gruppe, in der Abbrüche entstehen. Deshalb lohnt es sich, die Verteilung selbst anzusehen und nicht nur die eine Zahl, die ein Werkzeug daraus ableitet.

• Wie viele Aufrufe hinter der Zahl stehen - bei kleiner Grundgesamtheit schwankt das Perzentil stark.
• Wie weit Handy und Rechner auseinanderliegen - beide Gruppen zusammenzuwerfen verdeckt in der Regel das Problem.
• Welche Seitentypen enthalten sind - Startseite, Kategorie, Produktseite und Kasse verhalten sich verschieden.
• Ob wiederkehrende Besucher enthalten sind - ein warmer Zwischenspeicher hebt das Ergebnis, ohne dass sich etwas verbessert hätte.
• Welcher Zeitraum ausgewertet wurde - eine Woche mit Aktion sieht anders aus als ein ruhiger Monat.

Was der öffentliche Chrome-Datensatz zeigt und was nicht

Die öffentlich verfügbare Feldquelle ist der Chrome User Experience Report. Er beruht auf einem gleitenden Fenster von 28 Tagen, und dieser Zeitraum lässt sich nicht verändern (web.dev). Wer eine Änderung am Montag ausliefert und am Freitag in den öffentlichen Daten nachsieht, betrachtet deshalb überwiegend die Zeit davor. Erst nach rund vier Wochen ist das Fenster vollständig mit dem neuen Stand gefüllt. Diese Trägheit ist kein Mangel, sondern die Bedingung dafür, dass die Zahl über Millionen Websites hinweg vergleichbar bleibt - sie macht die Quelle aber untauglich, um am Tag nach einer Auslieferung eine Wirkung zu belegen.

Dazu kommen Einschränkungen bei der Grundgesamtheit. Der Datensatz enthält ausschließlich Chrome-Nutzer (web.dev); Chrome auf iOS zählt nicht dazu, weil dort eine andere Darstellungsmaschine arbeitet, und Android-Anwendungen mit eingebetteter Ansicht ebenso wenig (Chrome UX Report). Erfasst werden zudem nur Nutzer, die der Übermittlung von Nutzungsstatistiken zugestimmt und ihren Verlauf synchronisiert haben (Chrome UX Report). Eine Seite muss außerdem öffentlich auffindbar und hinreichend häufig besucht sein, sonst erscheint sie gar nicht (Chrome UX Report). Für viele Shops heißt das: Es gibt Werte für die Domain, aber nicht für die einzelne Produktseite. Wer genauer werden will, kommt an eigener Erhebung nicht vorbei - wie das ohne Fremddienst geht, zeigt der Beitrag zu serverseitigem Tracking auf eigener Infrastruktur.

• Nur Chrome: andere Browser und Chrome auf iOS liefern nichts in den Datensatz (Chrome UX Report).
• Nur zugestimmte Nutzer: die Erfassung setzt eingeschaltete Nutzungsstatistik und synchronisierten Verlauf ohne eigenes Kennwort voraus (Chrome UX Report).
• Nur auffindbare Seiten: eine Adresse mit noindex oder einem anderen Statuscode als 200 fällt heraus (Chrome UX Report).
• Nur hinreichend besuchte Seiten: unterhalb einer nicht veröffentlichten Schwelle erscheint weder die Seite noch die Domain (Chrome UX Report).
• Parameter fallen weg: Abfrageparameter und Sprungmarken werden von der Adresse abgeschnitten, verschiedene Varianten landen zusammen (Chrome UX Report).
• Eingebettete Rahmen zählen zur Elternseite: ein Rahmen erscheint nicht getrennt, seine Layoutverschiebungen wirken aber auf die umgebende Seite (Chrome UX Report).

Die Feldzahlen aus dem Datensatz vom Juli 2025

Wie sieht das Feld aus? Im Datensatz vom Juli 2025, den der Web Almanac 2025 auswertet, bestehen 48 % der Websites auf dem Handy alle drei Core Web Vitals - nach 44 % im Jahr davor und 36 % zwei Jahre davor (Web Almanac 2025). Auf dem Rechner sind es 56 %, nach 55 % im Jahr davor; dort fiel der Zugewinn also gering aus (Web Almanac 2025). Der Abstand zwischen beiden Gerätearten hält sich hartnäckig und hat einen naheliegenden Grund: langsamere Netze und schwächere Geräte. Für einen Shop heißt das, dass eine Auswertung ohne Trennung nach Geräteart einen erheblichen Teil der Aussage verschenkt. Wo Ihr eigener Shop in dieser Verteilung steht, lässt sich mit einem Shop-Check einordnen.

Die Einzelkennzahlen zeigen dasselbe Muster deutlicher. Beim Largest Contentful Paint erreichen 74 % der Seiten auf dem Rechner einen guten Wert, auf dem Handy 62 %; der Anteil schlechter Erfahrungen liegt auf dem Handy mit 13 % bei fast dem Doppelten des Rechners mit 7 % (Web Almanac 2025). Das ist kein Randproblem: Wenn im Shop mehr als die Hälfte des Verkehrs vom Telefon kommt, entscheidet die Verteilung auf dem Handy über das Gesamtergebnis - und über den Umsatz, der an der schwächsten Stelle verloren geht.

Eine der aufschlussreichsten Zahlen betrifft den Seitentyp. Startseiten bestehen zu 47 % auf dem Rechner und zu 45 % auf dem Handy, Unterseiten dagegen zu 61 % und 56 % (Web Almanac 2025). Der Grund ist bekannt: Die Startseite trägt Bühnenbilder, Aktionsflächen und Einbindungen, die auf einer Produktseite fehlen. Für die Auswertung folgt daraus, dass ein einzelner Wert für die ganze Domain die Lage verzerrt - je nachdem, wie sich der Verkehr auf die Seitentypen verteilt. Zu einer sauberen Auswertung gehört außerdem, automatisierten Verkehr auszusortieren; wie sich Bots und Scraper erkennen und aussteuern lassen, beschreibt der Beitrag zu Bot-Traffic im Onlineshop.

Warum der Laborwert trotzdem gebraucht wird

Trotz aller Grenzen bleibt der Laborlauf notwendig, und die Zahlen zeigen auch, warum. Die Total Blocking Time, eine reine Laborkennzahl, liegt im Laborlauf des HTTP Archive vom Juli 2025 je Seite am 75. Perzentil auf dem Rechner bei 336 Millisekunden und auf dem Handy bei 4.193 Millisekunden (Web Almanac 2025). Der Medianwert auf dem Handy stieg dort auf 1.916 Millisekunden, ein Zuwachs von 58 % gegenüber 1.209 Millisekunden im Jahr davor (Web Almanac 2025). Gleichzeitig verbessert sich die Reaktionszeit im Feld. Dieser scheinbare Widerspruch ist erklärbar: Die Laborkennzahl misst die Blockade während des Ladens unter festgelegten Bedingungen, die Feldkennzahl misst die Reaktion in dem Moment, in dem ein Mensch tatsächlich tippt - und das tut er meist erst, wenn die Seite fertig aussieht. Die Laborkennzahl wird deshalb ausdrücklich als Näherung für die Reaktionszeit verwendet, die nur aus echten Nutzerdaten stammen kann (Web Almanac 2025).

Der zweite Grund ist praktischer Natur. Eine Änderung lässt sich nur dann verantworten, wenn ihre Wirkung vor der Auslieferung sichtbar wird, und dafür braucht es feste Bedingungen. Genau das leistet der Laborlauf: Gerät, Verbindung und Standort bleiben gleich, damit der Unterschied zwischen zwei Ständen auf die Änderung zurückfällt und nicht auf die Tageszeit im Mobilfunknetz. Voraussetzung ist eine Umgebung, die dem Produktivstand nahekommt, ohne Kundendaten zu enthalten - wie sich eine solche Umgebung aufsetzen lässt, beschreibt der Beitrag zu Staging mit Testdaten statt Kundendaten.

Warum die beiden Zahlen für dieselbe Seite auseinanderlaufen, lässt sich benennen. Im Labor wird regelmäßig dasselbe Element als größtes erkannt; im Feld hängt es von Bildschirmgröße, Anmeldung, laufenden Tests und den verfügbaren Schriften ab, welches Element das größte ist (web.dev). Der Laborlauf startet mit leerem Zwischenspeicher, während ein Teil der echten Besucher Teile der Seite bereits vorliegen hat (web.dev). Rücksprünge über die Verlaufsliste werden im Feld gezählt und sind nahezu verzögerungsfrei, im Labor kommen sie nicht vor (web.dev). Und die Beobachtung des größten Elements endet im Feld, sobald ein Mensch scrollt oder tippt, im Labor erst mit dem vollständigen Laden (web.dev). Jeder dieser Punkte verschiebt die Zahl in eine bestimmte Richtung - zusammengenommen erklären sie einen Großteil der Abweichungen, über die in Berichten gestritten wird.

Damit ergibt sich eine Arbeitsteilung, die sich in Projekten bewährt: Der Laborlauf läuft bei jeder Änderung und meldet Rückschritte, bevor sie live gehen. Die Felddaten laufen dauerhaft und entscheiden, woran als Nächstes gearbeitet wird. Wer beides zusammen mit der Erreichbarkeit beobachtet, erkennt außerdem, ob ein Einbruch am eigenen Code liegt oder an der Umgebung; wie ein solches Beobachtungssystem aufgebaut sein kann, zeigt der Beitrag zu Shop-Monitoring für Erreichbarkeit und Tempo.

Eigene Felddaten erheben, ohne Fremddienst

Eigene Felddaten zu erheben ist weniger Aufwand, als der Begriff vermuten lässt. Die Browser liefern die nötigen Ereignisse selbst; es braucht eine kleine Erfassung im Browser, eine Sammelstelle auf der eigenen Domain und eine Auswertung, die Perzentile rechnet. Kein Fremddienst und in der Regel kein zusätzliches Einwilligungsfenster, solange keine personenbezogenen Merkmale gespeichert werden. Wie sich Messdaten ohne Cookies auf eigener Infrastruktur sammeln lassen, ist im Beitrag zu serverseitigem Tracking beschrieben. Der entscheidende Unterschied zum öffentlichen Datensatz: Sie erfassen alle Browser, alle Seiten und jeden Zeitraum, den Sie brauchen.

// Felderfassung ohne Fremddienst: eigene Sammelstelle, eigene Auswertung
const puffer = [];

function melden(name, wert) {
  puffer.push({ name, wert: Math.round(wert), pfad: location.pathname });
}

// Größtes Inhaltselement: letzter Eintrag zählt
new PerformanceObserver((liste) => {
  const eintraege = liste.getEntries();
  melden('LCP', eintraege[eintraege.length - 1].startTime);
}).observe({ type: 'largest-contentful-paint', buffered: true });

// Layoutverschiebungen ohne kurz zuvor erfolgte Eingabe aufsummieren
let verschiebung = 0;
new PerformanceObserver((liste) => {
  for (const eintrag of liste.getEntries()) {
    if (!eintrag.hadRecentInput) verschiebung += eintrag.value;
  }
}).observe({ type: 'layout-shift', buffered: true });

// Langsamste Interaktion als Näherung für INP
let langsamste = 0;
new PerformanceObserver((liste) => {
  for (const eintrag of liste.getEntries()) {
    if (eintrag.interactionId && eintrag.duration > langsamste) {
      langsamste = eintrag.duration;
    }
  }
}).observe({ type: 'event', durationThreshold: 40, buffered: true });

// Erst beim Verlassen senden, damit der Wert vollständig ist
addEventListener('visibilitychange', () => {
  if (document.visibilityState !== 'hidden') return;
  melden('CLS', verschiebung * 1000); // in Tausendstel, damit ganzzahlig
  melden('INP', langsamste);
  navigator.sendBeacon('/api/feldwerte', JSON.stringify(puffer));
}, { once: true });

Beim Speichern zählt weniger die Menge als die Segmentierung. Ein Wert ohne Zusatzangaben ist kaum verwertbar; erst mit Seitentyp, Geräteart, Verbindungsklasse, Land und der Frage, ob es sich um einen ersten oder wiederkehrenden Besuch handelt, wird daraus eine Grundlage für Entscheidungen. Ebenso wichtig ist die Anzahl: Perzentile aus wenigen hundert Aufrufen schwanken so stark, dass sie eher in die Irre führen als helfen. Wer eine Stichprobe zieht, sollte die Quote festhalten und beim Vergleich berücksichtigen, sonst entsteht aus einer Änderung an der Erfassung ein scheinbarer Fortschritt. Für den Einbau in eine bestehende Anwendung greifen wir auf die eigene Entwicklung zurück.

• Kennzahl und Wert, in ganzen Millisekunden oder Tausendsteln
• Seitentyp: Startseite, Kategorie, Produktseite, Warenkorb, Kasse
• Geräteart und Bildschirmbreite zum Zeitpunkt des Aufrufs
• Erster oder wiederkehrender Besuch, damit warme Zwischenspeicher sichtbar bleiben
• Herkunft des Aufrufs, getrennt nach Suche, Anzeige, Verweis und Direkteingabe
• Datum und Stunde, damit sich Aktionszeiträume herausrechnen lassen

Vom Messwert zur Entscheidung

Aus Messwerten wird erst dann eine Entscheidung, wenn die Reihenfolge feststeht. Sie ergibt sich nicht aus der Größe des Rückstands allein, sondern aus dem Zusammenspiel von Rückstand und Gewicht: Eine Kategorieseite mit einem Viertel des Verkehrs wiegt schwerer als eine Randseite mit demselben Rückstand. Die folgende Reihenfolge hat sich in Projekten bewährt und lässt sich in einem Nachmittag aufsetzen.

1. Verkehr je Seitentyp erheben und die drei Seitentypen bestimmen, die zusammen den größten Teil der Aufrufe tragen.
2. Für diese Seitentypen die Verteilung ansehen, getrennt nach Handy und Rechner, und das 75. Perzentil notieren.
3. Den Abstand zur guten Schwelle je Kennzahl bestimmen und mit dem Anteil am Verkehr gewichten.
4. Die größte gewichtete Lücke im Labor nachstellen, bis die Ursache wiederholbar auftritt.
5. Die Änderung ausliefern und den Laborwert davor und danach festhalten.
6. Nach vier vollen Wochen die Feldverteilung erneut auswerten und das Ergebnis gegen die Erwartung halten.

Bei der Reaktionszeit lohnt ein eigener Blick, weil sie sich anders verhält als der Ladeeindruck: Sie entsteht nicht beim Laden, sondern beim Tippen, und trifft damit vor allem Filter, Warenkorb und Kasse. Ein Shop kann beim Ladeeindruck gut dastehen und trotzdem an der Kasse zäh wirken. Wo die Ursachen liegen und welche Eingriffe sich erfahrungsgemäß lohnen, haben wir im Beitrag zur Verbesserung der Reaktionszeit zusammengetragen.

Was das im Shop-Alltag bedeutet

Im Shop-Alltag zeigt sich der Unterschied an drei Stellen besonders deutlich. Erstens bei Aktionen: Eine Kampagne bringt Verkehr von Geräten und aus Netzen, die sonst kaum vorkommen; die Feldverteilung wird breiter, ohne dass sich an der Seite etwas geändert hätte. Zweitens bei Erweiterungen: Ein zusätzliches Modul im Seitenkopf verschiebt den Laborwert um wenige Punkte und die Feldverteilung um deutlich mehr, weil es auf schwachen Geräten stärker wirkt. Drittens bei Umbauten am Katalog: Eine neue Filterlogik kann den Ladeeindruck unberührt lassen und trotzdem die Reaktionszeit verschlechtern. Wer solche Eingriffe plant, sollte die Erfassung vorher aufsetzen - unsere Shopware-Entwicklung richtet sie im Rahmen des Projekts mit ein.

Ein Teil der Streuung entsteht nicht im Code, sondern in der Umgebung. Antwortzeiten des Servers, Zwischenspeicher, Bildauslieferung und die Anbindung wirken sich unmittelbar auf den ersten sichtbaren Inhalt aus und damit auf die gesamte Verteilung. Diese Anteile lassen sich mit Laborläufen schlecht beurteilen, weil die Bedingungen dort entweder ideal oder künstlich gedrosselt sind. In der Betreuung sehen wir sie deshalb über Felddaten und Serverprotokolle gemeinsam an; was dazugehört, steht auf der Seite zu Hosting und Betrieb.

Bleibt die Frage, welche Zahl in den Bericht an die Geschäftsführung gehört. Erfahrungsgemäß trägt eine einzelne Punktzahl dort selten weit: Sie schwankt, sie lässt sich nicht auf Umsatz beziehen und sie provoziert die Rückfrage nach der vollen Punktzahl. Belastbarer ist eine Aussage über Anteile - wie viele Aufrufe auf den umsatzstärksten Seitentypen die gute Schwelle einhalten, getrennt nach Handy und Rechner, mit Stichtag und Anzahl. Diese Form überlebt den nächsten Werkzeugwechsel, weil sie nicht an ein Werkzeug gebunden ist, sondern an die Verteilung selbst.

So gehen wir dabei vor

Wir beginnen mit einer Bestandsaufnahme: Welche Feldquellen liegen vor, wie ist die Erfassung eingebaut, welche Seitentypen tragen den Verkehr. Danach richten wir die eigene Erhebung auf Ihrer Infrastruktur ein, prüfen sie gegen den öffentlichen Datensatz auf Plausibilität und legen die Auswertung nach Segmenten an. Auf dieser Grundlage entsteht die Reihenfolge der Arbeiten, jeweils mit Laborwert vor und nach der Änderung und einer Nachmessung im Feld nach vier vollen Wochen. Wenn Sie wissen möchten, wie Ihr Shop im Feld tatsächlich dasteht, sprechen Sie uns an.