Core Web Vitals & INP 2026

Im März 2024 hat Google Interaction to Next Paint (INP) offiziell als Core Web Vital eingeführt und damit First Input Delay (FID) abgelöst. Das klingt zunächst nach einer technischen Randnotiz, ist es aber nicht. FID maß lediglich die Verzögerung bis zur ersten Verarbeitung eines Inputs — und ignorierte dabei, wie lange es dauerte, bis der Browser tatsächlich etwas auf dem Bildschirm aktualisierte. INP erfasst genau das: die gesamte Latenz vom Nutzer-Klick bis zur sichtbaren Reaktion der Seite, gemessen über alle Interaktionen einer Session, nicht nur die erste.

Für Entscheider im DACH-Mittelstand hat dieser Wechsel zwei direkte Konsequenzen. Erstens: Seiten, die FID-technisch sauber wirkten, können bei INP deutlich schlechter abschneiden — weil sie zwar schnell auf den ersten Tap reagieren, aber bei nachfolgenden Klicks (Formular-Eingaben, Filter-Aktionen, Tab-Wechsel) ins Stocken geraten. Zweitens: Google verwendet INP als Rankingsignal im Page Experience Update. Eine schlechte INP-Note kann Positionen kosten, auch wenn LCP und CLS im grünen Bereich liegen.

Aus meiner Praxis mit B2B-Websites im DACH-Raum sehe ich regelmäßig, dass JavaScript-lastige Plattformen — insbesondere React- und Next.js-Setups mit umfangreichem Client-Rendering — bei INP strukturell benachteiligt sind, solange bestimmte Architektur-Entscheidungen nicht bewusst getroffen werden. Das ist kein Argument gegen moderne Frameworks, aber ein Argument dafür, Performance von Anfang an zu priorisieren.

Core Web Vitals sind keine akademische Übung. Sie modellieren drei konkrete Nutzererlebnisse: Wie schnell wird der wichtigste Inhalt sichtbar? Wie reaktionsschnell fühlt sich die Seite an? Und wie stabil ist das Layout während des Ladens? Diese drei Dimensionen — Ladegeschwindigkeit, Interaktivität und visuelle Stabilität — korrelieren nachweislich mit Absprungrate, Verweildauer und Conversion.

Largest Contentful Paint (LCP) misst die Zeit bis zum Rendern des größten sichtbaren Inhalts-Elements, typischerweise ein Hero-Bild oder eine H1. Der Schwellenwert für 'gut' liegt bei 2,5 Sekunden. Häufige Ursachen für schlechtes LCP: unkomprimierte Bilder, fehlende Preload-Hints für kritische Ressourcen, langsame Server-Antwortzeiten (TTFB) und render-blockierendes JavaScript.

Cumulative Layout Shift (CLS) quantifiziert unerwartete Layout-Verschiebungen — wenn Elemente während des Ladens springen und Nutzer versehentlich auf falschen Buttons klicken. Der Schwellenwert liegt bei 0,1. Häufige Ursachen: Bilder ohne definierte Dimensionen, nachträglich eingeblendete Banner und Webfonts ohne font-display-Strategie.

Interaction to Next Paint (INP) ist die neue Schlüsselmetrik. Gut bedeutet unter 200 ms, verbesserungswürdig zwischen 200 und 500 ms, schlecht über 500 ms. INP misst die Latenz vom Nutzer-Eingabe bis zum nächsten gerenderten Frame — und zwar über alle Interaktionen der Session, wobei der 98. Perzentil-Wert als Gesamtnote gilt. Das macht INP empfindlicher für seltene, aber schwerwiegende Einbrüche als FID es je war.

Die Unterscheidung zwischen Field- und Lab-Daten ist für die praktische Arbeit zentral. Lab-Daten kommen aus kontrollierten Messumgebungen — Lighthouse, WebPageTest, PageSpeed Insights im Labor-Modus. Sie sind reproduzierbar, gut für Regression-Tests geeignet und liefern detaillierte Traces. Aber sie simulieren einen einzelnen Ladevorgang auf einem definierten Gerät unter definierten Netzwerkbedingungen.

