Core Web Vitals 2026: LCP, INP, CLS und was Rankings wirklich bewegt

Core Web Vitals sind Googles messbare Antwort auf eine einfache Frage. Fühlt sich diese Seite für eine echte Person auf einem echten Smartphone tatsächlich schnell an? Lab Scores können täuschen, Marketing Aussagen können täuschen, aber die Zeitdaten echter Chrome Nutzer aus dem Feld sagen die Wahrheit. Genau diese Daten erfassen die Core Web Vitals, und genau das ist der Grund, warum sich diese Metriken gehalten haben, während viele andere Page Experience Initiativen verschwunden sind.

Im Jahr 2026 ist das Set fixiert. LCP misst das Laden. INP misst die Interaktivität. CLS misst die visuelle Stabilität. Zusammen decken sie genau die Momente ab, in denen Nutzer eine langsame Seite bemerken. Dieser Leitfaden behandelt jede Metrik einzeln, die geltenden Schwellwerte, den Unterschied zwischen Lab und Feld, das Playbook zur Behebung jedes Problems und die ehrliche Antwort auf die Frage, die jedes Team irgendwann stellt: Wann bewegen Core Web Vitals tatsächlich Rankings?

Die drei Metriken im Jahr 2026

Google fasst die Core Web Vitals in drei benannten Metriken zusammen, jeweils eine pro Kategorie der vom Nutzer wahrgenommenen Performance.

Largest Contentful Paint (LCP) erfasst das Laden. Die Uhr läuft ab dem Moment, in dem der Nutzer die Seite anfordert, bis das größte sichtbare Inhaltselement vollständig gerendert ist. Dieses Element ist meist das Hero Bild, ein Banner oder eine große Überschrift.

Interaction to Next Paint (INP) erfasst die Interaktivität. INP hat First Input Delay (FID) im März 2024 abgelöst. Während FID nur die allererste Interaktion gemessen hat, misst INP jede Interaktion über die gesamte Sitzung und meldet die längste Verzögerung. Diese Änderung ist wichtig, weil die meisten Nutzer einen flüssigen ersten Klick haben und erst beim dritten oder vierten Tap auf eine ruckelnde Verzögerung stoßen. INP fängt genau die schlechten Momente ein, die FID nie sah.

Cumulative Layout Shift (CLS) erfasst die visuelle Stabilität. CLS ist die Summe der unerwarteten Layoutverschiebungen während der Sitzung. Ein Button, der nach unten rutscht, weil über ihm eine langsame Anzeige geladen wird, ein Rezept, das halb nach unten springt, weil eine Schriftart einspringt, beides erzeugt CLS. Layoutverschiebungen sind genau die Art von Bug, die ein Entwickler auf einem schnellen Laptop kaum bemerkt, und genau die Art, die ein echter Nutzer auf einem langsameren Smartphone jeden Tag spürt.

Diese drei Metriken teilen zwei Designentscheidungen, die erklären, warum sie zum Standard geworden sind. Sie sind nutzerwahrgenommen, nicht technisch. Und sie werden aus echten Chrome Nutzern über den Chrome User Experience Report (CrUX) gemeldet, nicht aus synthetischen Lab Läufen. Beide Entscheidungen sind bewusst. Frühere Metriken wie Time to First Byte und First Contentful Paint waren technische Stellvertreter, die nicht immer zum tatsächlichen Empfinden der Nutzer passten. Core Web Vitals versuchen, das Empfinden selbst zu messen.

Largest Contentful Paint (LCP)

LCP markiert den Moment, in dem die Seite visuell aussagekräftig wird. Solange das größte Element noch lädt, wartet der Nutzer. Sobald es gerendert ist, kann er sich engagieren.

Die LCP Schwellwerte für 2026, festgelegt von Google, sind unverändert.

• Gut: 2,5 Sekunden oder weniger
• Verbesserungsbedürftig: 2,5 bis 4,0 Sekunden
• Schlecht: mehr als 4,0 Sekunden

Das 75. Perzentil ist entscheidend. Google betrachtet den LCP Wert am 75. Perzentil Ihrer echten Besucher über ein 28 Tage Fenster. Wenn 75 Prozent Ihrer Nutzer LCP bei 2,5 Sekunden oder weniger sehen, ist die Seite gut. Wenn nur der Median diesen Wert erreicht und das 75. Perzentil bei 5 Sekunden liegt, ist die Seite schlecht.

Das größte Element wird vom Browser live identifiziert. Auf einer typischen Inhaltsseite ist es das Hero Bild, ein hervorgehobenes Foto oder manchmal eine große Überschrift. Auf Commerce Seiten ist es oft das Hauptproduktbild. Auf einer Startseite mit Video übernimmt das Posterbild des Videos diese Rolle.

