Die Core Web Vitals sind drei Messwerte, mit denen wichtige Aspekte der Nutzererfahrung einer Website beurteilt werden: Ladegeschwindigkeit, Reaktionsfähigkeit und visuelle Stabilität.
Die drei aktuellen Core Web Vitals heißen Largest Contentful Paint (LCP), Interaction to Next Paint (INP) und Cumulative Layout Shift (CLS).
Ein guter Wert allein bedeutet jedoch noch nicht, dass die gesamte Website schnell und problemlos funktioniert. Jeder der drei Messwerte betrachtet einen anderen Aspekt der Nutzererfahrung.
In diesem Artikel erklären wir dir, was LCP, INP und CLS messen, welche Werte als gut gelten und wie du bei auffälligen Ergebnissen systematisch nach der Ursache suchst.
Kurz erklärt: LCP misst vereinfacht, wie schnell ein wichtiger großer Seiteninhalt sichtbar wird. INP bewertet, wie schnell die Website auf Benutzerinteraktionen reagiert. CLS misst unerwartete Layoutverschiebungen während der Nutzung.
Was sind die Core Web Vitals? #
Core Web Vitals sind von Google definierte Kennzahlen zur Bewertung bestimmter Aspekte der tatsächlichen Nutzererfahrung einer Webseite.
Die drei aktuellen Core Web Vitals sind:
| Messwert | Vollständiger Name | Bewertet |
|---|---|---|
| LCP | Largest Contentful Paint | Ladeerlebnis |
| INP | Interaction to Next Paint | Reaktionsfähigkeit |
| CLS | Cumulative Layout Shift | Visuelle Stabilität |
Die Werte ergänzen sich, weil eine Website in einem Bereich sehr gut und in einem anderen problematisch sein kann.
Die Grenzwerte im Überblick #
Google unterteilt die Werte in die Bereiche „gut“, „verbesserungswürdig“ und „schlecht“.
| Messwert | Gut | Verbesserungswürdig | Schlecht |
|---|---|---|---|
| LCP | ≤ 2,5 s | > 2,5 s bis 4,0 s | > 4,0 s |
| INP | ≤ 200 ms | > 200 ms bis 500 ms | > 500 ms |
| CLS | ≤ 0,1 | > 0,1 bis 0,25 | > 0,25 |
Wichtig: Diese Grenzwerte gehören jeweils zu einer bestimmten Kennzahl. Ein LCP-Grenzwert von 2,5 Sekunden bedeutet beispielsweise nicht, dass jede andere denkbare Ladezeit ebenfalls unter 2,5 Sekunden liegen muss.
Warum wird das 75. Perzentil verwendet? #
Bei der Beurteilung realer Nutzungsdaten wird nicht einfach nur der beste oder durchschnittliche Seitenaufruf betrachtet.
Für die Core Web Vitals wird das 75. Perzentil verwendet.
Vereinfacht bedeutet das: Mindestens 75 Prozent der gemessenen Erfahrungen sollten den jeweiligen Grenzwert erreichen oder besser sein.
100 gemessene Erfahrungen
75 oder mehr
→ guter Bereich
wenn der Wert am 75. Perzentil
innerhalb des guten Grenzwerts liegtDamit wird die Beurteilung nicht nur von besonders schnellen Geräten und Verbindungen bestimmt.
Core Web Vitals bestehen: Was bedeutet das? #
Für eine gute Core-Web-Vitals-Bewertung müssen die drei maßgeblichen Kennzahlen LCP, INP und CLS bei ausreichender Datenbasis am 75. Perzentil im guten Bereich liegen.
Eine Website kann also beispielsweise einen guten LCP und CLS besitzen, aber wegen eines schlechten INP die Core-Web-Vitals-Bewertung nicht bestehen.
LCP → gut
INP → schlecht
CLS → gut
Ergebnis:
Core Web Vitals nicht vollständig bestandenLCP – Largest Contentful Paint #
Largest Contentful Paint misst die Zeit bis zum Rendern des größten relevanten Inhaltselements im sichtbaren Bereich.
Damit soll LCP näherungsweise erfassen, wann ein wesentlicher Teil des Hauptinhalts für den Besucher sichtbar geworden ist.
Ein guter LCP liegt bei:
2,5 Sekunden oder weniger
Welches Element kann das LCP-Element sein? #
Das hängt vom Aufbau der jeweiligen Seite ab.
Häufig handelt es sich beispielsweise um:
großes Hero-Bild
große Textüberschrift
Banner
großes Inhaltsbild
großen TextblockWelches Element tatsächlich als LCP erkannt wird, solltest du mit einem Performance-Werkzeug überprüfen und nicht nur anhand des Designs vermuten.
Beispiel für einen LCP #
Angenommen, eine Startseite besitzt im oberen Bereich ein großes Hero-Bild:
┌─────────────────────────────────────┐
│ Navigation │
├─────────────────────────────────────┤
│ │
│ GROSSES HERO-BILD │
│ │
│ Webhosting für KMU │
│ │
└─────────────────────────────────────┘Wenn dieses Bild das größte relevante Element im sichtbaren Bereich darstellt, kann es zum LCP-Element werden.
Lädt es spät, kann sich dadurch auch der LCP verschlechtern.
Was kann einen schlechten LCP verursachen? #
Ein auffälliger LCP kann verschiedene Ursachen haben.
Dazu können beispielsweise gehören:
- eine langsame Bereitstellung des HTML-Dokuments,
- ein sehr großes LCP-Bild,
- eine spät entdeckte Bildressource,
- render-blockierende Ressourcen,
- Webfonts,
- clientseitiges Rendering,
- eine ungünstige Ladepriorisierung.
Welche Ursache tatsächlich vorliegt, muss an der konkreten Seite untersucht werden.
Bei schlechtem LCP zuerst das LCP-Element identifizieren #
Bevor du irgendwelche Performance-Einstellungen änderst, solltest du feststellen, welches Element überhaupt gemessen wird.
LCP schlecht
↓
LCP-Element identifizieren
↓
Bild?
Text?
anderes Element?
↓
Ladeweg dieses Elements untersuchenGoogle PageSpeed Insights kann bei der Analyse Hinweise auf das LCP-Element und dessen Ladeverhalten liefern.
Wie du das Werkzeug verwendest, erklären wir unter Google PageSpeed Insights richtig verwenden.
Wenn ein Bild das LCP-Element ist #
Ist ein Hero- oder Inhaltsbild für den LCP verantwortlich, solltest du zunächst dessen technische Eigenschaften prüfen.
Interessant sind unter anderem:
Pixelabmessungen
Dateigröße
Bildformat
Kompression
responsive Bildvarianten
Zeitpunkt der Entdeckung
Ladepriorität
Lazy LoadingEin Bild im unmittelbar sichtbaren Bereich sollte beispielsweise nicht ohne Prüfung genauso behandelt werden wie ein Bild weit unten auf der Seite.
Wie du Bilder sinnvoll vorbereitest, erklären wir unter Bilder für das Web optimieren: Dateigröße, Format und SEO.
Lazy Loading kann beim LCP problematisch sein #
Lazy Loading ist für Bilder außerhalb des unmittelbar sichtbaren Bereichs häufig sinnvoll.
Wird jedoch ein wichtiges LCP-Bild im oberen Seitenbereich unnötig verzögert geladen, kann dies den LCP verschlechtern.
Deshalb gilt nicht:
Alle Bilder = Lazy Loading
Sondern:
Lazy Loading dort einsetzen, wo verzögertes Laden sinnvoll ist.
Ein modernes Bildformat allein löst keinen schlechten LCP #
WebP oder AVIF können helfen, die Dateigröße eines Bildes zu reduzieren. Das Format ist jedoch nur ein Teil des gesamten Ladewegs.
Ein riesiges WebP-Bild mit unnötigen Pixelabmessungen kann weiterhin problematisch sein.
Auch eine kleine Bilddatei kann spät geladen werden, wenn der Browser sie erst spät entdeckt.
Die Wahl des Bildformats behandeln wir unter WebP, AVIF, JPG und PNG: Welches Bildformat verwenden?.
Die Serverantwort kann den LCP beeinflussen #
Bevor der Browser wichtige Seiteninhalte rendern kann, muss er zunächst die erforderlichen Daten erhalten.
Wenn bereits die Bereitstellung des HTML-Dokuments lange dauert, verschiebt sich auch der Zeitpunkt, an dem nachgelagerte Ressourcen entdeckt und dargestellt werden können.
Ein schlechter LCP sollte deshalb nicht ausschließlich als „Bildproblem“ betrachtet werden.
INP – Interaction to Next Paint #
Interaction to Next Paint misst die Reaktionsfähigkeit einer Seite auf Benutzerinteraktionen.
Dazu gehören beispielsweise Interaktionen über:
Mausklick
Touchscreen
TastaturINP betrachtet, wie lange es dauert, bis eine Interaktion verarbeitet wird und der Browser anschließend eine visuelle Aktualisierung darstellen kann.
Ein guter INP liegt bei:
200 Millisekunden oder weniger
Was bedeutet INP für einen Besucher? #
Stell dir vor, du klickst auf einen Button.
Bei einer reaktionsschnellen Website erhältst du praktisch unmittelbar eine sichtbare Reaktion.
Bei einer schlechten Reaktionsfähigkeit kann dagegen eine merkliche Verzögerung entstehen:
Klick
↓
........ Verzögerung ........
↓
sichtbare ReaktionGenau diese Art von Nutzererfahrung soll INP messbar machen.
INP misst nicht einfach nur den ersten Klick #
INP betrachtet die Interaktionen während des Besuchs einer Seite und versucht, die gesamte Reaktionsfähigkeit anhand einer repräsentativen langsamen Interaktion zu bewerten.
Es handelt sich damit nicht einfach um eine Messung der ersten Interaktion nach dem Seitenaufruf.
Was gehört zu einer Interaktionslatenz? #
Vereinfacht lässt sich die Zeit einer Interaktion in mehrere Abschnitte zerlegen:
Benutzer interagiert
↓
Eingabeverzögerung
↓
Event-Handler / Verarbeitung
↓
Darstellungsverzögerung
↓
nächster sichtbarer FrameProbleme können in unterschiedlichen Teilen dieses Ablaufs entstehen.
Was kann einen schlechten INP verursachen? #
Eine häufige Ursache ist zu viel Arbeit auf dem Hauptthread des Browsers.
Dazu kann umfangreiches oder ineffizientes JavaScript beitragen.
Weitere mögliche Ursachen sind beispielsweise:
- lange JavaScript-Aufgaben,
- aufwendige Event-Handler,
- komplexe DOM-Änderungen,
- umfangreiche Layout- und Rendering-Arbeit,
- viele gleichzeitig ausgeführte Scripts,
- aufwendiger Drittanbieter-Code.
Was ist der Main Thread? #
Der Hauptthread beziehungsweise Main Thread des Browsers übernimmt zahlreiche Aufgaben, die für die Darstellung und Interaktion einer Webseite erforderlich sind.
Dazu gehören unter anderem Teile der JavaScript-Ausführung, Layoutberechnungen und Rendering-Arbeiten.
Ist dieser Thread lange mit einer Aufgabe beschäftigt, kann er nicht gleichzeitig sofort auf eine neue Benutzerinteraktion reagieren.
Main Thread:
████████ lange JavaScript-Aufgabe ████████
↓
Benutzer klickt hier
↓
muss zunächst wartenWas sind Long Tasks? #
Lange Aufgaben auf dem Hauptthread können die Reaktionsfähigkeit einer Website beeinträchtigen.
Eine umfangreiche JavaScript-Aufgabe kann beispielsweise den Browser so lange beschäftigen, dass Benutzerinteraktionen verzögert verarbeitet werden.
Bei der INP-Optimierung ist deshalb häufig interessant, welche Aufgaben während einer langsamen Interaktion stattfinden.
INP ist nicht dasselbe wie TBT #
In Lighthouse begegnet dir häufig der Wert Total Blocking Time, kurz TBT.
TBT ist eine Laborkennzahl. INP basiert dagegen auf tatsächlichen Benutzerinteraktionen und ist ein Core Web Vital.
TBT kann für die technische Diagnose hilfreich sein, ist aber kein Ersatz für INP.
TBT
→ Labormessung
INP
→ reale Interaktionsdaten möglich
→ Core Web VitalWarum kann PageSpeed keinen echten INP im Labortest erzeugen? #
INP benötigt echte Benutzerinteraktionen während eines Seitenbesuchs.
Ein synthetischer Lighthouse-Ladetest besitzt nicht dieselbe Sammlung realer Interaktionen wie Felddaten.
Deshalb solltest du bei INP besonders auf verfügbare Felddaten achten.
Was tun bei schlechtem INP? #
Versuche zunächst herauszufinden, welche Interaktionen langsam sind.
Beispiele:
Menü öffnen
Filter anwenden
Produktvariante auswählen
Accordion öffnen
Formular bedienen
Warenkorb aktualisieren
Cookie-Banner bedienenAnschließend solltest du untersuchen, welche JavaScript- oder Rendering-Arbeit durch diese Interaktion ausgelöst wird.
Praxis-Tipp: Bei einem schlechten INP solltest du nicht einfach wahllos JavaScript-Dateien deaktivieren. Finde zuerst heraus, welche Interaktion langsam ist und was der Browser während dieser Interaktion verarbeitet.
Drittanbieter-Scripts können INP beeinflussen #
Websites laden häufig JavaScript von externen Diensten.
Beispiele sind:
Analytics
Tag-Manager
Chat-Systeme
Social-Media-Widgets
Werbesysteme
Tracking
Maps
Marketing-ToolsAuch solcher Code kann Rechenzeit auf dem Main Thread beanspruchen.
Das bedeutet nicht, dass jeder externe Dienst entfernt werden muss. Sein Nutzen sollte aber gegen den technischen Aufwand und mögliche Performance-Auswirkungen abgewogen werden.
CLS – Cumulative Layout Shift #
Cumulative Layout Shift misst unerwartete Verschiebungen sichtbarer Seitenelemente.
Ein guter CLS liegt bei:
0,1 oder weniger
Anders als LCP und INP wird CLS nicht in Sekunden oder Millisekunden angegeben.
Es handelt sich um einen dimensionslosen Wert, der die Auswirkungen unerwarteter Layoutverschiebungen beschreibt.
Wie fühlt sich ein schlechter CLS an? #
Ein typisches Beispiel:
Du möchtest auf einen Button klicken. Kurz vor dem Klick erscheint oberhalb ein weiteres Element. Der Button springt nach unten und du klickst versehentlich auf etwas anderes.
VORHER
[ Kaufen ]
Du willst klicken ...
↓
Bild wird nachgeladen
↓
NACHHER
[ neues Bild ]
[ Kaufen ]
Button ist plötzlich verschobenSolche unerwarteten Bewegungen können sehr störend sein.
Nicht jede Layoutverschiebung ist schlecht #
Layoutänderungen können auch vom Benutzer erwartet und bewusst ausgelöst werden.
Wenn du beispielsweise ein Menü öffnest oder einen Akkordeon-Bereich aufklappst, darf sich die Oberfläche entsprechend verändern.
Problematisch sind vor allem unerwartete Verschiebungen, die ohne eine entsprechende Erwartung des Benutzers auftreten.
Was kann einen schlechten CLS verursachen? #
Typische Ursachen können sein:
- Bilder ohne reservierten Platz,
- Werbe- oder Bannerflächen ohne feste Dimensionen,
- nachträglich eingefügte Inhalte,
- Cookie- oder Hinweis-Elemente, die Inhalt verschieben,
- bestimmte Webfont-Effekte,
- dynamische Widgets.
Bilder ohne Abmessungen und CLS #
Wenn der Browser vor dem Laden eines Bildes nicht weiß, wie viel Platz benötigt wird, kann sich das Layout verändern, sobald das Bild erscheint.
Bei einem HTML-Bild können beispielsweise geeignete Angaben für width und height dabei helfen, das Seitenverhältnis beziehungsweise den erforderlichen Platz bereits vorher zu berücksichtigen.
<img
src="beispiel.webp"
width="1200"
height="800"
alt="Beispielbild"
>Moderne CMS übernehmen solche Angaben häufig automatisch. Bei einem auffälligen CLS lohnt sich trotzdem die Kontrolle.
Webfonts und Layoutverschiebungen #
Auch Schriftarten können die Darstellung beeinflussen.
Wenn zunächst eine Ersatzschrift dargestellt und später durch eine Webfont ersetzt wird, können sich Zeichenbreiten und Zeilenumbrüche verändern.
Dadurch kann sich auch das Layout verschieben.
Ob dies tatsächlich ein relevantes CLS-Problem verursacht, sollte gemessen und nicht nur vermutet werden.
Cookie-Banner und CLS #
Ein Cookie-Banner kann ebenfalls Layoutverschiebungen verursachen, wenn es nachträglich in den normalen Seitenfluss eingefügt wird und vorhandene Inhalte verschiebt.
Ein Overlay, das über dem bestehenden Inhalt erscheint, verhält sich technisch anders als ein Element, das nachträglich Platz innerhalb des Layouts beansprucht.
Bei auffälligen CLS-Werten solltest du deshalb auch Consent- und Hinweis-Systeme untersuchen.
Dynamische Inhalte und CLS #
Nachgeladene Inhalte können problematisch sein, wenn für sie vorher kein entsprechender Platz vorgesehen wurde.
Beispiele:
Werbebanner
Empfehlungsboxen
Social-Media-Feeds
Bewertungen
externe Widgets
personalisierte InhalteWenn solche Elemente Inhalte nach unten oder zur Seite verschieben, können sie zum CLS beitragen.
Wie wird CLS berechnet? #
CLS basiert nicht einfach auf der Anzahl der Bewegungen.
Für eine Layoutverschiebung werden unter anderem berücksichtigt, wie viel des sichtbaren Bereichs von instabilen Elementen betroffen ist und wie weit sich diese Elemente bewegen.
Die einzelnen relevanten Layoutverschiebungen werden innerhalb definierter Sitzungsfenster bewertet.
Für die praktische Website-Optimierung musst du die Formel normalerweise nicht selbst berechnen. Wichtiger ist, die verursachenden Elemente zu identifizieren.
LCP, INP und CLS messen unterschiedliche Probleme #
Eine Website kann beispielsweise folgende Werte besitzen:
LCP: 1,9 s
→ gut
INP: 180 ms
→ gut
CLS: 0,32
→ schlechtDie Seite lädt in diesem Beispiel schnell und reagiert gut auf Interaktionen, besitzt aber erhebliche visuelle Verschiebungen.
Eine pauschale Aussage wie „Die Website ist schnell“ würde das eigentliche Problem nicht erfassen.
Ein weiteres Beispiel #
LCP: 4,4 s
→ schlecht
INP: 120 ms
→ gut
CLS: 0,04
→ gutHier reagiert die Website gut und bleibt visuell stabil. Der Hauptinhalt erscheint aber zu spät.
Die Optimierung sollte deshalb zunächst auf den LCP beziehungsweise dessen Ursache ausgerichtet werden.
Felddaten und Labordaten unterscheiden #
Für die Core Web Vitals ist die Unterscheidung zwischen realen Felddaten und synthetischen Labordaten besonders wichtig.
Felddaten zeigen die tatsächlichen Erfahrungen realer Nutzer.
Labordaten werden unter kontrollierten Testbedingungen erzeugt und eignen sich besonders für die technische Diagnose.
Die Unterschiede erklären wir ausführlich unter Website-Ladezeit messen und richtig beurteilen.
Warum unterscheiden sich meine realen und getesteten Werte? #
Reale Besucher verwenden unterschiedliche Geräte, Netzwerkverbindungen und Browserbedingungen.
Ein Labortest arbeitet dagegen mit festgelegten beziehungsweise simulierten Bedingungen.
Deshalb können beispielsweise folgende Ergebnisse gleichzeitig auftreten:
Labortest:
LCP auffällig
reale Felddaten:
LCP gutoder umgekehrt.
Beide Ergebnisse können korrekt sein, weil sie unterschiedliche Daten betrachten.
Wo finde ich reale Core-Web-Vitals-Daten? #
Reale Nutzungsdaten können unter anderem in Google PageSpeed Insights angezeigt werden, sofern genügend Daten für die betreffende URL beziehungsweise den Ursprung vorhanden sind.
Auch Google Search Console stellt einen Bericht zu den Core Web Vitals bereit.
Die Einrichtung der Search Console behandeln wir unter Google Search Console einrichten und Website bestätigen.
Warum fehlen Core-Web-Vitals-Daten manchmal? #
Für Felddaten muss eine ausreichende Datenbasis vorhanden sein.
Neue oder wenig besuchte Websites beziehungsweise einzelne URLs können deshalb unter Umständen keine eigenen ausreichenden Felddaten besitzen.
Das ist kein Performance-Fehler.
Wichtig: Fehlende Felddaten bedeuten nicht, dass deine Core Web Vitals schlecht sind. Es kann schlicht nicht genügend geeignete Messdaten geben.
URL-Daten und Origin-Daten #
Performance-Werkzeuge können je nach Verfügbarkeit Daten für eine einzelne URL oder aggregierte Daten für einen gesamten Ursprung anzeigen.
Das sollte bei der Interpretation berücksichtigt werden.
URL
→ konkrete Seite
Origin
→ zusammengefasste Daten
derselben Website-HerkunftEin guter Origin-Wert garantiert deshalb nicht automatisch, dass jede einzelne Seite identisch funktioniert.
Core Web Vitals und mobile Geräte #
Mobile Nutzer können andere Performance-Erfahrungen haben als Desktop-Nutzer.
Unterschiede entstehen beispielsweise durch:
Rechenleistung
Netzwerkverbindung
Displaygröße
Seitenlayout
geladene Ressourcen
BenutzerinteraktionenDeshalb solltest du Performance-Probleme nicht ausschließlich auf einem leistungsfähigen Desktop-Rechner beurteilen.
Core Web Vitals und SEO #
Die Core Web Vitals sind Teil der technischen Signale rund um die Nutzererfahrung einer Seite.
Sie sollten jedoch nicht als isolierter „Google-Ranking-Score“ betrachtet werden.
Ein guter LCP, INP und CLS garantiert keine bestimmte Position in den Suchergebnissen.
Umgekehrt solltest du schlechte Werte nicht ignorieren, nur weil eine Seite momentan gut rankt.
Eine schnelle, reaktionsfähige und stabile Website ist vor allem für deine Besucher sinnvoll.
Von 90 auf 100 ist nicht automatisch die wichtigste Optimierung #
Die Core Web Vitals besitzen klar definierte gute Bereiche. Das bedeutet nicht, dass du anschließend jede weitere Millisekunde um jeden Preis entfernen musst.
Wenn eine Website bereits eine gute Nutzererfahrung bietet, kann es sinnvoller sein, größere Probleme an anderer Stelle zu lösen.
Beispielsweise:
LCP 2,4 s → gut
aber:
Checkout funktioniert auf Mobilgeräten nicht
→ Checkout-Problem hat eindeutig höhere PrioritätCore Web Vitals nicht isoliert optimieren #
Technische Performance-Maßnahmen können Nebenwirkungen besitzen.
Wenn du beispielsweise JavaScript aggressiv verzögerst, nur um einen Messwert zu verbessern, können Navigation, Formulare oder andere Funktionen beeinträchtigt werden.
Dasselbe gilt für übermäßige Bildkompression oder unpassendes Lazy Loading.
Grundregel: Eine Performance-Optimierung ist nur dann eine Verbesserung, wenn die Website danach nicht nur bessere Messwerte besitzt, sondern weiterhin korrekt und angenehm funktioniert.
Core Web Vitals systematisch optimieren #
Statt wahllos Optimierungsmaßnahmen umzusetzen, solltest du zuerst feststellen, welcher Messwert tatsächlich problematisch ist.
Core Web Vitals prüfen
↓
Welcher Wert ist schlecht?
↓
LCP?
INP?
CLS?
↓
konkrete Ursache identifizieren
↓
gezielte Änderung
↓
Website testen
↓
erneut messenWenn LCP schlecht ist #
Beginne mit folgenden Fragen:
Welches Element ist das LCP-Element?
Wann wird es entdeckt?
Wie groß ist die Ressource?
Ist das Bild passend dimensioniert?
Wird es unnötig lazy geladen?
Blockieren andere Ressourcen die Darstellung?
Wie schnell wird das HTML bereitgestellt?Danach kannst du wesentlich gezielter optimieren.
Wenn INP schlecht ist #
Beginne mit:
Welche Interaktion ist langsam?
Was passiert nach dem Klick oder Tastendruck?
Welche JavaScript-Aufgaben laufen?
Ist der Main Thread lange blockiert?
Sind Drittanbieter-Scripts beteiligt?
Werden große DOM- oder Layout-Änderungen ausgelöst?Das Ziel ist nicht einfach „weniger JavaScript“, sondern weniger unnötige beziehungsweise ungünstig geplante Arbeit während wichtiger Interaktionen.
Wenn CLS schlecht ist #
Untersuche:
Welches Element verschiebt sich?
Was löst die Verschiebung aus?
Sind Bildabmessungen bekannt?
Wird Inhalt nachträglich eingefügt?
Verändert eine Webfont das Layout?
Verschiebt ein Banner bestehende Inhalte?
Sind externe Widgets beteiligt?Behebe anschließend die konkrete Ursache der unerwarteten Verschiebung.
Mehrere Probleme können dieselbe Ursache haben #
Performance-Probleme sind nicht immer sauber voneinander getrennt.
Ein komplexes JavaScript-Widget kann beispielsweise Ressourcen nachladen, den Main Thread belasten und gleichzeitig Inhalte in das Layout einfügen.
Dadurch können mehrere Messwerte beeinflusst werden.
Eine saubere Ursachenanalyse ist deshalb wichtiger als das isolierte „Optimieren einer Zahl“.
Nach Änderungen erneut messen #
Wenn du eine konkrete Ursache behoben hast, solltest du erneut testen.
Für unmittelbare technische Veränderungen eignen sich Labortests gut.
Reale Felddaten verändern sich dagegen nicht sofort, weil sie über einen längeren Zeitraum gesammelt und ausgewertet werden.
Erwarte deshalb nicht, dass eine heute vorgenommene Optimierung unmittelbar sämtliche Felddaten verändert.
Häufige Fehler bei Core Web Vitals #
LCP mit vollständiger Ladezeit gleichsetzen
INP mit TBT gleichsetzen
CLS in Sekunden interpretieren
nur den Performance-Score betrachten
nur Desktop testen
fehlende Felddaten als schlechte Werte interpretieren
jedes Bild pauschal lazy laden
JavaScript blind deaktivieren
jede Layoutänderung als CLS-Problem betrachten
gute Core Web Vitals mit guten Rankings gleichsetzen
mehrere Optimierungen gleichzeitig durchführen
nach Änderungen sofort neue Felddaten erwartenPraktische Diagnose-Matrix #
| Problem | Erste Untersuchung |
|---|---|
| LCP schlecht | LCP-Element und dessen Ladeweg identifizieren |
| INP schlecht | langsame Interaktionen und Main-Thread-Arbeit untersuchen |
| CLS schlecht | verschobene Elemente und Auslöser identifizieren |
Checkliste für Core Web Vitals #
Felddaten vorhanden?
↓
URL- oder Origin-Daten?
↓
75. Perzentil betrachten
↓
LCP ≤ 2,5 s?
↓
INP ≤ 200 ms?
↓
CLS ≤ 0,1?
↓
problematischen Messwert bestimmen
↓
verursachendes Element / Interaktion finden
↓
technische Ursache untersuchen
↓
gezielte Änderung durchführen
↓
Website funktional testen
↓
Labortest wiederholen
↓
Entwicklung der Felddaten beobachtenZusammenfassung #
Die Core Web Vitals betrachten drei unterschiedliche Aspekte der Nutzererfahrung einer Website.
LCP misst das Ladeerlebnis eines wichtigen großen Inhalts und gilt bei einem Wert von höchstens 2,5 Sekunden als gut.
INP bewertet die Reaktionsfähigkeit auf Benutzerinteraktionen. Ein Wert von höchstens 200 Millisekunden gilt als gut.
CLS bewertet unerwartete Layoutverschiebungen. Ein Wert von höchstens 0,1 gilt als gut.
Für die Bewertung realer Nutzungsdaten ist das 75. Perzentil entscheidend. Dadurch werden nicht nur besonders schnelle Einzelaufrufe berücksichtigt.
Bei schlechten Werten solltest du nicht sofort allgemeine Performance-Einstellungen verändern. Identifiziere zuerst beim LCP das betroffene Element, beim INP die langsame Interaktion und beim CLS die unerwartete Layoutverschiebung.
Core Web Vitals sind am hilfreichsten, wenn du sie nicht als drei Zahlen betrachtest, die möglichst grün werden sollen, sondern als Hinweise darauf, welches konkrete Erlebnis deiner Besucher verbessert werden kann.
