Core Web Vitals 2026: Was wirklich zählt

27. März 2026 #Core Web Vitals#Performance#SEO#INP#Web Performance

Core Web Vitals sind drei Messwerte von Google, die erfassen, wie sich eine Seite für echte Menschen anfühlt: LCP (lädt der Hauptinhalt schnell?), INP (reagiert die Seite zügig auf Klicks und Eingaben?) und CLS (springt das Layout während des Ladens herum?). Sie sind ein bestätigter, wenn auch kleiner Ranking-Faktor — ihr eigentlicher Hebel liegt aber bei der Conversion. Gemessen wird mit echten Nutzerdaten (Felddaten aus dem Chrome UX Report), nicht nur im Labor. Wer 2026 gut abschneiden will, optimiert für das 75. Perzentil seiner realen Besucher, nicht für den sauberen Lighthouse-Lauf auf dem MacBook.

TL;DR

Drei Metriken zählen: LCP (≤ 2,5 s), INP (≤ 200 ms), CLS (≤ 0,1) — jeweils am 75. Perzentil.
INP hat im März 2024 FID abgelöst und ist 2026 der häufigste Stolperstein, besonders bei JavaScript-lastigen Seiten.
Ranking-Effekt ist real, aber moderat. Der größere Gewinn: weniger Absprünge, mehr Abschlüsse.
Feld vor Labor. Lighthouse zeigt Potenzial, CrUX und RUM zeigen die Wahrheit.
Die meisten Probleme sind hausgemacht: zu viel JS, unkomprimierte Bilder, fehlende Größenangaben, Third-Party-Skripte.

Was die drei Metriken eigentlich messen

Vergiss für einen Moment die Abkürzungen. Die Core Web Vitals beantworten drei simple Nutzerfragen.

LCP – Largest Contentful Paint. Wann erscheint das größte sichtbare Element im Viewport? Meist ist das ein Hero-Bild, ein Headline-Block oder ein Video-Poster. LCP misst die wahrgenommene Ladegeschwindigkeit. Gut sind ≤ 2,5 Sekunden, alles über 4 Sekunden ist schlecht. Wichtig: Es geht nicht um „die Seite ist fertig”, sondern um den Moment, in dem das Wesentliche da ist.

INP – Interaction to Next Paint. Wie schnell reagiert die Seite, nachdem du etwas anklickst, tippst oder antippst? INP misst die Latenz aller Interaktionen während eines Seitenbesuchs und meldet (näherungsweise) den schlechtesten Wert. Ziel: ≤ 200 Millisekunden. Über 500 ms ist es schlecht. INP ist seit März 2024 offiziell Teil der Core Web Vitals und hat das alte FID (First Input Delay) ersetzt — ein deutlich strengerer Maßstab, weil INP die komplette Verarbeitung bis zum nächsten Frame erfasst, nicht nur die Verzögerung bis zum Start der Reaktion.

CLS – Cumulative Layout Shift. Wie stark verschiebt sich Inhalt unerwartet, während die Seite lädt? Jeder kennt das: Du willst auf „Akzeptieren” tippen, ein nachgeladenes Banner schiebt den Button weg, und du landest auf einer Werbung. CLS bündelt diese Ruckler in einem dimensionslosen Score. Ziel: ≤ 0,1.

Metrik	Was sie misst	Gut	Verbesserung nötig	Schlecht
LCP	Ladezeit des Hauptinhalts	≤ 2,5 s	2,5–4 s	> 4 s
INP	Reaktionszeit auf Interaktionen	≤ 200 ms	200–500 ms	> 500 ms
CLS	Visuelle Stabilität	≤ 0,1	0,1–0,25	> 0,25

Ein Punkt, der ständig untergeht: Diese Schwellen gelten am 75. Perzentil. Heißt — drei von vier deiner echten Besucher müssen den „guten” Wert erreichen, sonst gilt die Metrik insgesamt nicht als bestanden. Dein eigenes schnelles Gerät im schnellen Büro-WLAN ist nicht repräsentativ. Das alte Android-Mittelklasse-Handy im Zug mit schwankendem Netz schon eher.

Zählen die Core Web Vitals fürs Ranking — wirklich?

Ja, aber lass uns ehrlich über das Gewicht reden, denn hier kursiert viel Unsinn.

Core Web Vitals sind Teil von Googles Page-Experience-Signalen. Sie sind ein echter, aber moderater Ranking-Faktor. Sie machen aus einer mittelmäßigen Seite keinen Spitzenplatz, und ein perfekter LCP rettet dünnen Content nicht. Google selbst formuliert es als Tiebreaker-Logik: Bei vergleichbarer Relevanz und Qualität bekommt die bessere Nutzererfahrung den Vorzug. In umkämpften Nischen, in denen zehn Seiten inhaltlich gleichauf liegen, kann genau das den Unterschied machen.

