Core Web Vitals 2026: LCP, INP und CLS mit echten Nutzerdaten diagnostizieren

Direkte Antwort

Die aktuellen Core Web Vitals sind Largest Contentful Paint, Interaction to Next Paint und Cumulative Layout Shift. Eine gute Erfahrung am 75. Perzentil bedeutet einen LCP von höchstens 2,5 Sekunden, einen INP von höchstens 200 Millisekunden und einen CLS von höchstens 0,1, jeweils getrennt für Mobile und Desktop bewertet.

Nutze Felddaten wie den Chrome UX Report oder dein eigenes Real-User-Monitoring, um zu entscheiden, ob echte Besucher ein Problem haben. Nutze Lighthouse und Performance-Traces, um ein reproduzierbares Problem in einer kontrollierten Umgebung zu erklären. Ein Lighthouse-Score von 100 beweist nicht, dass die mobile Feldkohorte besteht, und eine durchfallende CrUX-Kohorte sagt dir nicht, welche Codezeile die Ursache ist.

Behebe die Metrikkomponente, die tatsächlich langsam ist, sichere das Ergebnis mit einem Regressionsbudget ab, und versprich niemals, dass das Bestehen der Core Web Vitals einen Ranking- oder Umsatzanstieg bewirkt.

Was du danach kannst

Am Ende dieser Lektion kannst du:

• LCP, INP und CLS in Begriffen der Nutzererfahrung definieren;
• die Schwellenwerte gut, verbesserungswürdig und schlecht einordnen;
• Feld-, Labor-, Seiten- und Origin-Daten voneinander unterscheiden;
• LCP und INP in diagnostische Komponenten zerlegen;
• den ersten Fix für eine durchfallende Kohorte priorisieren;
• ein Performance-Budget und eine Verifikationsmethode festlegen, ohne einem Vanity-Score hinterherzujagen.

Die drei Core Web Vitals

Googles Web-Vitals-Leitfaden benennt drei stabile Core Web Vitals.

Largest Contentful Paint, oder LCP

LCP misst die Ladeperformance über die Renderzeit des größten qualifizierenden sichtbaren Inhaltselements im Viewport.

Die Nutzerfrage lautet:

Wann fühlt sich der wichtigste sichtbare Inhalt geladen an?

Gut: höchstens 2,5 Sekunden. Verbesserungswürdig: über 2,5 bis höchstens 4,0 Sekunden. Schlecht: über 4,0 Sekunden.

Interaction to Next Paint, oder INP

INP misst die Reaktionsfähigkeit, indem die Latenz von Nutzerinteraktionen beobachtet und eine repräsentative Interaktion mit hoher Latenz für den Seitenbesuch gemeldet wird.

Die Nutzerfrage lautet:

Wie lange dauert es nach einem Klick, Tap oder einer Eingabe, bis die Seite sichtbar reagiert?

Gut: höchstens 200 Millisekunden. Verbesserungswürdig: über 200 bis höchstens 500 Millisekunden. Schlecht: über 500 Millisekunden.

Auf stark interaktiven Seiten ignoriert INP in der Regel eine schlechteste Interaktion pro 50 Interaktionen, um den Effekt seltener Ausreißer zu verringern. Die exakte aktuelle Definition findest du im INP-Leitfaden von web.dev.

Cumulative Layout Shift, oder CLS

CLS misst unerwartete visuelle Instabilität anhand von Layout-Shift-Werten, die in Session-Fenstern zusammengefasst werden.

Die Nutzerfrage lautet:

Hat sich der Inhalt unerwartet bewegt, während ich versucht habe zu lesen oder zu handeln?

Gut: höchstens 0,1. Verbesserungswürdig: über 0,1 bis höchstens 0,25. Schlecht: über 0,25.

Vom Nutzer ausgelöste, erwartete Änderungen werden anders behandelt als unerwartete Verschiebungen. Reserviere Platz und steuere dynamische Inhalte, statt jede Bewegung zu verstecken.