Die häufigen Ursachen für langsames LCP fallen in fünf Gruppen.

Langsame Server Antwort. Time to First Byte ist Teil von LCP. Wenn der Server 800 ms braucht, um das erste Byte zu senden, kann LCP nicht früher beginnen. Die Server Antwortzeit hängt von Hosting, CDN und der Arbeit ab, die der Server vor der Antwort leistet.

Render blockierende Ressourcen. CSS Dateien im Head und JavaScript ohne async oder defer blockieren das Rendering. Jede blockierende Ressource ist eine Verzögerung für LCP.

Langsames Laden der Ressource. Das größte Bild selbst braucht Zeit zum Herunterladen. Ein 2 MB Hero Bild auf einer langsamen Verbindung kostet Sekunden. Die Lösung sind moderne Bildformate (WebP, AVIF), korrekte Dimensionen für den Viewport und der richtige Loading Hinweis.

Client seitiges Rendern. Eine Seite, die nichts rendert, bis JavaScript läuft und Daten lädt, hat ein LCP gleich der JavaScript Boot Zeit. Single Page Applications ohne Server seitiges Rendering zeigen auf realen Smartphones häufig LCP über 4 Sekunden.

Schriftladung. Ein spät erscheinendes Textelement, das zum LCP befördert wird, kann auf eine Webschrift warten. Font display swap und ein größenangepasster Fallback verhindern, dass der Text zurückgehalten wird.

Die Behebungssequenz für LCP ist immer dieselbe. Identifizieren Sie das LCP Element. Messen Sie, wie es geladen wird. Entfernen Sie das langsamste Glied der Kette.

Interaction to Next Paint (INP)

INP wurde im März 2024 die offizielle Interaktivitätsmetrik und löste FID ab. Der entscheidende Unterschied: FID maß nur die allererste Eingabe, INP misst jede Eingabe und meldet die schlechteste.

Die INP Schwellwerte für 2026 sind ebenfalls stabil.

• Gut: 200 ms oder weniger
• Verbesserungsbedürftig: 200 bis 500 ms
• Schlecht: mehr als 500 ms

INP wird als die schlechteste (oder fast schlechteste) beobachtete Interaktionslatenz der Sitzung gemeldet. Der Browser verfolgt jeden Klick, Tap und Tastendruck, misst die Zeit von der Eingabe bis zum nächsten Paint und liefert die längste als INP der Seite für diese Sitzung.

INP scheitert aus einem Grund. Der Main Thread ist blockiert, wenn der Nutzer interagiert. JavaScript läuft auf dem Main Thread, Layout läuft auf dem Main Thread, Paint läuft auf dem Main Thread. Wenn ein langer JavaScript Task in Bearbeitung ist, während der Nutzer einen Button klickt, bleibt der Klick in der Warteschlange, bis der Task fertig ist. Das sichtbare Ergebnis ist ein Button, der eine halbe Sekunde nicht reagiert.

Die fünf häufigsten Ursachen für schlechtes INP.

Lange JavaScript Tasks. Eine Funktion, die 300 ms läuft, blockiert den Main Thread für 300 ms. Häufige Übeltäter sind große synchrone Schleifen, Deserialisierung großer JSON Daten und komplexe State Berechnungen in Single Page Apps.

Third Party Skripte. Analytics, Werbung, A/B Testing, Tag Manager. Jedes lädt auf dem Main Thread, jedes kann in unvorhersehbaren Momenten einen langen Task auslösen.

Schwere Event Handler. Ein Click Handler, der zu viel Arbeit in einer einzigen Funktion erledigt. Klick löst einen Routenwechsel aus, Routenwechsel lädt Daten, Daten lösen ein schweres Render aus. Der Nutzer hat einmal geklickt und 600 ms gewartet.

React oder Vue Render Stürme. Ein State Wechsel, der das Rendern des gesamten Baums auslöst, während der Nutzer mitten im Scrollen oder Tappen ist.

Animationsruckler während der Interaktion. Ein CSS Übergang oder eine JavaScript Animation, die den Main Thread hält, während der Nutzer scrollen oder klicken will.

Das Werkzeugset zur Behebung von INP ist gut etabliert. Lange Tasks in kleinere Stücke zerlegen mit scheduler.yield(), requestIdleCallback oder einfach setTimeout(fn, 0). Schwere Arbeit in einen Web Worker verschieben. Nicht kritische Third Party Skripte hinter einer Nutzerinteraktion verzögern. React Komponenten memoisieren und useDeferredValue für nicht dringenden State nutzen. Prüfen, was synchron bei jeder Interaktion läuft, und entscheiden, was später laufen kann.

