Core Web Vitals sind Googles drei zentrale Metriken für Nutzererfahrung: Interaction to Next Paint (INP) misst die Reaktionszeit bei Klicks und Eingaben (Schwellenwert: 200 ms), Largest Contentful Paint (LCP) die Ladezeit des größten sichtbaren Elements (2,5 s) und Cumulative Layout Shift (CLS) die visuelle Stabilität (0,1). Seit März 2024 hat INP den bisherigen First Input Delay (FID) ersetzt. Laut HTTP Archive scheitern rund 43 Prozent aller Websites am INP-Schwellenwert, was direkte Auswirkungen auf die Core Web Vitals und damit auf Google-Rankings hat.
Was ist INP und warum ist es wichtiger als FID?
FID maß nur die Verzögerung bei der allerersten Interaktion eines Nutzers mit der Seite. Das Problem: Die meisten Performance-Probleme treten später auf - beim Öffnen eines Menüs, beim Absenden eines Formulars oder beim Filtern von Produkten. INP bewertet dagegen alle Interaktionen während des gesamten Seitenbesuchs und nimmt den schlechtesten Wert (abzüglich der 2% schlechtesten Ausreißer) als Ergebnis.
Der INP-Wert setzt sich aus drei Phasen zusammen: Input Delay (die Zeit zwischen der Nutzer-Interaktion und dem Start der Event-Handler), Processing Time (die Ausführung der Event-Handler selbst) und Presentation Delay (die Zeit für Rendering und Compositing bis zum nächsten Frame). Alle drei Phasen zusammen müssen unter 200 Millisekunden liegen, um als gut zu gelten.
INP optimieren: Die drei Phasen im Detail
Die Input-Delay-Phase wird vor allem durch blockierende Aufgaben auf dem Main Thread verursacht. Lange JavaScript-Tasks (über 50ms) verhindern, dass der Browser auf Klicks oder Tastatureingaben reagieren kann. Die Lösung: Große Scripts aufteilen, Third-Party-Scripts verzögert laden und Arbeit über requestIdleCallback oder die Scheduler API in kleinere Einheiten zerlegen.
Die Processing-Phase betrifft Ihre Event-Handler direkt. Hier helfen effiziente DOM-Manipulationen, weniger Reflows und die Vermeidung synchroner Layout-Abfragen innerhalb von Event-Handlern. Moderne Frameworks wie Angular nutzen Change Detection mit OnPush, um unnötige Neuberechnungen zu vermeiden.
Die Presentation-Phase hängt von der Rendering-Komplexität ab. Vermeiden Sie aufwändige CSS-Animationen während Interaktionen, nutzen Sie CSS-Containment und reduzieren Sie die DOM-Größe. Websites mit über 1.500 DOM-Elementen zeigen messbar schlechtere INP-Werte.
- Input Delay: JavaScript-Tasks unter 50ms halten, Third-Party-Scripts verzögert laden
- Processing: Event-Handler schlank halten, keine synchronen Layout-Abfragen
- Presentation: DOM-Größe reduzieren, CSS-Containment nutzen, Rendering-Last minimieren
- Generell: Main-Thread-Blockaden mit Chrome DevTools Performance Tab identifizieren
LCP unter 2,5 Sekunden: Praxistipps
Largest Contentful Paint misst, wie schnell das größte sichtbare Element im Viewport geladen wird - meist ein Hero-Bild, eine Überschrift oder ein Video-Poster. Der Schwellenwert liegt bei 2,5 Sekunden. Laut Google-Daten haben Seiten mit einem LCP unter 2,5 Sekunden eine um 24 Prozent niedrigere Absprungrate als Seiten mit LCP über 4 Sekunden.
Die häufigsten LCP-Killer bei KMU-Websites: unkomprimierte Hero-Bilder (oft 2-5 MB statt 50-100 KB), fehlende Preload-Hints für kritische Ressourcen, render-blockierendes CSS aus nicht genutzten Frameworks und langsame Server-Antwortzeiten (TTFB über 800ms). Server Side Rendering (SSR) löst das TTFB-Problem, indem HTML bereits auf dem Server generiert wird.
- Hero-Bilder in WebP/AVIF konvertieren und responsiv ausliefern (srcset)
- LCP-Ressource mit <link rel='preload'> frühzeitig anfordern
- Kritisches CSS inline ausliefern, Rest verzögert nachladen
- TTFB unter 600ms halten durch Caching, CDN oder SSR/SSG
- fetchpriority='high' nur für das tatsächliche LCP-Element verwenden
CLS unter 0,1: Visuelle Stabilität sicherstellen
Cumulative Layout Shift misst, wie stark sich Seitenelemente während des Ladevorgangs verschieben. Ein CLS-Wert unter 0,1 gilt als gut. Layout-Verschiebungen sind besonders ärgerlich für Nutzer: Ein Klick auf einen Button trifft plötzlich die Werbeanzeige darüber, weil ein Bild nachgeladen wurde und den Inhalt nach unten geschoben hat.
Die wichtigsten Maßnahmen: Feste Abmessungen für Bilder und Videos angeben (width und height Attribute oder aspect-ratio in CSS), Webfonts mit font-display: swap oder optional laden, und dynamische Inhalte wie Cookie-Banner oder Chatwidgets in reservierten Bereichen platzieren. Besonders problematisch sind Third-Party-Embeds wie Google Maps oder Social-Media-Widgets, die ohne feste Höhe eingefügt werden.
Messen und Monitoring: Feld- vs. Labordaten
Ein entscheidender Punkt wird oft übersehen: Google nutzt für das Ranking ausschließlich Felddaten aus dem Chrome User Experience Report (CrUX) - nicht die Labordaten aus Lighthouse. Eine Seite kann im Lighthouse-Test perfekte Werte zeigen und trotzdem schlechte Core Web Vitals haben, weil reale Nutzer mit langsameren Geräten oder instabilen Verbindungen zugreifen.
Prüfen Sie Ihre Felddaten regelmäßig in der Google Search Console unter Core Web Vitals und in PageSpeed Insights im Abschnitt Felddaten. Für Websites mit wenig Traffic (unter 1.000 Besucher pro Monat) stehen oft keine Felddaten zur Verfügung - hier müssen Sie sich auf Labortests und Real User Monitoring (RUM) verlassen.
Fazit: Core Web Vitals als Wettbewerbsvorteil
Core Web Vitals sind kein theoretisches SEO-Thema, sondern messbare Nutzererfahrung. Mit INP als neuem Schwerpunkt belohnt Google Websites, die nicht nur schnell laden, sondern auch bei jeder Interaktion flüssig reagieren. Für KMU-Websites ist das eine Chance: Während große Portale mit ihren komplexen JavaScript-Anwendungen oft an INP scheitern, können schlanke, gut gebaute Unternehmensseiten hier punkten.
Wenn Sie wissen möchten, wie Ihre Website bei den aktuellen Core Web Vitals abschneidet, liefert ein detaillierter Blick auf die Core Web Vitals Grundlagen den passenden Einstieg.