Schwellenwert- und Diagnosetabelle

Die Schwellenwerte sind Erfahrungsrichtwerte. Sie sind kein Versprechen für Ranking oder Conversion.

Warum das 75. Perzentil zählt

Ein Durchschnitt kann die langsamste relevante Nutzerkohorte verdecken. Google empfiehlt, das 75. Perzentil der Seitenaufrufe zu bewerten, segmentiert nach Mobile und Desktop.

Wenn 75 Prozent der gemessenen Besuche einen LCP von höchstens 2,5 Sekunden haben, erreicht der p75-LCP den guten Schwellenwert. Liegt der Durchschnitt bei 2,0 Sekunden, der p75 aber bei 3,1 Sekunden, hat eine erhebliche Gruppe trotzdem eine langsamere Erfahrung.

Segmentiere weiter, wo möglich:

• Land oder Region;
• effektive Verbindung;
• Gerätefähigkeit;
• Template;
• eingeloggter Zustand;
• Release-Version.

Segmentiere nicht so aggressiv, dass die Stichprobe instabil oder datenschutzsensibel wird.

Felddaten versus Labordaten

Felddaten

Felddaten stammen von echten, berechtigten Nutzerbesuchen unter realen Geräten, Netzwerken, Caches, Erweiterungen und Verhaltensweisen.

Beispiele:

• Chrome UX Report, oder CrUX;
• der Feldbereich von PageSpeed Insights;
• die Core-Web-Vitals-Gruppen in der Search Console;
• dein eigenes Real-User-Monitoring.

Die CrUX-API-Dokumentation besagt, dass ihre Datensätze einen gleitenden 28-Tage-Erfassungszeitraum verwenden und täglich aktualisiert werden. Die Daten werden für berechtigte Seiten oder Origins aggregiert.

Einschränkungen:

• nicht jede Seite hat genug berechtigte Daten;
• der Origin-Fallback kann Unterschiede zwischen Seiten verdecken;
• Chrome-Nutzer sind nicht alle Nutzer;
• das Zeitfenster reagiert nur langsam auf einen Release;
• Felddaten identifizieren die betroffene Erfahrung, nicht die exakte Codeursache.

Labordaten

Labordaten führen eine Seite in einer kontrollierten Umgebung aus.

Beispiele:

• Lighthouse;
• das Performance-Panel von Chrome DevTools;
• WebPageTest;
• lokale Interaktions-Traces.

Vorteile:

• reproduzierbare Bedingungen;
• detaillierte Waterfall- und Hauptthread-Belege;
• schnelles Debugging vor dem Release.

Einschränkungen:

• nur ein Geräte- und Netzwerkprofil;
• synthetische Navigation;
• eingeschränkte Abdeckung echter Interaktionen;
• Cache und Standort weichen vom Feld ab;
• INP ist ohne Interaktionen möglicherweise nicht verfügbar.

Warum Lighthouse und CrUX nicht übereinstimmen

Sie beantworten unterschiedliche Fragen.

Lighthouse fragt:

Was ist bei diesem kontrollierten Durchlauf passiert?

CrUX fragt:

Was haben berechtigte echte Chrome-Nutzer über das gleitende Feldfenster hinweg erlebt?

Eine statische Astro-Seite kann in einem Desktop-Labor 100 Punkte erzielen und trotzdem einen schlechten mobilen Feld-INP haben, wenn echte Nutzer einen schweren Consent-Manager öffnen, mit einem Rechner interagieren oder langsamere Geräte nutzen.

Seiten- versus Origin-Daten

CrUX kann eine bestimmte URL melden, wenn genug Daten vorhanden sind. Andernfalls zeigen Tools womöglich Origin-Daten an.

Origin-Daten kombinieren unterschiedliche Templates und Nutzerpfade. Eine schnelle Dokumentationsseite kann einen langsamen Checkout verdecken. Eine langsame App kann eine redaktionelle Seite schuldig aussehen lassen.