Cumulative Layout Shift (CLS)

CLS misst die visuelle Instabilität der Seite. Jedes Mal, wenn etwas auf dem Bildschirm unerwartet verrutscht, steigt CLS. Die Metrik ist einheitslos, berechnet als Summe der Layout Shift Werte während der Sitzung.

Die CLS Schwellwerte für 2026.

• Gut: 0,1 oder weniger
• Verbesserungsbedürftig: 0,1 bis 0,25
• Schlecht: mehr als 0,25

Ein einzelner Layout Shift Wert ist der Impact Faktor mal der Distance Faktor. Ein Bild, das die halbe Seite um zehn Prozent des Viewports nach unten schiebt, wird mit 0,05 bewertet. Zwei solche Verschiebungen in einer Sitzung summieren sich auf 0,10, knapp an der Grenze. Drei katapultieren die Seite in den schlechten Bereich.

Die vier Ursachen, die den Großteil aller CLS Probleme ausmachen.

Bilder und Videos ohne Dimensionen. Wenn der Browser die Größe eines Bildes erst nach dem Laden kennt, reserviert er keinen Platz, rendert den Inhalt drumherum und verschiebt alles nach unten, sobald das Bild ankommt. Setzen Sie immer width und height auf Bildern und Videos, oder nutzen Sie das CSS Aspect Ratio Äquivalent.

Dynamisch eingefügter Inhalt. Anzeigen, Embeds, Banner, Benachrichtigungen, die nach dem ersten Render in das DOM eingefügt werden, verschieben alles darunter. Die Lösung ist, vorab Platz zu reservieren, auch wenn der Inhalt noch nicht geladen ist, indem Sie eine Mindesthöhe auf dem Container setzen.

Webschriften, die einspringen. Wenn eine Webschrift fertig lädt und die Fallback Schrift ersetzt, fließt der Text oft neu, weil die Metriken abweichen. Die Lösung ist font-display: swap zusammen mit dem CSS Deskriptor size-adjust in der @font-face Regel, der die Fallback Schrift auf die Metriken der Webschrift skaliert und den sichtbaren Sprung entfernt.

Animationen, die das Layout beeinflussen. Ein CSS Übergang auf top, left, width oder height löst bei jedem Frame ein Layout Reflow aus. Animieren Sie stattdessen transform und opacity, beides kann der Browser ohne Layout Auswirkung verarbeiten.

CLS ist die einfachste der drei Metriken zu beheben, sobald das verursachende Element gefunden ist. Die Layout Instability API in Chrome DevTools (Performance Panel, dann “Web Vitals” oder “Experience” Track) markiert jede Verschiebung mit dem betroffenen DOM Knoten.

Lab Daten versus Field Daten

Die zwei Wege, Core Web Vitals zu messen, dienen unterschiedlichen Zwecken. Sie zu verwechseln führt zu verschwendeter Optimierungsarbeit.

Lab Daten stammen aus einem synthetischen Test. Lighthouse, der Lab Bereich von PageSpeed Insights, WebPageTest, alle simulieren ein Laden auf einem kontrollierten Gerät unter einer kontrollierten Netzwerkverbindung. Das Ergebnis ist reproduzierbar und nützlich zur Diagnose. Ein Lab Score von 95 in Lighthouse zeigt, dass die Seite schnell sein kann.

Field Daten stammen von echten Chrome Nutzern. CrUX ist der öffentliche Datensatz, monatlich aktualisiert. Der Field Bereich von PageSpeed Insights, die Chrome UX Report API und der Core Web Vitals Bericht in Search Console lesen alle aus CrUX. Field Daten sind das, was Google zur Bewertung Ihrer Seite für das Ranking heranzieht.

Eine Seite kann in Lighthouse 100 erreichen und in CrUX scheitern. Die Diskrepanz kommt vom Geräte und Netzwerkmix Ihrer echten Besucher gegenüber dem simulierten Profil. Lighthouse nutzt standardmäßig ein Moto G4 auf einer langsamen 4G Verbindung. Ihre echten Nutzer sind möglicherweise auf älteren Android Smartphones in schwächeren Netzwerken oder auf Tablets, die JavaScript langsamer ausführen, als das Lab annimmt.

Der umgekehrte Fall tritt ebenfalls auf. Eine Seite mit einem Lighthouse Score von 60 kann CrUX bestehen, weil echte Nutzer überwiegend auf schnelleren Geräten unterwegs sind als das Lab simuliert.