Field-Daten hingegen stammen aus dem Chrome User Experience Report (CrUX) — aggregierten, anonymisierten Messwerten echter Nutzer-Sessions. Sie spiegeln die tatsächliche Erfahrung Ihrer Zielgruppe wider: mit deren Endgeräten, Verbindungen und Nutzungsmustern. Für das Google-Ranking zählt ausschließlich das Field-Daten-Signal. Lighthouse-Scores verbessern sich nicht automatisch im Ranking, solange die CrUX-Daten nicht folgen.

INP ist per Definition eine Field-Metrik: Lab-Tools können keine realen Interaktions-Sequenzen über eine komplette Nutzersession erfassen. Lighthouse misst zwar Total Blocking Time (TBT) als Labor-Proxy — ein Indikator für Long Tasks, die INP verschlechtern können — aber TBT und INP sind nicht deckungsgleich. Eine niedrige TBT garantiert keine gute INP.

Praktische Konsequenz: Für INP-Optimierung braucht man Real-User-Monitoring (RUM). Google Search Console zeigt CrUX-basierte INP-Werte auf URL-Ebene. Für tiefere Diagnosen eignen sich Tools wie SpeedCurve, Sentry Performance, oder das Web Vitals JavaScript-Snippet direkt im eigenen Analytics-Stack. Erst wenn klar ist, welche Interaktionen auf welchen Seiten bei welchen Nutzergruppen das INP-Problem verursachen, kann man gezielt eingreifen.

INP-Probleme entstehen selten aus einer einzelnen Ursache. In der Praxis sind es meist mehrere sich überlagernde Faktoren, die zusammen dazu führen, dass der Browser nach einem Klick Hunderte von Millisekunden braucht, bevor sich auf dem Bildschirm etwas verändert. Die drei häufigsten Ursachen-Cluster sind: Long Tasks im Main Thread, Hydration-Overhead bei serverseitig gerenderten Frameworks und ineffiziente Event-Handler.

Long Tasks sind JavaScript-Blöcke, die den Main Thread länger als 50 ms blockieren. Während ein Long Task läuft, kann der Browser weder auf Nutzer-Eingaben reagieren noch neue Frames rendern. Das Ergebnis: Der Nutzer klickt, sieht nichts passieren, klickt erneut — und die gestaute Interaktionswarteschlange verlängert die gemessene INP weiter. Long Tasks lassen sich im Chrome DevTools Performance-Panel als rote Balken identifizieren; 'Long Tasks' sind explizit markiert.

Hydration ist das spezifische Problem von Frameworks wie Next.js, Nuxt oder SvelteKit im SSR/SSG-Modus: Die Seite wird zunächst als statisches HTML ausgeliefert (gut für LCP), dann lädt JavaScript nach und 'hydratisiert' die statische Seite zu einer interaktiven App. Während dieser Hydration-Phase ist die Seite für Nutzer zwar sichtbar, aber Interaktionen können zu drastischen INP-Ausschlägen führen, weil der Hydration-Prozess den Main Thread blockiert. Progressive Hydration, Island Architecture (z.B. Astro) und React Server Components sind architekturelle Antworten auf dieses Problem.

Ineffiziente Event-Handler sind die am häufigsten unterschätzte Ursache. Jedes Mal, wenn ein Nutzer klickt oder tippt, wird der zugehörige Event-Handler synchron ausgeführt. Wenn dieser Handler komplexe DOM-Operationen, synchrone Datenabrufe oder kaskadierte State-Updates auslöst, verlängert sich die Zeit bis zum nächsten Paint direkt. Besonders kritisch: Event-Handler, die Layout-Thrashing verursachen — also abwechselnd DOM lesen und schreiben, was den Browser zwingt, das Layout wiederholt neu zu berechnen.

Performance-Optimierung ohne Priorisierung ist Ressourcenverschwendung. Das folgende Framework beschreibt einen strukturierten Weg von der ersten Messung bis zur produktiven Verbesserung — mit klarer Priorität auf die Maßnahmen mit dem größten Impact bei vertretbarem Aufwand.

Schritt 1 — Basis-Diagnostik: Google Search Console öffnen, Abschnitt 'Core Web Vitals'. Welche URLs haben 'schlechte' INP-Werte? Handelt es sich um Templates (z.B. alle Produktseiten) oder Einzelseiten? Diese URL-Cluster definieren den Scope der Optimierung. Parallel: CrUX-Daten via PageSpeed Insights auf Seiten-Ebene prüfen, um Gerät- und Verbindungs-Splits zu verstehen.