Der größere Hebel liegt woanders, und das sagen wir unseren Kunden in jedem Erstgespräch: Conversion und Absprungrate. Jede zusätzliche Sekunde Ladezeit kostet Abschlüsse — das ist über Jahre und Branchen hinweg gut belegt. Ein Shop, dessen LCP von 4,5 auf 2 Sekunden fällt, gewinnt nicht in erster Linie Rankings, er gewinnt Käufe. Wer Performance nur als SEO-Hausaufgabe sieht, optimiert für den falschen Grund. Sieh es als UX-Investition, die nebenbei auf das Ranking einzahlt.

Noch ein verbreitetes Missverständnis: Core Web Vitals werden pro URL und pro Gerätetyp (Mobile/Desktop) bewertet, nicht pauschal für die ganze Domain. Deine Startseite kann grün sein, während die Produktdetailseiten mit dem schweren Konfigurator-Widget rot sind. Genau dort, wo das Geld verdient wird.

Häufige Ursachen schlechter Werte — und was dahintersteckt

Aus unserer Audit-Praxis: Die Probleme wiederholen sich. Selten ist es exotisch, fast immer ist es das Gleiche.

Schlechter LCP

Riesige, unkomprimierte Bilder. Das Hero-Bild ist ein 2,8-MB-PNG, das auf 1200 px skaliert wird. Klassiker.
Render-blockierendes CSS und JavaScript im <head>, das den Browser ausbremst, bevor er überhaupt zeichnen kann.
Langsame Server-Antwort (TTFB). Wenn der Server 1,5 Sekunden für das erste Byte braucht, ist der LCP-Kampf schon halb verloren, bevor das Frontend überhaupt anfängt.
Fehlende Priorisierung. Das LCP-Bild wird lazy-geladen, obwohl es above the fold liegt — der Browser holt es zu spät.

Schlechter INP

Zu viel JavaScript auf dem Main Thread. Lange Tasks blockieren die Verarbeitung von Klicks. Hydration-schwere SPA-Frameworks, die beim Laden den kompletten Zustand aufbauen, sind hier die üblichen Verdächtigen.
Teure Event-Handler, die bei jedem Klick synchron rendern oder große Listen neu aufbauen.
Third-Party-Tags — Tag-Manager, A/B-Test-Tools, Chat-Widgets, Tracking. Sie laufen mit auf deinem Main Thread und stehlen Reaktionszeit.

Schlechter CLS

Bilder und iframes ohne width/height-Angabe. Der Browser weiß nicht, wie viel Platz er reservieren soll, und schiebt nach.
Web Fonts, die einen späten Reflow auslösen (FOUT/FOIT), wenn der Text plötzlich in der echten Schrift umbricht.
Dynamisch eingefügte Inhalte — Cookie-Banner, Promo-Leisten, Ads — die ohne reservierten Platz oben hereingeschoben werden.

Konkrete Fixes, die in der Praxis ziehen

Genug Theorie. Das hier setzen wir bei fast jedem Projekt um.

Für LCP:

Bilder modern ausliefern: AVIF oder WebP, korrekt dimensioniert via srcset/sizes. Das LCP-Bild nicht lazy-loaden, sondern priorisieren:

<img src="hero.avif" width="1200" height="600"
     fetchpriority="high" decoding="async" alt="…">

Für die wichtigste Ressource einen Preload setzen, statt darauf zu warten, dass der Parser sie findet:

<link rel="preload" as="image"
      href="hero.avif" fetchpriority="high">

Render-blockierendes CSS minimieren, kritisches CSS inline, den Rest nachladen. Schriften mit font-display: swap und Preconnect zum Font-Host.
TTFB angehen: Caching, CDN, ein realistisches Server-Setup. Statische Seiten oder Edge-Rendering schlagen jede Frontend-Mikrooptimierung, wenn der Server das Nadelöhr ist.

Für INP:

JavaScript reduzieren. Klingt banal, ist der eigentliche Knackpunkt. Weniger ausliefern, Code-Splitting, nicht-kritisches JS verzögern.
Lange Tasks aufbrechen. Arbeit, die nicht sofort sichtbar sein muss, in einen Yield-Punkt verlagern — scheduler.yield() wo verfügbar, sonst setTimeout(…, 0) oder requestIdleCallback.
Schweres Rechnen aus dem Main Thread in einen Web Worker auslagern.
Third-Party-Skripte auf den Prüfstand: Brauchst du wirklich vier Tracking-Tools? Jedes geht zulasten von INP. Lade, was geht, mit async/defer oder erst nach Interaktion.

Für CLS:

Immer width und height (oder aspect-ratio) auf Bilder, Videos, iframes.
Platz für dynamische Inhalte vorab reservieren — Banner, Ads, eingebettete Widgets bekommen einen festen Slot.
Schriften mit size-adjust und passenden Fallbacks so wählen, dass der Wechsel keinen Reflow auslöst.

Wie man richtig misst: Feld vor Labor

Das ist der Teil, an dem die meisten scheitern — nicht an der Technik, sondern am Verständnis, welche Zahl überhaupt zählt.

Felddaten (RUM)

Felddaten kommen von echten Nutzern, auf echten Geräten, in echten Netzen. Das ist die Datenbasis, mit der Google bewertet. Quellen:

Chrome UX Report (CrUX): Aggregierte Daten echter Chrome-Nutzer, das 75. Perzentil über 28 Tage. Genau das fließt ins Ranking ein.
Google Search Console, Bericht „Core Web Vitals”: deine URLs, gruppiert nach Status, auf CrUX-Basis.
PageSpeed Insights: zeigt oben die CrUX-Felddaten (sofern genug Traffic vorhanden), darunter die Labordaten.
Eigenes RUM via web-vitals-Library — die ehrlichste Quelle, weil du deine INP-Probleme bis zur auslösenden Interaktion zurückverfolgen kannst.

import { onLCP, onINP, onCLS } from 'web-vitals';
onLCP(sendToAnalytics);
onINP(sendToAnalytics);
onCLS(sendToAnalytics);

Labordaten

Labordaten entstehen in einer kontrollierten, simulierten Umgebung: Lighthouse, der Performance-Tab in den Chrome DevTools, WebPageTest. Reproduzierbar, perfekt zum Debuggen — aber synthetisch. Wichtig: Lighthouse misst kein INP. Dafür gibt es im Labor den Proxy „Total Blocking Time” (TBT), der gut mit INP korreliert, ihn aber nicht ersetzt. INP braucht echte Interaktionen, und die liefert nur das Feld.

	Felddaten (CrUX/RUM)	Labordaten (Lighthouse)
Basis	Echte Nutzer	Simulierte Umgebung
INP messbar?	Ja	Nein (nur TBT als Proxy)
Fließt ins Ranking?	Ja	Nein
Stärke	Realität, Repräsentativität	Reproduzierbar, gut zum Debuggen
Schwäche	Braucht Traffic-Volumen, träge	Nicht ranking-relevant, kann täuschen

Die Faustregel, die uns vor vielen Fehlleitungen bewahrt hat: Labordaten zum Diagnostizieren und Fixen, Felddaten zum Beurteilen, ob es geklappt hat. Wer nur auf den grünen Lighthouse-Score schielt, optimiert für ein Gerät, das keiner seiner Kunden benutzt. Und CrUX reagiert träge — der rollende 28-Tage-Schnitt zeigt Verbesserungen erst nach Wochen vollständig. Geduld gehört dazu.

Was wir 2026 anders machen als früher

Drei Verschiebungen prägen die Arbeit gerade. Erstens: INP ist die neue Hauptbaustelle. Seit es FID abgelöst hat, fallen viele JavaScript-schwere Seiten durch, die mit dem alten, laschen FID noch grün waren. Wer ein React-, Vue- oder Angular-Setup fährt, sollte INP zur Priorität machen. Zweitens: Mobile First ist keine Floskel. Der typische Nutzer kommt mit einem Mittelklasse-Android, nicht mit dem Flaggschiff. Drosselt eure DevTools auf „Slow 4G” und „4x CPU”, dann seht ihr, was eure Besucher sehen. Drittens: Architektur schlägt Mikrooptimierung. Die größten Sprünge kommen nicht vom letzten gequetschten Kilobyte, sondern von der Grundentscheidung — Server-Side Rendering oder statische Generierung statt einer schweren Client-SPA, sinnvolles Caching, sparsamer Umgang mit Third-Party-Code.

Und ein Hinweis zu Vanity-Metriken: Ein perfekter Performance-Score ist nett fürs Ego, aber kein Selbstzweck. Wir haben Seiten mit Score 100 gesehen, die im Feld trotzdem rot waren — und umgekehrt. Misstraut der einen schönen Zahl. Schaut auf das 75. Perzentil eurer echten Nutzer.

Wenn ihr nicht sicher seid, ob eure Werte halten, was Lighthouse verspricht, oder INP euch im Feld einbricht und ihr nicht wisst, welche Interaktion schuld ist: Genau solche Audits machen wir bei Rocket-Monkeys regelmäßig — Felddaten lesen, die Ursache finden, gezielt fixen, statt blind zu raten. Schreibt uns für ein unverbindliches Erstgespräch an info@rocket-monkeys.com. Wir schauen uns eure CrUX-Daten an und sagen ehrlich, wo der Hebel sitzt — und wo sich der Aufwand schlicht nicht lohnt.