Behandeln Sie Lab Daten als Diagnosewerkzeug. Sie zeigen, was ein optimiertes Gerät sehen sollte, und sie liefern Stack Traces, Render Timelines und klare Vorher Nachher Vergleiche. Behandeln Sie Field Daten als Urteil. Sie zeigen, was Ihre echten Nutzer sehen, und sie entscheiden, ob die Core Web Vitals Schwelle bestanden oder verfehlt wird.

Der Zyklus lautet: Seite ändern, im Lab prüfen, dass die Änderung wirkt, dann 28 Tage warten, bis CrUX die Änderung in den Field Daten widerspiegelt.

Das Playbook für jede Metrik

Jede Metrik hat ein wiederkehrendes Playbook. Field Daten zuerst lesen, im Lab diagnostizieren, die zugrundeliegende Ursache beheben, im Lab verifizieren, dann auf Field Daten warten.

LCP Playbook.

1. PageSpeed Insights für die URL öffnen, den Field Daten Bereich anschauen.
2. Wenn die Seite LCP nicht besteht, scrollen Sie zu den Diagnoseangaben. Das größte Element ist benannt.
3. Chrome DevTools Performance Panel öffnen, die Seite mit Throttling neu laden (Slow 4G, 4x CPU Slowdown).
4. Das LCP Element in der Timeline finden. Schauen Sie, was es blockiert hat. Häufige Übeltäter in der Reihenfolge: Server Antwort, render blockierendes CSS, render blockierendes JavaScript, langsames Bildladen.
5. Die kleinste Korrektur anwenden, die die dominante Ursache adressiert. Server seitiges Rendering für SPA Seiten, modernes Bildformat und explizite Dimensionen für Bild LCP, async oder defer für blockierende Skripte.
6. Im Lab verifizieren, dass LCP unter 2,5 Sekunden fällt.
7. Datum notieren. Field Daten spiegeln die Änderung 28 Tage später in CrUX wider.

INP Playbook.

1. Den Core Web Vitals Bericht in Search Console öffnen. URLs finden, die INP nicht bestehen.
2. Auf einem echten Smartphone oder im DevTools Mobile Emulator die scheiternde Interaktion reproduzieren.
3. Performance Panel öffnen, ab vor dem Klick aufzeichnen. Nach dem nächsten Paint stoppen.
4. Den langen Task finden, der den Main Thread blockiert hat. Das Flame Chart zeigt den Funktionsnamen.
5. Eine der Standardlösungen anwenden. Mit scheduler.yield ausgliedern. Die Arbeit hinter requestIdleCallback verschieben. In einen Web Worker auslagern. Den synchronen Algorithmus durch einen inkrementellen ersetzen.
6. Im Lab verifizieren, dass die Interaktion in unter 200 ms abschließt.
7. Auf CrUX Bestätigung in den Field Daten warten.

CLS Playbook.

1. Chrome DevTools, Performance Panel, einen Seitenladevorgang mit aktiviertem Web Vitals Overlay aufnehmen.
2. Jeder Layout Shift erscheint als rotes Rechteck auf dem betroffenen Element mit einem Beitragswert.
3. Die Ursache identifizieren. Bild ohne Dimensionen, spät eingefügte Anzeige, Schriftwechsel, Animation auf Layout Eigenschaft.
4. Die Korrektur anwenden. width und height auf Bildern setzen. Container Platz für dynamischen Inhalt reservieren. font-display: swap mit size-adjust nutzen. transform statt top animieren.
5. Verifizieren, dass der Layout Shift in der Aufzeichnung verschwindet.
6. Auf Field Daten warten.

Das Playbook funktioniert, weil jede Metrik einen kleinen, gut bekannten Satz von Grundursachen hat. Sobald Sie wissen, welche Grundursache vorliegt, ist die Korrektur mechanisch.

Wann Core Web Vitals Rankings tatsächlich bewegen

Die ehrliche Frage, die jedes Team irgendwann stellt. Wir ranken seit Jahren auf Platz zehn, schiebt uns grünes Core Web Vitals auf Platz fünf?

Die ehrliche Antwort. Wahrscheinlich nicht aus eigener Kraft.

Google ist in dieser Frage konsistent. Core Web Vitals ist ein Tiebreaker, kein primärer Ranking Faktor. Wenn zwei Seiten in Relevanz, Inhaltsqualität und Autorität gleichauf liegen, kann die Seite mit besseren Core Web Vitals den Tiebreak gewinnen. Wenn sich Seiten in diesen primären Signalen unterscheiden, schließt Core Web Vitals die Lücke nicht.