Schritt 2 — Interaktions-Tracing: Chrome DevTools, Performance-Panel, 'Record' während einer typischen Nutzer-Session auf der problematischen Seite. Konkret: Klick auf die häufigste Interaktion (CTA-Button, Filter, Formular-Feld), dann den Trace analysieren. Wie lang ist die Input-to-Paint-Latenz? Welcher Code-Block verursacht den längsten Task? Das Performance-Panel zeigt Long Tasks, Scripting-Aufwand und Layout-Operationen in einem Wasserfall.

Schritt 3 — Maßnahmen nach Kategorie priorisieren: Code-Splitting für JavaScript-Bundles reduziert die Hydration-Last. Drittanbieter-Skripte in Web Worker auslagern oder via Partytown delegieren. Event-Handler mit requestAnimationFrame oder der Scheduler API (scheduler.yield()) aufteilen, damit der Browser zwischen Tasks Interaktionen verarbeiten kann. Für React/Next.js: startTransition() für nicht-dringende State-Updates nutzen, um visuelle Responsiveness zu erhalten.

Schritt 4 — Validierung im Staging: Nach jeder Änderung TBT in Lighthouse als Proxy messen und DevTools-Traces wiederholen. Kein Deploy ohne messbaren Nachweis der Verbesserung im Lab. Staging-Daten sind kein Ersatz für Field-Daten, aber sie verhindern Regressionen.

Schritt 5 — Field-Daten-Monitoring: RUM einrichten (oder vorhandenes Analytics-Setup um Web Vitals erweitern). Mindestens 28 Tage warten, bis CrUX-Daten die Verbesserung widerspiegeln — Google aktualisiert CrUX rollierend über diesen Zeitraum. Erst dann ist der Optimierungszyklus abgeschlossen.

Die Frage, die in jedem Gespräch mit Marketing-Leads kommt: 'Was bringt das konkret?' Die ehrliche Antwort ist differenziert. Core Web Vitals sind ein bestätigtes Rankingsignal im Page Experience Update von Google, aber sie sind kein dominierendes Signal. Relevanz, Backlinks und Content-Qualität wiegen weiterhin schwerer. Was Vitals tun: Sie fungieren als Tiebreaker bei ansonsten gleichwertigen Seiten und als Mindeststandard, unterhalb dessen selbst guter Content benachteiligt werden kann.

Die Business-Relevanz von INP liegt jedoch weniger im Ranking-Algorithmus als in der direkten Auswirkung auf Nutzerverhalten. Googles eigene Recherchen zeigen, dass eine Verbesserung der Core Web Vitals um eine Stufe (z.B. von 'schlecht' auf 'verbesserungswürdig') messbare Effekte auf Absprungrate und Session-Dauer haben kann. Amazon, Pinterest und andere haben in internen Tests dokumentiert, dass Ladezeit-Verbesserungen im Millisekunden-Bereich Conversion-Effekte hatten — allerdings bei sehr hohem Traffic-Volumen, das DACH-Mittelstands-Websites typischerweise nicht erreichen.

Was ich aus konkreten Projekten berichten kann: B2B-Websites mit schlechten Core Web Vitals verlieren keine Rankings über Nacht, aber sie akkumulieren über Zeit einen strukturellen Nachteil gegenüber Wettbewerbern, die aktiv optimieren. Und der direkte Nutzereffekt ist real: Eine Seite, die nach einem Klick 600 ms braucht, um zu reagieren, erzeugt messbares Misstrauen — besonders bei Formularen, Checkout-Flows und interaktiven Tools. Das ist kein Conversion-Wert, der im A/B-Test in zwei Wochen sichtbar wird, aber er ist kumulativ signifikant.

Für die strategische Priorisierung empfehle ich diesen Rahmen: Wenn Core Web Vitals im 'schlechten' Bereich liegen, ist die Optimierung keine optionale Maßnahme, sondern Hygiene. Wenn sie im 'verbesserungswürdigen' Bereich liegen, prüfe ich zuerst, ob INP-Spitzen bei conversion-kritischen Interaktionen auftreten. Wenn ja, ist der Business Case klar. Wenn alle drei Vitals im grünen Bereich sind, verlagert sich die Priorität auf andere Hebel.

Die folgenden Quellen bilden die Grundlage der in diesem Artikel dargestellten technischen Sachverhalte und Schwellenwerte.