Lighthouse vs. Field Data: Prüfe, ob dein Fix funktioniert hat

Lighthouse sagt, es ist behoben. Warum ist die Search Console noch rot?

Lighthouse lädt deine Seite einmal auf einem simulierten Smartphone und meldet LCP und CLS für diesen Aufruf. Deine Core Web Vitals sind Field Data: das 75. Perzentil aus 28 Tagen echter Chrome-Besuche – auf schnellen und langsamen Smartphones und Netzen, mit leerem und vollem Cache, inklusive jedem Klick. Ein Fix kann heute in Lighthouse bestehen und vier Wochen brauchen, bis er in der Search Console auftaucht. Vergleiche drei Lighthouse-Durchläufe und beobachte dann deine Field Data.

Wie führst du Lighthouse aus, um Vorher und Nachher zu vergleichen?

Führe Lighthouse vor und nach der Änderung genau gleich aus:

1. Leere die Caches. Leere nach der Änderung den Cache deines Caching-Plugins und deines CDN, sonst testet Lighthouse die alte Seite.
2. Wähle ein Tool und bleib dabei. Ohne Code: PageSpeed Insights auf dem Tab „Mobilgerät“. Als Entwickler: das Lighthouse-Panel in den Chrome DevTools mit Device auf „Mobile“. Nutze ein Inkognito-Fenster, weil Browser-Erweiterungen eigene Skripte in die Seite laden.
3. Teste die URL mit der Meldung. War die Änderung im Produkt-Template, teste eine Produktseite.
4. Lass es dreimal laufen und nimm das mittlere Ergebnis.
5. Schau zuerst auf die Meldung und die Metrik. Die Meldung wandert zu „Passed audits“, und die betroffene Metrik (LCP, CLS, Total Blocking Time) sinkt. Der Score kommt zuletzt.

Warum ändert sich der Score, wenn sich nichts geändert hat?

Jeder Durchlauf ist ein einzelner Ladevorgang, und kein Ladevorgang gleicht dem anderen: Der Server antwortet schneller oder langsamer, das Netzwerk schwankt, und Ads, Consent-Banner oder A/B-Tests unterscheiden sich von Durchlauf zu Durchlauf. Auf einer meiner Testseiten erschien der erste Text oder das erste Bild (FCP) in einem Durchlauf 1,5 s früher als in einem anderen. Auf einer zweiten Seite lag der Score bei 96 oder 80 – ohne jede Änderung. Ein paar Punkte mehr nach einem Fix sagen wenig aus, solange du nicht das mittlere von drei Ergebnissen vergleichst.

Sechs Durchläufe in Folge auf derselben URL, www.bbc.com, brachten innerhalb von zwei Minuten 38, 44, 41, 73, 60 und 53. Lighthouse 13.5.0, Mobile, simuliertes Throttling wie in PageSpeed Insights.

Einen Trace in den DevTools aufzeichnen

Öffne die Seite in Chrome, öffne die DevTools und wechsle ins Performance-Panel. Stelle in den Capture settings (Zahnrad-Symbol) Network auf „Slow 4G“ und CPU auf „4x slowdown“ – das kommt dem nahe, was Lighthouse auf Mobilgeräten simuliert. Klicke dann auf Record und lade neu. Der Tab „Insights“ in der Seitenleiste listet dieselben Insights wie Lighthouse, jeweils mit den Requests und Elementen dahinter. Vor der Aufnahme zeigt das Panel deine eigenen Werte für LCP, CLS und INP live (INP, sobald du in die Seite klickst). Klicke unter „Field metrics“ auf „Set up“, und das Panel stellt die CrUX-Zahlen deiner echten Besucher für dieselbe URL direkt daneben.

Warum sagt Lighthouse das eine und die Search Console das andere?

