Performance richtig messen: Feld- und Labordaten trennen

Cookbook: Ziel und Ergebnis

Am Ende besitzt du eine wiederholbare Baseline für repräsentative Seitentypen. Laborwerte dienen der Ursachenanalyse; Felddaten beantworten, was echte Besucher am 75. Perzentil erleben. Ein Score allein ist kein Ziel.

Rezept: Schritt für Schritt

1. Lege je eine URL für Startseite, Artikel, schwere Landingpage und – falls vorhanden – Produkt, Warenkorb sowie eingeloggte Ansicht fest.
2. Notiere Testregion, Gerät, Netzwerkprofil, Browser, Login- und Cache-Zustand. Ändert sich eine Bedingung, ist der Vergleich nicht sauber.
3. Führe pro URL mindestens fünf Labormessungen kalt und fünf warm aus. Verwende den Median; notiere zusätzlich Minimum und Maximum als Streuung.
4. Ändere genau einen Faktor. Wiederhole dieselbe Messreihe und prüfe anschließend reale Felddaten über mindestens einen vollständigen 28-Tage-Zeitraum.

Rechenweg oder Entscheidungsregel

Median-Gewinn (%) = (Median vorher − Median nachher) / Median vorher × 100\nStreuung (%) = (Maximum − Minimum) / Median × 100

Ein Gewinn sollte größer als die normale Streuung sein. Liegt die TTFB beispielsweise zwischen 280 und 520 ms, ist eine einzelne Messung mit 30 ms Verbesserung kein Beleg.

Praxisbeispiel

Fünf LCP-Werte vor der Änderung: 3,1 / 2,8 / 3,0 / 3,5 / 2,9 s; Median 3,0 s. Danach: 2,5 / 2,6 / 2,4 / 2,7 / 2,5 s; Median 2,5 s. Der Laborgewinn beträgt 16,7 %. Erst wenn Funktionen stabil bleiben und CrUX später dieselbe Richtung zeigt, gilt die Maßnahme als bestätigt.

Prüfen, ob es funktioniert

• LCP, INP und CLS getrennt für Mobil und Desktop am P75 betrachten.
• HTML-TTFB, LCP-Ressourcenzeit und Main-Thread-Arbeit getrennt notieren.
• Fehlerrate, Serverlast, Formulare, Login und Shop-Pfade neben der Geschwindigkeit testen.

Rollback

Die geänderte Einstellung oder Datei auf den dokumentierten Ausgangswert zurücksetzen, Caches kontrolliert leeren und dieselbe Messreihe wiederholen. Messdaten selbst werden nie überschrieben, sondern als neuer Lauf abgelegt.

Das Problem

Ein einzelner Lighthouse-Lauf ist keine Nutzerstatistik. Labortests simulieren kontrollierte Bedingungen und helfen beim Debugging; Felddaten wie CrUX zeigen reale Besuche über einen längeren Zeitraum. Cache-Zustand, Gerät, Netz, Region und eingeloggter Status verändern Ergebnisse.

Empfehlung

Lege vor jeder Änderung eine Baseline für Startseite, einen typischen Artikel, eine schwere Landingpage und – falls vorhanden – Shop, Suche und eingeloggte Ansicht an. Nutze mindestens drei Labordurchläufe je URL und notiere den Median. Prüfe Feldwerte am 75. Perzentil getrennt für Mobil und Desktop.

So gehst du vor

1. Erfasse LCP, INP und CLS aus Felddaten, sofern genügend Daten vorhanden sind.
2. Nutze Lighthouse oder DevTools, um Ursachen wie TTFB, Ressourcenketten und lange JavaScript-Aufgaben zu finden.
3. Ändere genau eine Maßnahme und teste kalt sowie warm erneut.
4. Behalte Funktionsprüfungen und Serverlast neben dem Score im Blick.

Erfolgskontrolle

Eine Verbesserung gilt erst als belastbar, wenn sie wiederholt messbar ist, keine Regression auf anderen Seitentypen erzeugt und sich später in Felddaten bestätigt. Gute Zielwerte sind LCP ≤ 2,5 s, INP ≤ 200 ms und CLS ≤ 0,1 für mindestens 75 % der Besuche.

Quellen und Prüfstand

• Google: Core Web Vitals mit Werkzeugen messen
• Google: Largest Contentful Paint

Inhalt fachlich geprüft am 17. August 2026. Konkrete Werte sind Ausgangspunkte, keine Universaldosierung.