Core Web Vitals 2026: Was Google jetzt wirklich misst.

Die drei aktiven Kennzahlen 2026

Core Web Vitals bestehen 2026 aus genau drei Metriken: LCP, INP und CLS. Google misst diese über das Chrome User Experience Report (CrUX) und nutzt sie als Teil des Page Experience Signals im Ranking-Algorithmus.^[1]

Wichtig: Es reicht nicht, in einer Metrik gut zu sein. Alle drei müssen die jeweiligen Schwellenwerte für 'good' unterschreiten, damit deine Seite als 'good URL' eingestuft wird.

• LCP (Largest Contentful Paint). Wann ist das größte sichtbare Element fertig geladen? Ziel: unter 2,5 Sekunden.
• INP (Interaction to Next Paint). Wie schnell reagiert die Seite auf Interaktion? Ziel: unter 200 Millisekunden.
• CLS (Cumulative Layout Shift). Wie stark verschiebt sich das Layout nach dem ersten Render? Ziel: unter 0,1.

Eine Seite, die in zwei Metriken im grünen Bereich liegt und in einer im roten, bekommt von Google das Label 'needs improvement'. Das reicht nicht für volles Ranking-Wohlwollen.

Was LCP wirklich misst und wie du es senkst

LCP ist die Zeit zwischen dem ersten Pixel auf dem Viewport und dem Moment, in dem das größte sichtbare Element vollständig gerendert ist. In den meisten Fällen ist das größte Element ein Hero-Image, ein großer Text-Block oder ein Video-Frame.

Was LCP typischerweise verzögert:

• Unkomprimierte Bilder. Ein Hero-Image mit 1,2 MB statt 80 KB ist der häufigste Killer. Lösung: WebP, AVIF, responsive sizes (srcset).
• Render-blocking Resources. CSS- und JS-Dateien, die im Head geladen werden und das Rendering blockieren. Lösung: kritisches CSS inline, der Rest mit defer oder async.
• Late-Loading Custom Fonts. Wenn Fonts erst spät geladen werden, rendert der Hero-Text gar nicht oder ploppt verzögert auf. Lösung: font-display: swap setzen, kritische Fonts preloaden.
• Schlechte Server-Antwortzeiten. TTFB über 600 ms killt deine LCP automatisch. Lösung: CDN, Caching, schlanke Backend-Logik.

Realistisches Ziel: unter 2,5 Sekunden auf 75 % aller realen Page-Visits. Auf einem schnellen Wifi reicht das nicht - du brauchst gute Werte auch auf 4G in der Bahn.

INP statt FID - der Wechsel von 2024

Im März 2024 hat Google First Input Delay (FID) durch Interaction to Next Paint (INP) ersetzt. Der Unterschied: FID misst nur die erste Interaktion, INP misst Reaktionszeit über die gesamte Session und liefert deshalb realistischere Daten.

INP wird in drei Schritten berechnet: Input Delay (Zeit bis JavaScript reagiert), Processing (Zeit für JS-Verarbeitung), Presentation Delay (Zeit bis nächster Frame). Die Summe muss unter 200 Millisekunden bleiben.

• JavaScript Long Tasks. Tasks über 50 ms blocken den Main Thread und verzögern INP. Lösung: Long Tasks in kleinere Chunks splitten (yield to main).
• Drittanbieter-Scripts. Tracker, Chat-Widgets, A/B-Test-Tools. Alles, was nicht kritisch ist, async laden oder ganz weglassen.
• Event-Handler ohne Optimierung. Click-Handler, die schwere DOM-Operationen ausführen, blocken die Wahrnehmung. Lösung: requestIdleCallback für nicht-zeitkritische Arbeit.

INP ist deutlich strikter als FID. Viele Seiten, die früher 'gut' waren, sind seit dem Wechsel auf 'needs improvement' gefallen. Wer es noch nicht geprüft hat, sollte das diese Woche tun.

CLS und visuelle Stabilität

Cumulative Layout Shift misst, wie viel sich Elemente auf der Seite verschieben, nachdem sie initial gerendert wurden. Jeder kennt das: Du willst auf einen Button klicken, in dem Moment lädt ein Banner nach, der Button springt nach unten, du klickst stattdessen auf die Werbung. Das ist Layout Shift, und Google bestraft es.

