Lighthouse nicht ins Lastenheft Abgenommen wird gegen Felddaten im 75. Perzentil je Seitentyp, nicht gegen einen Punktwert aus dem Labor

Von Christian Schreiber, Web Performance Consultant für AEM und Magnolia, veröffentlicht am 10. November 2026

In Lastenheften und Abnahmen begegnet mir als Performance-Anforderung häufig ein Lighthouse-Punktwert, etwa „mindestens 90 auf Mobilgeräten“. Ich halte das für einen Fehler. Der Punktwert misst etwas anderes als die Bewertung, nach der Google und die Besucher urteilen, und er lässt sich erreichen, ohne dass sich die Erfahrung echter Nutzer verbessert. In ein Lastenheft und in eine Abnahme gehören Felddaten: das 75. Perzentil je Seitentyp, getrennt nach Mobilgeräten und Desktop.

Lighthouse ist ein gutes Diagnosewerkzeug, und an dieser Stelle hat es seinen Platz. Mein Einwand gilt nur seiner Verwendung als Zielwert. Die Gründe sind dokumentiert, teils bei Google selbst, teils im eigenen Core Web Vitals Benchmark 2026.

Lighthouse-Punktwert gewichtet anders als Googles Bewertung der Core Web Vitals

Der Performance-Punktwert von Lighthouse ist ein gewichteter Durchschnitt aus fünf Labormesswerten. Nach der Dokumentation von Google zählen Total Blocking Time mit 30 Prozent, Largest Contentful Paint und Cumulative Layout Shift mit je 25 Prozent sowie First Contentful Paint und Speed Index mit je 10 Prozent (Lighthouse performance scoring).

Googles Bewertung der Core Web Vitals kennt keinen Durchschnitt, sondern drei Schwellen: Largest Contentful Paint bis 2,5 Sekunden, Interaction to Next Paint bis 200 Millisekunden, Cumulative Layout Shift bis 0,1, jeweils im 75. Perzentil der Besuche (web.dev). Bestanden ist eine Seite nur, wenn sie alle drei Schwellen einhält. Daraus folgen drei Unterschiede:

• Die Hälfte des Punktwerts entfällt auf Kennzahlen, die nicht zu den Core Web Vitals gehören: Total Blocking Time, First Contentful Paint und Speed Index.
• Interaction to Next Paint fehlt ganz, weil eine Labormessung ohne Interaktion sie nicht erfassen kann. Total Blocking Time ist dafür nur eine Näherung (web.dev zu TBT).
• Im Durchschnitt gleicht ein sehr guter Wert einen schlechten aus. In Googles Bewertung fällt eine Seite mit zu langsamem Largest Contentful Paint durch, egal wie stabil ihr Layout ist.

Wie schwer die fehlende Reaktionszeit wiegt, zeigt der AEM Core Web Vitals Benchmark: Von den 127 Auftritten, die im eigenen Abruf durchfallen, verfehlen 47,2 Prozent die Schwelle für Interaction to Next Paint, also genau die Kennzahl, die im Lighthouse-Punktwert nicht vorkommt.

Labormessung ohne Einwilligung und Interaktion: Der Punktwert sieht die Produktion nicht

Lighthouse misst einen einzelnen Seitenaufruf unter festen Bedingungen. Für Mobilgeräte simuliert es in der Standardeinstellung ein Moto G Power mit gedrosselter Verbindung und vierfach verlangsamtem Prozessor (Lighthouse-Konfiguration). Was dabei fehlt, ist genau das, was auf Enterprise-Plattformen die Werte bestimmt:

• Einwilligung: Im Labor stimmt niemand im Einwilligungsdialog zu. Tags, die erst danach laden, etwa Analytik, Testwerkzeuge und Personalisierung, fehlen in der Messung.
• Interaktion: Niemand klickt, tippt oder öffnet ein Menü. Die Reaktionszeit bleibt unsichtbar.
• Vielfalt: Echte Besucher kommen mit unterschiedlichen Geräten, Verbindungen, Caches und Einstiegsseiten. Das 75. Perzentil bildet diese Streuung ab, ein einzelner Lauf nicht.

Dazu kommt die Streuung zwischen zwei Läufen. Das Lighthouse-Team beschreibt selbst, dass der Punktwert auch ohne Änderung am Code schwankt, und empfiehlt den Median aus mehreren Läufen (Lighthouse Variability). Ein Abnahmekriterium, das bei zwei Messungen derselben Version zu zwei Ergebnissen führen kann, erzeugt Diskussionen statt Klarheit. Warum Labor- und Felddaten auseinanderliegen, erklärt Google unter Why lab and field data can be different.

