Ein Lighthouse-Score ist kein Core-Web-Vitals-Audit. Lighthouse misst einen reproduzierbaren Laborlauf unter festgelegten Bedingungen. Core Web Vitals sind dagegen als Feldmetriken konzipiert: Sie beschreiben, was reale Nutzer mit unterschiedlichen Geräten, Netzwerken, Cache-Zuständen und Interaktionen erleben.
Beide Ebenen sind wichtig, aber sie beantworten verschiedene Fragen:
- Felddaten: Wo und für wen besteht ein reales Problem?
- Labordaten: Welche technische Ursache lässt sich reproduzieren?
Ein belastbarer Audit beginnt mit der Verteilung realer Erfahrungen, grenzt betroffene Seitentypen ein und nutzt erst dann Lighthouse und DevTools zur Diagnose.
Die drei Core Web Vitals und ihre Grenzwerte
Google definiert aktuell drei Core Web Vitals:
| Metrik | Was sie misst | „Gut“ am 75. Perzentil |
|---|---|---|
| Largest Contentful Paint (LCP) | Ladezeit des größten sichtbaren Inhaltselements | ≤ 2,5 Sekunden |
| Interaction to Next Paint (INP) | Reaktionsfähigkeit bei Interaktionen | ≤ 200 Millisekunden |
| Cumulative Layout Shift (CLS) | unerwartete visuelle Verschiebungen | ≤ 0,1 |
Für die Einstufung wird das 75. Perzentil betrachtet. Vereinfacht: Mindestens 75 Prozent der erfassten Besuche sollten den guten Grenzwert erreichen. Ein Durchschnittswert kann langsame Erfahrungen verschleiern und ist für diese Klassifikation nicht der richtige Maßstab.
Die Metriken zeigen Symptome, nicht automatisch die Ursache. Ein schlechter LCP sagt noch nicht, ob Serverantwort, Bildpriorität, Fonts, CSS oder clientseitiges Rendering verantwortlich sind.
Warum Lighthouse und Felddaten widersprechen können
Labordaten und Felddaten erfassen unterschiedliche Populationen:
- Lighthouse führt einen einzelnen synthetischen Test mit definierter Hardware- und Netzwerkdrosselung aus.
- Felddaten enthalten viele reale Seitenaufrufe mit verschiedenen Viewports, Geräten, Standorten, Cache-Zuständen und Nutzeraktionen.
Deshalb kann eine Seite im Labor schlecht aussehen und im Feld gut abschneiden — oder umgekehrt. Typische Gründe sind:
- andere LCP-Elemente auf Mobilgerät und Desktop,
- wiederkehrende Besucher mit warmem Cache,
- Consent-Banner nur für neue Besucher,
- Personalisierung oder A/B-Tests,
- langsame Geräte, die im Test nicht repräsentiert sind,
- INP-Probleme nach Interaktionen, die ein Lade-Audit nie ausführt.
Lighthouse kann INP in einem normalen Seitenlade-Test nicht direkt messen, weil dafür reale Interaktionen über die Nutzung nötig sind. Total Blocking Time (TBT) ist ein nützlicher Laborindikator für Main-Thread-Blockaden, aber kein Ersatz für INP-Felddaten.
Welche Datenquellen ein Audit braucht
Search Console
Der Core-Web-Vitals-Bericht der Search Console nutzt CrUX-Daten und gruppiert ähnliche URLs. Er hilft, betroffene Seitengruppen und den zeitlichen Status zu erkennen. Er eignet sich weniger für eine komponentengenaue Ursachenanalyse.
Prüfen Sie:
- Mobil und Desktop getrennt,
- welche URL-Gruppen als schlecht oder verbesserungswürdig gelten,
- welche Beispiel-URLs Google nennt,
- ob wichtige Templates oder nur Randseiten betroffen sind.
PageSpeed Insights und CrUX
PageSpeed Insights stellt, sofern genügend Daten vorhanden sind, Felddaten aus dem Chrome User Experience Report (CrUX) neben einen Lighthouse-Laborlauf. Achten Sie darauf, ob Daten für die konkrete URL oder nur für den gesamten Origin angezeigt werden. Origin-Daten können ein Problem auf einer einzelnen Landingpage überdecken.
CrUX basiert auf berechtigten Chrome-Nutzern und bildet nicht zwangsläufig die gesamte Zielgruppe ab. Seiten mit wenig Traffic erhalten eventuell keine URL-genauen Daten.
Eigenes Real User Monitoring
Eigenes RUM kann Core Web Vitals pro Route, Template, Gerätekategorie, Navigationstyp oder Release erfassen. Die offizielle web-vitals-Bibliothek hilft bei der browserseitigen Erhebung.
Dabei gelten Datenschutz und Datenqualität:
- keine unnötigen Identifikatoren erfassen,
- Consent- und Rechtsgrundlage zum konkreten Setup passend prüfen,
- Bot- und Testtraffic kennzeichnen,
- Version und Route mitschreiben,
- Stichprobengröße und Perzentile statt Einzelwerte auswerten.
RUM ist besonders wertvoll, um eine Verschlechterung einem Deployment oder einer Komponente zuzuordnen.
Lighthouse und Chrome DevTools
Labortools liefern reproduzierbare Traces. Sie zeigen LCP-Phasen, Netzwerkabhängigkeiten, lange Main-Thread-Aufgaben, Layout Shifts und Ressourcenprioritäten. Führen Sie mehrere Läufe aus, weil ein einzelner Test durch Netzwerkschwankungen beeinflusst sein kann.
Audit-Ablauf in sieben Schritten
1. Geschäftlich relevante Seitentypen festlegen
Erstellen Sie eine kleine Matrix aus Template und Nutzeraufgabe:
- Start- und Service-Seiten,
- organische Landingpages,
- Artikel und Wissensseiten,
- Formulare oder Checkout,
- eingeloggte Produktansichten.
Performance ist kein abstrakter Site-Score. Ein INP-Problem im Angebotsformular kann wichtiger sein als ein LCP-Ausreißer auf einer selten besuchten Archivseite.
2. Felddaten segmentieren
Vergleichen Sie Mobil/ Desktop, Route, Land, Browser, Navigationstyp und Zeitraum — soweit Datenmenge und Datenschutz dies zulassen. Prüfen Sie die Verteilung und das 75. Perzentil, nicht nur den Mittelwert.
Dokumentieren Sie auch die Reichweite: Wie viele Aufrufe und Nutzer sind in der Stichprobe enthalten? Eine scheinbar starke Verbesserung bei sehr wenig Traffic kann Zufall sein.
3. Betroffene Templates und Komponenten erkennen
Wenn viele URLs desselben Templates scheitern, liegt die Ursache oft in einer gemeinsamen Komponente:
- Hero-Bild oder Font im Layout,
- Header und Navigation,
- Consent- oder Chat-Widget,
- globaler Client-Provider,
- Teaser- oder Kartenkomponente,
- Werbe- oder Personalisierungsslot.
Ein URL-Problem muss trotzdem nicht global sein. Unterschiedliche Inhalte können andere LCP-Elemente oder Bildgrößen erzeugen.
4. LCP in seine Phasen zerlegen
Prüfen Sie für das tatsächliche LCP-Element:
- Time to First Byte,
- Verzögerung bis zur Ressourcenerkennung,
- Ressourcendownload,
- Verzögerung bis zum Rendern.
Ein schneller Bilddownload hilft wenig, wenn das Bild erst nach einem clientseitigen API-Aufruf entdeckt wird. Umgekehrt löst Serveroptimierung keinen LCP, der durch ein schlecht priorisiertes Hero-Bild entsteht.
5. INP an realen Interaktionen untersuchen
Identifizieren Sie zuerst die langsamen Interaktionstypen: Navigation öffnen, Filter ändern, Formular ausfüllen oder Dialog anzeigen. Zerlegen Sie anschließend die Verzögerung in Input Delay, Event-Verarbeitung und Presentation Delay.
Typische Ursachen sind lange JavaScript-Tasks, große synchrone Zustandsupdates, unnötiges Re-Rendering, Layout-Arbeit nach dem Handler und konkurrierende Third-Party-Skripte. Ein Bundle-Audit kann helfen, ist aber nur ein Teil der Diagnose.
6. CLS mit den auslösenden Elementen verbinden
Layout Shifts entstehen häufig durch:
- Bilder oder Embeds ohne reservierte Abmessungen,
- Banner und Hinweise, die Inhalt nach unten drücken,
- spät geladene Fonts mit stark abweichenden Metriken,
- dynamische Inhalte oberhalb des sichtbaren Bereichs,
- Animationen, die Layout-Eigenschaften statt Transform verwenden.
Der CLS-Score allein zeigt nicht, welches Element verschoben wurde und welches die Verschiebung ausgelöst hat. Nutzen Sie die Layout-Shift-Einträge im Performance-Panel.
7. Fix, Regressionstest und Feldvalidierung
Vor dem Rollout:
- Vergleichsläufe unter identischen Laborbedingungen,
- visuelle und funktionale Tests,
- Performance-Budget im Build oder Monitoring,
- kontrollierter Rollout bei riskanten Komponenten.
Nach dem Rollout braucht die Feldbewertung Zeit und ausreichend Traffic. CrUX-basierte Berichte reagieren nicht wie ein Live-Monitor. Eigenes RUM kann früher zeigen, ob die Verteilung sich in die gewünschte Richtung bewegt.
Priorisierung ohne Score-Theater
Eine praktische Reihenfolge berücksichtigt vier Faktoren:
- Reichweite: Wie viele reale Nutzer sind betroffen?
- Schwere: Wie weit liegt das 75. Perzentil vom Ziel entfernt?
- Geschäftswert: Betrifft es Einstieg, Lead oder Transaktion?
- Fix-Risiko: Kann die Änderung Funktion, Tracking oder Layout beschädigen?
Google erklärt in seiner Page-Experience-Dokumentation, dass Core Web Vitals in Ranking-Systemen verwendet werden, gute Tool-Ergebnisse aber keine Top-Platzierung garantieren. Relevanter Inhalt bleibt zentral. Das Ziel ist daher eine bessere reale Erfahrung, nicht eine kosmetische 100 in Lighthouse.
Audit-Checkliste
- Mobil und Desktop wurden getrennt betrachtet.
- URL- und Origin-Daten werden nicht verwechselt.
- Stichprobengröße, Zeitraum und 75. Perzentil sind dokumentiert.
- Wichtige Templates und Nutzeraufgaben sind priorisiert.
- Felddaten bestimmen das Problem, Labordaten erklären die Ursache.
- LCP-Element und LCP-Phasen sind bekannt.
- INP wurde an konkreten Interaktionen untersucht.
- CLS-Auslöser wurden im Trace identifiziert.
- Third-Party- und Consent-Zustände sind Teil der Tests.
- Der Fix wurde funktional geprüft und im Feld nachgemessen.
Fazit
Ein Core-Web-Vitals-Audit ist ein Messprozess, kein einmaliger Lighthouse-Export. CrUX und eigenes RUM zeigen, wo reale Nutzer leiden. Lighthouse und DevTools machen Ursachen reproduzierbar. Erst die Verbindung beider Ebenen erlaubt eine Priorisierung, die Technik, SEO und Geschäftswirkung zusammenbringt.