Was CLS verursacht:

• Bilder ohne Dimensionen. Wenn du width und height nicht setzt, weiß der Browser nicht, wie viel Platz er reservieren soll. Lösung: immer Dimensionen angeben, auch für responsive Bilder.
• Iframes und Embeds. YouTube-Embeds, Tweet-Embeds, Ads. Alles, was nachträglich Platz beansprucht. Lösung: feste Container mit aspect-ratio und reservierter Höhe.
• Web Fonts mit Fallback-Shift. Wenn der Custom-Font lädt, ändert sich die Buchstaben-Breite, und alles verrutscht. Lösung: size-adjust auf @font-face oder font-display: optional.
• Animationen, die Layout-Properties anfassen. Animationen auf width, height oder margin zwingen das Layout neu zu rechnen. Lösung: nur transform und opacity animieren.

Ziel: CLS unter 0,1 auf 75 % aller Page-Visits. Diese Metrik ist einfach zu erfüllen, wenn du sie kennst - und brutal frustrierend, wenn du sie ignorierst.

Mess-Workflow ohne Lighthouse-Lottery

Eine der häufigsten Frustrationen: Du misst deine Seite mit Lighthouse und bekommst 95/100. Eine Woche später misst der Kunde mit demselben Tool 62/100. Was ist los?

Lab-Daten (Lighthouse, PageSpeed Insights) testen unter standardisierten Bedingungen. Field-Daten (CrUX, Search Console) messen, was echte Nutzer erleben. Beide haben ihre Berechtigung, aber Google rankt auf Field-Daten, nicht auf Lab-Werten.

• Search Console > Core Web Vitals Report. Die einzige Quelle, die zeigt, wie deine echten Nutzer deine Seite erleben. Mindestens einmal pro Woche prüfen.
• Chrome UX Report (CrUX) Dashboard. Public Field-Daten für alle Sites mit genug Traffic. Vergleich zu Wettbewerbern.
• Lighthouse für Debugging. Nicht für Reporting. Lighthouse zeigt dir, was du fixen musst, aber nicht, ob es geholfen hat - das siehst du erst in den Field-Daten 28 Tage später.
• RUM-Tools (Real User Monitoring). Für größere Sites: Tools wie SpeedCurve oder Calibre messen echte Nutzer in deinem eigenen Setup. Lohnt sich ab ~100k Sessions pro Monat.

Workflow in der Praxis: Field-Daten anschauen → Probleme identifizieren → Lab-Tools für Root-Cause → Fix implementieren → 28 Tage warten → Field-Daten erneut prüfen. Schneller wirst du nicht.

Fazit: Performance ist kein Optional, sondern Ranking-Fundament

Core Web Vitals sind 2026 keine theoretischen Metriken mehr. Sie sind Ranking-Faktoren, und sie sind transparent: Du kannst sie in der Search Console täglich nachvollziehen. Wer hier schlecht ist, fällt - auch wenn der Content top ist.

Die drei Kennzahlen LCP, INP und CLS messen unterschiedliche Dinge, aber alle drei haben dasselbe Ziel: dass dein Besucher schnell sieht, schnell interagiert und nicht durch nachladenden Müll gestört wird.

Wer diese drei sauber bekommt, hat in 80 % der Fälle eine technisch solide Seite. Wer nicht, hat einen unsichtbaren Anker, der alle weiteren SEO-Bemühungen ausbremst. Du kannst die besten Backlinks haben - wenn dein LCP bei 6 Sekunden liegt, rankst du trotzdem nicht.

Kein Fluff. Nur Systeme. Performance ist kein Sprint-Projekt, sondern eine Disziplin. Wer sie ernst nimmt, hat einen technischen Vorteil, den Wettbewerber mit gleichen Keywords nicht aufholen können.

Quellen

1. Web Vitals - Essential metrics for a healthy site Google web.dev · 2026 web.dev/articles/vitals
2. Interaction to Next Paint (INP) replacing FID - announcement Chrome for Developers Blog · 2024 developer.chrome.com