Kennzeichne immer:

• Seite oder Origin;
• Mobile oder Desktop;
• Feld oder Labor;
• Zeitfenster;
• p75 oder ein anderes Perzentil;
• Stichprobenberechtigung.

LCP nach Komponenten diagnostizieren

Behandle LCP als eine Kette.

Time to First Byte
  + Verzögerung bei der Ressourcenentdeckung
  + Dauer des Ressourcen-Ladevorgangs
  + Verzögerung beim Rendern des Elements
  = beobachteter LCP

Time to First Byte

Die Dokumentantwort ist langsam.

Zu untersuchen:

• Serverarbeit;
• Cache-Miss;
• Weiterleitung;
• Geografie;
• Backend-Abhängigkeit;
• Kaltstart.

Verzögerung bei der Ressourcenentdeckung

Der Browser entdeckt die LCP-Ressource zu spät.

Zu untersuchen:

• CSS-Hintergrundbilder;
• clientseitig eingefügte Bilder;
• fehlendes Preload für eine wirklich kritische Ressource;
• blockierende Styles oder Skripte;
• Lazy Loading, das auf das LCP-Bild oberhalb des sichtbaren Bereichs angewendet wird.

Dauer des Ressourcen-Ladevorgangs

Die Ressource braucht zu lange zur Übertragung.

Zu untersuchen:

• übergroßes Bild;
• falsches Format oder falsche Dimensionen;
• langsames CDN;
• Kompression;
• konkurrierende Anfragen.

Verzögerung beim Rendern des Elements

Die Ressource ist bereit, kann aber nicht gemalt werden.

Zu untersuchen:

• renderblockierendes CSS;
• Arbeit im Hauptthread;
• verstecktes Element;
• Hydration;
• Font-Status;
• Animationsverzögerung.

Optimiere nicht den Server, wenn die tatsächliche LCP-Verzögerung von einem spät entdeckten, clientseitig gerenderten Bild stammt.

INP nach Phasen diagnostizieren

Jede langsame Interaktion lässt sich unterteilen in:

Input-Verzögerung
  + Verarbeitung des Event-Handlers
  + Darstellungsverzögerung
  = Interaktionslatenz

Input-Verzögerung

Die Interaktion wartet, weil der Hauptthread beschäftigt ist.

Typische Ursachen:

• lange Skript-Tasks;
• Drittanbietercode;
• Hydration;
• Parsen eines großen Payloads;
• synchroner Speicherzugriff.

Verarbeitungsdauer

Die Event-Handler selbst sind teuer.

Typische Ursachen:

• synchrones Filtern tausender Zeilen;
• wiederholte Layout-Lese- und Schreibvorgänge;
• großes State-Update;
• aufwendige Validierung;
• unnötige Arbeit bei jedem Tastenanschlag.

Darstellungsverzögerung

Die Handler-Arbeit endet, aber der nächste Frame verzögert sich.

Typische Ursachen:

• teures Style und Layout;
• Rendern eines riesigen Komponentenbaums;
• synchrone Folgeaufgaben;
• komplexes Paint.

Zerlege lange Tasks, reduziere Arbeit, gib die Kontrolle wo sinnvoll an den Browser ab und rendere nur, was der Nutzer braucht. Entferne keine nützliche Funktionalität nur, um einen Score zu verbessern.

CLS diagnostizieren

Nutze die Layout-Shift-Spur, um das sich bewegende Element und dessen Ursache zu identifizieren.

Häufige Ursachen:

• Bilder oder Embeds ohne Dimensionen;
• über dem Inhalt eingefügtes Cookie-Banner;
• Anzeigenplatz ohne reservierten Raum;
• späte Web-Font-Änderung;
• unerwartet eingefügtes Akkordeon oder Alert;
• Client-Hydration, die serverseitiges Markup durch eine andere Größe ersetzt.