Lighthouse liefert dir Lab Data: ein einzelner Ladevorgang deiner Seite auf einem simulierten Mittelklasse-Smartphone über eine langsame 4G-Verbindung mit leerem Cache. Der Test stoppt kurz nach dem Laden – er scrollt nie, tippt nicht und öffnet keine zweite Seite. Du bekommst LCP und CLS für diesen einen Ladevorgang und kein INP, weil INP einen Besucher braucht, der klickt.

Field Data ist das, was Chrome bei deinen echten Besuchern gemessen hat: schnelle und langsame Smartphones, gute und schlechte Netze, ein erster Besuch mit leerem Cache und der zehnte mit vollem Cache, Scrollen, Tippen, der Wechsel von Seite zu Seite. Google sammelt diese Daten im Chrome UX Report (CrUX) von Chrome-Nutzern auf Android und Desktop, die Nutzungsstatistiken teilen. Deine Core Web Vitals basieren auf diesen Besuchen der letzten 28 Tage, pro Metrik beim 75. Perzentil (p75): Drei von vier Besuchen waren mindestens so gut.

Google rankt auf Basis der Field Data. Mit Lighthouse findest du heraus, warum eine Seite langsam ist und ob eine Änderung hilft. Stimmen beide nicht überein, haben sie unterschiedliche Ladevorgänge gemessen. Ein grüner Lighthouse-Score bei schlechten Field Data bedeutet oft: Smartphones, die langsamer sind als die Simulation, träge Reaktionen auf Klicks (INP) oder Inhalte, die sich beim Scrollen verschieben. Ein roter Score bei guten Field Data bedeutet oft: Deine Besucher haben schnellere Smartphones und bessere Netze als das simulierte Slow 4G von Lighthouse – und sie kehren mit deinen Dateien im Cache zurück.

Ein PageSpeed-Insights-Bericht für www.bbc.com auf Mobile vom 26. Oktober 2026. Die echten Besuche bestehen alle drei Core Web Vitals mit einem LCP von 1,2 s; der Lighthouse-Durchlauf im selben Bericht kommt auf einen Score von 37 mit einem LCP von 9,5 s.

Hat die getestete URL genug Besuche, zeigt PageSpeed Insights die Field Data für diese URL. Reichen die Besuche nicht aus, zeigt das Tool die Daten für die gesamte Website unter „Origin“. Die Search Console fasst ähnliche URLs in Gruppen zusammen und bewertet jede Gruppe nach ihrer schlechtesten Metrik.

Wo siehst du, was deine Besucher erleben?

Vier kostenlose Tools zeigen CrUX – die Field Data, die Google nutzt:

• PageSpeed Insights: der obere Bereich „Discover what your real users are experiencing“ mit LCP, INP und CLS beim p75 der letzten 28 Tage, für die URL oder den Origin.
• Search Console: Der Core-Web-Vitals-Bericht für Mobile und Desktop zeigt, welche Gruppen ähnlicher URLs auf der gesamten Website schlecht abschneiden.
• CrUX-History-Report: ein Balken pro Woche für deine Website oder eine URL, damit du den Trend siehst.
• DevTools: Das Performance-Panel stellt dieselben Zahlen neben deinen eigenen Ladevorgang (einmalig einrichten).

Hat eine Website zu wenige Chrome-Besuche, fehlen die CrUX-Daten: PageSpeed Insights zeigt im oberen Bereich „No Data“. CoreDash misst diese Besuche trotzdem.

CoreDash: welche Seite, welches Element

CrUX, Googles Field Data, liefert dir einen einzigen p75-Wert pro URL oder pro Website. CoreDash, das Real User Monitoring, das ich gebaut habe, ist ein Skript auf deinen Seiten: Es misst jeden Besuch und nennt das Element hinter jedem LCP, INP und CLS. Du filterst nach Seite, Gerät und Element. Eine Änderung siehst du ab den nächsten Besuchen im Zeitverlauf. Binde das Skript ein, bevor du etwas änderst, damit du Vorher und Nachher vergleichen kannst.