Edge Delivery Services: 100 Lighthouse-Punkte vor dem Livegang legen die Feldwerte nicht fest

Am deutlichsten wird der Unterschied bei Adobes Edge Delivery Services. Adobe beschreibt unter Keeping it 100, wie Projekte einen Lighthouse-Wert von 100 halten, und nennt in der Go-live-Checkliste 100 Punkte für Mobilgeräte und Desktop als Ziel. Die Architektur ist tatsächlich schlank, und ich halte sie für eine gute Ausgangsbasis.

Im Feld zeigt der Benchmark ein nüchterneres Bild. In den Daten des HTTP Archive bestehen 54,0 Prozent der 87 erfassten Auftritte mit Edge Delivery Services die Core Web Vitals auf Smartphones. Im eigenen Abruf sind es 45,1 Prozent von 51 Auftritten, bei einer Antwortzeit des Servers von 782 Millisekunden im Median. Beide Gruppen sind klein.

Ob diese Auftritte zum Livegang 100 Punkte hatten, zeigt der Benchmark nicht. Er zeigt aber, dass die Plattform allein das Ergebnis im Feld nicht festlegt: Tag-Manager, Einwilligungsdialog und Personalisierung kommen nach dem Livegang hinzu und gehen in den Laborwert einer Vorschau nicht ein. Mehr dazu steht unter AEM Edge Delivery Services.

Abnahme gegen Felddaten: 75. Perzentil je Seitentyp, mobil, über 28 Tage

Was stattdessen ins Lastenheft gehört, passt in einen Satz: Für die Seitentypen Startseite, Übersichtsseite, Detailseite und Formular gelten auf Mobilgeräten im 75. Perzentil der Felddaten über 28 Tage Zielwerte für Largest Contentful Paint, Interaction to Next Paint und Cumulative Layout Shift. Ausgangspunkt sind die Grenzwerte von Google, für umsatzstarke Seitentypen können strengere Werte sinnvoll sein. Vollständige Formulierungen enthalten die Vorlagen Performance-Anforderungen im AEM-Lastenheft und Performance-Anforderungen im Magnolia-Lastenheft.

Drei Festlegungen machen diese Anforderung abnehmbar:

• Je Seitentyp statt je Domain: Ein Mittelwert über die Domain verdeckt die Seitentypen, an denen es klemmt.
• Quelle benannt: Ein Real User Monitoring liefert Werte je Seitentyp, der Chrome User Experience Report ergänzt sie für ausreichend besuchte Adressen. Welche Werkzeuge welche Quelle nutzen, steht unter Core Web Vitals messen.
• Labor als Vorabprüfung: Vor dem Livegang prüft eine Labormessung unter festgelegten Bedingungen, ob eine Änderung in die richtige Richtung wirkt. Sie entscheidet über den Merge, nicht über die Abnahme.

Ticket-Vorlagen mit dieser Aufteilung stehen unter Core Web Vitals Abnahmekriterien.

Einwände gegen Felddaten: Verzögerung und Verständlichkeit lassen sich lösen

Zwei Einwände höre ich regelmäßig. Der erste: Felddaten kommen zu spät, weil Google 28 Tage sammelt. Für den Chrome User Experience Report stimmt das. Deshalb hat die Abnahme zwei Stufen, die Vorabprüfung im Labor vor dem Livegang und den Nachweis im Feld danach. Ein Real User Monitoring verkürzt die zweite Stufe deutlich, weil es täglich auswertet.

Der zweite: Ein Punktwert ist leichter zu verstehen als drei Perzentile je Seitentyp. Auch das stimmt. Eine Anforderung, die leicht zu verstehen ist und das Falsche misst, schützt aber weder den Betreiber noch die Agentur. Eine Agentur, die 95 Punkte liefert, während die Felddaten durchfallen, hat das Lastenheft erfüllt und das Ziel verfehlt. Diesen Konflikt verhindert nur ein Kriterium, das mit Googles Bewertung übereinstimmt.

Kostenfreie Performance-Erstanalyse buchen

30 Minuten per Video. Sie erhalten die Google-Nutzerdaten Ihrer Plattform im Vergleich zu zwei Wettbewerbern, unabhängig davon, ob wir zusammenarbeiten.

Häufige Fragen zu Lighthouse und Felddaten in der Abnahme