Reserviere Platz, nutze stabile Platzhalter, koordiniere Fonts und füge dynamische UI in vorhersehbaren Bereichen ein.

Ein wiederholbares CWV-Verfahren

1. Das Feldproblem bestätigen

Notiere Metrik, Schwellenwert, Perzentil, Gerät, Seite oder Origin, Zeitfenster und die betroffene Template-Gruppe.

2. Datenberechtigung prüfen

Bezeichne eine neue Seite nicht als „CrUX-konform", wenn sie keinen Feld-Datensatz auf Seitenebene hat.

3. Einen repräsentativen Fall reproduzieren

Nutze ein geeignetes Mobilprofil, einen Standort, einen kalten oder warmen Zustand und eine echte Interaktion. Ein einzelner bester Desktop-Durchlauf ist nicht repräsentativ.

4. Die Metrik zerlegen

Identifiziere für LCP das Element und die vier zeitlichen Komponenten. Identifiziere für INP die tatsächliche Interaktion und die drei Phasen. Identifiziere für CLS den Verschiebungscluster und den Auslöser.

5. Grundursachen priorisieren

Wähle die Ursache, die die größte beobachtete Verzögerung erklärt und behoben werden kann, ohne die Aufgabe zu beeinträchtigen.

6. Budgets vor dem Release ergänzen

Beispiele:

• maximales JavaScript pro Route;
• maximale Dauer langer Tasks;
• maximale Byte-Größe des LCP-Bilds;
• reservierte Layout-Dimensionen;
• p75-RUM-Alarmschwelle.

7. Im Labor validieren

Bestätige, dass sich die anvisierte Komponente verbessert hat und keine Barrierefreiheits- oder Funktionsregression aufgetreten ist.

8. Sicher veröffentlichen

Nutze einen Kohorten- oder gestaffelten Rollout, wenn das Risiko es rechtfertigt. Dokumentiere den Release.

9. In den Felddaten verifizieren

Nutze RUM für schnelleres richtungsweisendes Feedback und warte auf das relevante gleitende CrUX-Fenster. Vergleiche dieselbe Kohorte und dieselben Definitionen.

Durchgerechnetes Beispiel: Desktop besteht, mobiler INP scheitert

Ein Lektions-Template zeigt:

• desktopseitige INP-ähnliche Laborinteraktion: 90 ms;
• mobile Laborinteraktion: 260 ms;
• mobiler Feld-INP p75: 420 ms;
• desktopseitiger Feld-INP p75: 150 ms.

Das Team möchte den Server aufrüsten.

Die Interaktion nachverfolgen

Auf Mobile ergibt das Öffnen des Tabellenfilters:

• Input-Verzögerung: 170 ms;
• Handler-Verarbeitung: 110 ms;
• Darstellungsverzögerung: 140 ms;
• Gesamt: 420 ms.

Die Haupt-Input-Verzögerung stammt von einer 190-ms-Analytics- und Hydrationsaufgabe, die bereits läuft, wenn der Nutzer tippt. Der Handler filtert und rendert anschließend die vollständige synthetische Tabelle mit 4.000 Zeilen.

Priorisierter Fix

1. nicht essenzielle Analytics-Initialisierung verzögern;
2. die Hydration-Arbeit in kleinere Tasks aufteilen;
3. das Filtern gegebenenfalls in eine effiziente Datenstruktur oder einen Worker verlagern;
4. eine virtualisierte, sichtbare Ergebnismenge rendern;
5. Tastatur- und Screenreader-Zugriff auf die Tabelle erhalten;
6. ein Budget für lange Tasks und mobile Interaktionen ergänzen.

Eine Serveraufrüstung könnte die initiale Dokumentantwort verbessern, adressiert aber nicht die gemessenen Interaktionsphasen.

Verifikation

Der Labor-Trace fällt auf dem repräsentativen mobilen Profil auf 160 ms. Das RUM der veröffentlichten Kohorte zeigt einen fallenden Trend. Der CrUX-p75 wird geprüft, nachdem das gleitende Feldfenster genug Post-Release-Exposition angesammelt hat.