CoreDash, acme-pagespeed.com, Mobile, p75 pro Seite: Eine Seite hat einen CLS von 0,92, während der Rest bei 0 liegt.

Wie lange dauert es, bis die Search Console deinen Fix anzeigt?

PageSpeed Insights und die Search Console zeigen die letzten 28 Tage, und dieses Zeitfenster wandert jeden Tag. In PageSpeed Insights sind die Daten etwa zwei Tage alt, in der Search Console noch ein paar Tage älter. Zwei Wochen nach deinem Fix stammt noch die Hälfte der Besuche in diesem Fenster aus der Zeit vor dem Fix. Nach vier Wochen enthält es nur noch Besuche nach dem Fix. Das 28-Tage-Fenster, Tag für Tag zeigt den genauen zeitlichen Ablauf.

Search Console, Core-Web-Vitals-Bericht, Mobile, am 26. Oktober 2026: zuletzt aktualisiert am 21. Oktober.

Der CrUX-History-Report zeigt dasselbe Fenster wochenweise: Jeder Balken deckt die 28 Tage davor ab. Ein Fix braucht also etwa vier Balken, bis er sich voll auswirkt.

CrUX-History-Report für ado-goldkante.de, Smartphones, LCP: Der Anteil guter, verbesserungsbedürftiger und schlechter Ladevorgänge pro Woche. Nach einer Änderung Mitte August klettert der gute Anteil über vier Balken von 59 % auf 76 %, 83 %, 90 % und 93 % – und der LCP bei p75 sinkt von 3,6 s auf 1,5 s.

Sobald der Fix live ist, öffne das Problem im Core-Web-Vitals-Bericht der Search Console und klicke auf „Start Tracking“ (auch „Validate fix“ genannt). Das startet die 28-tägige Prüfung der Search Console für jede URL mit diesem Problem auf denselben Field Data. Während der Laufzeit steht der Status auf „Started“, danach auf „Looking good“, sobald jede bisher geprüfte URL in Ordnung ist. Die Prüfung endet mit „Passed“, wenn 28 Tage lang keine URL mehr betroffen war – oder mit „Failed“, sobald eine URL das Problem noch immer hat. Dann behebst du das und klickst auf „Start new validation“.

Woran merkst du, dass ein Fix bei echten Besuchern ankommt?

Prüfe in dieser Reihenfolge – das Schnellste zuerst:

1. Die Änderung ist live. Schau in den Quelltext oder suche die Datei oder den Header im Network-Panel der DevTools. Siehst du noch die alte Version, liefert ein Caching-Plugin oder das CDN die alte Seite aus.
2. Lighthouse besteht. Mobil, drei Durchläufe, der mittlere (wie oben): Die Meldung wandert zu „Passed audits“.
3. Deine Besucher bekommen die Änderung. In CoreDash ab den nächsten Besuchen: Filtere die geänderte Seite oder das Template, stelle das Gerät auf Mobile und verfolge die Metrik pro Tag samt dem Element dahinter.
4. CrUX zieht nach. Die Field Data in PageSpeed Insights und die Balken im CrUX-History-Report bewegen sich schrittweise. Der volle Effekt zeigt sich nach vier Wochen (warum es so lange dauert).
5. Die Search Console bestätigt es. Klicke beim Problem im Core-Web-Vitals-Bericht auf „Start Tracking“ und warte auf „Passed“.

Lighthouse besteht, vier Wochen sind vorbei und deine Field Data bewegen sich noch immer nicht? Dann sind die langsamen Besuche genau jene, die Lighthouse nie durchführt: ein billigeres Smartphone, ein zäher Klick, ein Layout-Shift mitten auf der Seite. In einer Core-Web-Vitals-Power-Hour gehe ich deine Field Data mit dir durch, Seitengruppe für Seitengruppe, bis wir wissen, welche Seite und welches Element deinen p75 ausbremsen.