Der Ranking Effekt von Core Web Vitals zeigt sich am deutlichsten in drei Szenarien.

Mobile Commerce Wettbewerb. Zwei Produktseiten, ähnliche Relevanz, eine lädt in 2 Sekunden, die andere in 5 Sekunden. Die schnelle Seite tendiert dazu, die langsame mit der Zeit zu überholen, vor allem in stark umkämpften Kategorien, in denen jedes Signal zählt.

Seiten am Rand. Eine Seite, deren Core Web Vitals an der Grenze zum schlechten Bereich liegen, und eine Stufe der Seiten rutscht in den failenden Bereich, diese Stufe verliert Ranking. Wenn Sie die fehlschlagenden Seiten zurück in den guten Bereich bringen, kehrt das frühere Ranking zurück. Der Effekt ist beidseitig und manchmal scharf.

Engagement Signale über Nutzerverhalten. Das ist der längerfristige Effekt. Eine schnelle, stabile Seite hält Nutzer länger. Niedrigere Absprungrate, mehr Seiten pro Sitzung, bessere Wiederkehrrate. Diese Engagement Signale korrelieren mit Ranking, und sie sind selbst eine Folge guter Core Web Vitals.

Die Szenarien, in denen Core Web Vitals keine Rankings bewegt.

Eine Seite ohne thematische Autorität. Eine neue Seite kann die schnellste in ihrer Kategorie sein und trotzdem unter älteren Seiten mit schwacher Performance ranken. Autorität ist das dominante Signal, bis sie etabliert ist.

Eine Seite mit klarer Inhaltslücke. Eine Seite, die die Suchintention nicht gut beantwortet, rankt nicht über einer Seite, die es tut, unabhängig von der Geschwindigkeit.

Themen, in denen eine Seite dominiert. Wenn eine einzelne Seite klare Autorität in einer Nische aufgebaut hat, brechen schnellere Wettbewerber selten allein über Geschwindigkeit ein. Sie brauchen zuerst Inhaltstiefe und Links.

Die Faustregel, die seit mehreren Jahren hält: Streben Sie grüne Core Web Vitals an, weil sie die Nutzererfahrung verbessern, den Tiebreak sichern, wenn Relevanz nahe liegt, und die Engagement Signale stützen, die sich mit der Zeit aufaddieren. Streben Sie grüne Core Web Vitals nicht als Ranking Abkürzung an, weil sie keine ist.

Für einen tieferen Blick darauf, wie Geschwindigkeit mit dem Rest des technischen SEO interagiert, deckt die technische SEO Audit Checkliste die volle Oberfläche der Probleme ab, die mit Core Web Vitals zusammenwirken. Für Traffic, der von KI Engines abhängt, unterstützt dieselbe Geschwindigkeitsarbeit AI ready Seiten, da sowohl Google als auch KI Crawler schnelle, stabile Renderings bevorzugen.

Fazit

Core Web Vitals ist ein kleines Set von Metriken, das das meiste von dem abbildet, was echte Nutzer spüren, wenn eine Seite langsam ist. LCP für Laden, INP für Interaktivität, CLS für visuelle Stabilität. Jede hat einen bekannten Schwellwert, einen bekannten Satz Grundursachen und eine bekannte Korrekturreihenfolge. Lab Werkzeuge zeigen Ihnen, ob die Korrektur funktioniert. Field Daten, der 28 Tage rollende CrUX Datensatz, zeigt Ihnen, ob echte Nutzer die Verbesserung sehen.

Hören Sie auf, in Lighthouse 100 zu jagen. Streben Sie grüne Field Daten an. Die zwei sind unterschiedliche Ziele, und das zweite ist das, was für Nutzer und Ranking zählt.

Für die Audit Arbeit rund um Core Web Vitals, kombinieren Sie diese mit einer Meta Tags Prüfung und einer regelmäßigen SEO Crawler Routine. Geschwindigkeitsarbeit und Crawl Arbeit teilen Grundursachen, render blockierende Ressourcen, Server Antwortzeit, übergroße Assets. Beide Audits laufen zusammen effizienter als jedes für sich.

Wenn Sie ein Werkzeug brauchen, um Ihre Seite zu crawlen und Geschwindigkeitsprobleme neben dem Rest des technischen SEO zu finden, laden Sie Seodisias kostenlos herunter. Es läuft lokal auf Ihrer Maschine, hat keine URL Beschränkungen und meldet die Seitensignale, die Core Web Vitals beeinflussen, als Teil jedes Audits.