Warum es trotzdem scheitern kann

Wenn die neue virtualisierte Tabelle semantische Beziehungen oder den Tastaturzugriff entfernt, hat sich die Performance verbessert, während das Produkt schlechter wurde. Zu den Schutzmaßnahmen müssen Aufgabenerfüllung und Barrierefreiheit gehören.

Core Web Vitals und die Google-Suche

Googles Dokumentation zu Core Web Vitals und Suchergebnissen erklärt, dass Core Web Vitals von Ranking-Systemen im Rahmen der Seitenerfahrung genutzt werden.

Überinterpretiere das nicht:

• gute CWV garantieren keine Top-Rankings;
• schlechte CWV machen relevanten Content nicht allein dadurch unsichtbar;
• Relevanz und Nützlichkeit bleiben entscheidend;
• ein Performance-Fix kann Nutzer verbessern, ohne eine messbare Ranking-Veränderung zu erzeugen.

Priorisiere katastrophale Usability-Fehler, Indexierbarkeit, Sicherheit und Aufgabenerfüllung, bevor du einem perfekten Labor-Score hinterherjagst.

SEOryon-Performance-Budget-Planer

Lade den CWV-Schwellenwert- und Performance-Budget-Planer herunter.

Erfasse für jedes Template:

• das Gerät;
• ob Feld-Daten auf Seitenebene berechtigt sind;
• den p75 von LCP, INP und CLS;
• den aktuellen Status;
• die erste Diagnose;
• das Release-Budget;
• verantwortliche Person und Überprüfungsdatum.

Die enthaltenen Zeilen sind synthetische Beispiele. Ersetze sie durch echte, freigegebene Aggregate. Nimm niemals persönliche oder mandantenbezogene Browsing-Daten auf.

Übung: vier Templates priorisieren

Wähle für jeden Fall die erste Maßnahme und die Verifikationsmethode.

Lösungsschlüssel

• Academy: die späte Entdeckung der LCP-Ressource beheben, mit einem repräsentativen Labor-Trace verifizieren, dann die mobile Feldkohorte.
• Rechner: echte Interaktionen instrumentieren und RUM sammeln, bevor der INP als gut oder schlecht bewertet wird.
• Vergleich: die gemessene lange Task und die Interaktionsphasen priorisieren, dann Aufgabenerfüllung und mobilen p75 verifizieren.
• Preise: nicht annehmen, dass die Seite anhand von Origin-Daten besteht. Seiten-RUM ergänzen und repräsentative Laborbelege prüfen.

Bestrafe jede Antwort, die allein anhand des höchsten Lighthouse-Scores wählt oder fehlende Daten als gut behandelt.

Häufige Fehler

FID als aktuellen Core Web Vital verwenden

INP hat FID als Responsiveness-Core-Web-Vital abgelöst.

Durchschnittswerte optimieren

Nutze p75 und aussagekräftige Kohorten.

Lighthouse mit CrUX verwechseln

Das eine ist ein kontrollierter Durchlauf. Das andere ist aggregierte Felderfahrung.

Der 100 hinterherjagen, bevor kaputter Content repariert ist

Performance unterstützt die Aufgabe. Sie ersetzt sie nicht.

Serverzeit für ein Interaktionsproblem verbessern

Zerlege zuerst die tatsächlichen INP-Phasen.

Umsatzkausalität aus einem einzigen Vorher-Nachher-Vergleich behaupten

Performance und Umsatz können aus vielen Gründen gemeinsam schwanken. Nutze ein geeignetes Experiment und bewahre die Unsicherheit.

Abschließende Checkliste

• Die Metrik ist LCP, INP oder CLS gemäß aktueller Definition.
• Die Schwellenwerte gut, verbesserungswürdig und schlecht sind korrekt.
• Die Daten sind als Feld oder Labor gekennzeichnet.
• Der Umfang Seite versus Origin ist erkennbar.
• Mobile und Desktop werden getrennt betrachtet.
• Perzentil und Zeitfenster sind dokumentiert.
• Die Berechtigung der Felddaten ist geprüft.
• LCP ist in Antwort, Entdeckung, Ladevorgang und Renderverzögerung zerlegt.
• INP ist in Input-, Verarbeitungs- und Darstellungsverzögerung zerlegt.
• CLS-Verschiebungen haben einen erkennbaren Auslöser.
• Der erste Fix adressiert die gemessene Grundursache.
• Funktionalität und Barrierefreiheit sind Schutzmaßnahmen.
• Ein Regressionsbudget existiert.
• Release-Annotationen und RUM-Monitoring sind konfiguriert.
• Ranking- und Umsatzergebnisse sind nicht garantiert.

Häufig gestellte Fragen

Warum ist Lighthouse grün, während die Search Console durchfällt?

Lighthouse ist ein einzelner kontrollierter Test. Die Search Console nutzt CrUX-Felddaten über berechtigte echte Nutzer und ein gleitendes Zeitfenster. Gerät, Netzwerk, Interaktion, Route und Zeitraum können abweichen.

Wie schnell zeigt CrUX meinen Fix?

CrUX nutzt einen gleitenden 28-Tage-Erfassungszeitraum, der täglich aktualisiert wird. Richtungsweisende Veränderungen können schrittweise sichtbar werden. Dein eigenes RUM kann schnellere Belege liefern.

Verbessert das Bestehen der Core Web Vitals das Ranking?

Core Web Vitals tragen zur Seitenerfahrung bei, aber das Bestehen garantiert keine Ranking-Gewinne. Behebe sie für die Nutzer und miss die Sucherfolge separat.

Was ist das beste Tool für INP?

Nutze Felddaten, um betroffene Kohorten zu identifizieren, und RUM, um echte Interaktionen zu erfassen. Nutze Chrome-Performance-Traces, um die konkrete langsame Interaktion und ihre Phasen zu diagnostizieren.

Sollte ich JavaScript entfernen, um INP zu verbessern?

Entferne unnötige Arbeit, nicht standardmäßig nützliche Funktionalität. Teile lange Tasks auf, senke die Kosten von Handlern und Rendering, und erhalte die Barrierefreiheit.

Quellen und Methodik

Die Community-Recherche zeigte zwei wiederkehrende Fragen: warum CrUX schlechter ausfallen kann als ein Lighthouse-Score von 90 bis 100, und welches Tool INP-Probleme aufdecken kann. Diese Fragen prägten die in der direkten Antwort formulierte Unterscheidung zwischen Feld-Entscheidungsdaten und Labor-Diagnose. Community-Aussagen wurden nicht als Beleg verwendet.

1. web.dev, Web Vitals, aktualisiert am 31. Oktober 2024 und geprüft am 28. Juli 2026. Offizielle Metrikdefinitionen, Schwellenwerte und p75-Empfehlungen.
2. web.dev, Interaction to Next Paint, aktualisiert am 2. September 2025 und geprüft am 28. Juli 2026. Offizielle INP-Definition, Schwellenwerte und Interaktionsmodell.
3. Chrome for Developers, CrUX-API, aktualisiert am 11. Februar 2025 und geprüft am 28. Juli 2026. Offizielles Modell für aggregierte 28-Tage-Real-User-Daten.
4. Google Search Central, Core Web Vitals und die Google-Suche, aktualisiert am 10. Dezember 2025 und geprüft am 28. Juli 2026. Offizieller Kontext zu Suchrelevanz und Seitenerfahrung.

Zurück: JavaScript-SEO und agentenlesbare Schnittstellen Weiter: /academy/structured-data-schema/ ist die geplante Route für Schritt 11 und soll unveröffentlicht bleiben, bis die vollständige Lektion existiert.