INP (Interaction to Next Paint) ist die Google-Kennzahl, die seit März 2024 als offizieller Core Web Vital misst, wie schnell eine Webseite auf Nutzereingaben reagiert. Sie gibt an, wie lange der Browser nach einem Klick, einem Tipp oder einem Tastendruck braucht, bis die nächste sichtbare Antwort erscheint. Ein schlechter INP-Wert bedeutet: Die Seite reagiert spürbar träge auf den Nutzer, selbst wenn sie schnell lädt.

Was ist INP, und warum hat es FID abgelöst?

INP steht für Interaction to Next Paint. Google hat damit am 12. März 2024 den First Input Delay (FID) als dritten Core Web Vital abgelöst, neben LCP (Largest Contentful Paint) und CLS (Cumulative Layout Shift). Der Wechsel war notwendig, weil FID eine grundlegende Lücke hatte: Es maß nur die Verzögerung der allerersten Interaktion auf einer Seite. Seiten, die nach dem ersten Klick zunehmend langsamer wurden, fielen dadurch nicht auf.

INP schließt diese Lücke. Die Kennzahl erfasst alle Klicks, Tipps und Tastendrücke während der gesamten Nutzungssitzung und verwendet die schlechteste Reaktionszeit als finalen Wert. Bei sehr langen Sitzungen mit vielen Interaktionen werden einzelne Ausreißer herausgerechnet, damit ein ungewöhnlicher Einzelfall das Gesamtergebnis nicht verfälscht.

Wie INP gemessen wird: die drei Phasen

Jede Interaktion, die INP aufzeichnet, läuft durch drei aufeinanderfolgende Phasen. Ihre Summe ergibt die Gesamtlatenz für diese Interaktion.

• Input Delay: Die Wartezeit, bevor der Browser mit der Verarbeitung beginnt. Ursache ist meist ein Hauptthread, der gerade andere Aufgaben ausführt, etwa das Initialisieren von Skripten oder das Rendern einer Animation.
• Processing Time: Die Zeit, in der JavaScript-Eventhandler und Callbacks ausgeführt werden, nachdem der Browser die Eingabe registriert hat.
• Presentation Delay: Die Zeit für Layout-Neuberechnungen und das Zeichnen des nächsten Frames, bevor die visuelle Antwort für den Nutzer sichtbar wird.

Die INP-Schwellenwerte

Google bewertet INP auf drei Stufen. Maßgeblich ist das 75. Perzentil: Drei Viertel aller gemessenen Interaktionen auf einer Seite müssen diesen Wert erfüllen.

• Gut: unter 200 Millisekunden
• Verbesserungswürdig: 200 bis 500 Millisekunden
• Schlecht: über 500 Millisekunden

Felddaten und Labordaten: ein wichtiger Unterschied

Tools wie Google Lighthouse liefern im Lab-Modus keinen echten INP-Wert, weil kein echter Nutzer mit der Seite interagiert. Labordaten zeigen Näherungswerte über Simulationen. Die tatsächlichen INP-Werte stammen aus dem Chrome User Experience Report (CrUX) und erscheinen in der Google Search Console sowie im Felddaten-Abschnitt von PageSpeed Insights. Sie zeigen, wie echte Nutzer auf echten Geräten die Seite erleben.

INP ist dabei nur einer von mehreren Onpage-Faktoren, die Google beim Crawling und Ranking bewertet. Einen Überblick über den technischen SEO-Rahmen, in dem Core Web Vitals eingebettet sind, bietet der vollständige Onpage-SEO-Leitfaden mit Checkliste.

Ein konkretes Beispiel: Tracking-Skripte verzögern den Menü-Klick

Das Szenario ist auf vielen B2B-Websites typisch: Ein Live-Chat-Widget, ein Cookie-Consent-Banner, Google Tag Manager und Web-Analytics laden beim Seitenaufruf. Ein Besucher klickt auf das Navigationsmenü, kurz nachdem die Seite fertig geladen hat. Der Hauptthread ist zu diesem Zeitpunkt noch damit beschäftigt, das Chat-Skript zu initialisieren und den Consent-Manager zu starten.

Der Klick auf das Menü landet in einer Warteschlange. 650 Millisekunden vergehen, bis das Menü aufklappt. Für den Nutzer fühlt sich die Seite eingefroren an, auch wenn der Ladebalken längst verschwunden ist. PageSpeed Insights wertet diesen Wert als "Schlecht". Dieser Moment geht als INP-Wert der Seite in die Google-Bewertung ein.

Der entscheidende Punkt: Der Ladeprozess kann tadellos sein. Das Performance-Problem entsteht erst, wenn Nutzende mit der Seite interagieren. FID hätte es nicht aufgedeckt. INP tut es.

INP auf B2B-Websites und in Webflow

Für B2B-Websites ist das Szenario aus dem Beispiel der Regelfall: Live-Chat (Intercom, HubSpot), Tag Manager, Consent-Management-Plattformen und mehrere Analytics-Systeme laufen gleichzeitig. Jedes beansprucht Rechenzeit auf dem Hauptthread. Klickt ein Nutzer kurz nach dem Seitenaufruf, konkurrieren seine Eingaben mit diesen Initialisierungsprozessen um den Hauptthread. Auf vielen B2B-Websites liegt der INP-Wert deshalb deutlich über dem 200-Millisekunden-Schwellenwert.

Wer INP im Kontext einer umfassenden technischen Optimierung angehen will, findet im Artikel zur Webflow SEO-Optimierung die wichtigsten Stellschrauben, die über Core Web Vitals hinausgehen.

In Webflow-Projekten kommen Webflow Interactions und Lottie-Animationen als zusätzliche Faktoren hinzu. Diese reagieren auf Scroll- und Klick-Ereignisse über JavaScript-Callbacks. Wenn viele davon gleichzeitig feuern, steigt der Input Delay. Das gilt besonders auf Mobilgeräten, deren Prozessoren schwächer sind als auf Desktop-Systemen. Wer eine professionelle Unternehmenswebsite mit Webflow betreibt, sollte INP deshalb als festen Bestandteil der technischen Qualitätssicherung behandeln.

Was im B2B-Kontext oft unterschätzt wird: INP ist auch ein Qualitätssignal für den Besucher. Lange bevor ein Entscheider ein Kontaktformular ausfüllt, registriert er unbewusst, ob die Seite auf seine Eingaben reagiert. Eine träge Seite wirkt unprofessionell, auch wenn das Design stimmt.

Praktische Maßnahmen für Webflow-Projekte

Diese Maßnahmen verbessern den INP-Wert gezielt auf Webflow-Websites, lassen sich aber auf andere CMS und Plattformen übertragen:

• Drittanbieter-Skripte (Chat, Consent, Analytics) mit defer oder async einbinden, nie synchron im <head>.
• Im Google Tag Manager nur die Tags aktiv lassen, die wirklich gebraucht werden. Trigger so konfigurieren, dass sie nicht alle gleichzeitig beim Seitenaufruf feuern.
• Webflow Interactions auf das Notwendige reduzieren. Einen Überblick über aktuelle Webflow-Funktionen, die sich auf die Performance auswirken, bietet der Artikel zu den neuesten Webflow Features und Updates.
• Consent-Banner so einrichten, dass sie keine langen JavaScript-Tasks im kritischen Zeitfenster nach dem Seitenaufruf starten.
• Lange JavaScript-Tasks aufteilen: Tasks über 50 Millisekunden mit setTimeout oder requestIdleCallback unterbrechen, damit der Browser zwischendurch auf Nutzereingaben reagieren kann.

Häufige Fehler beim Umgang mit INP

Nur Labordaten prüfen. Lighthouse und PageSpeed Insights liefern im Lab-Modus keinen echten INP-Wert, weil keine Nutzerinteraktion simuliert wird. Wer sich ausschließlich auf Lab-Scores verlässt, kann einen schlechten Felddatenwert vollständig übersehen. Die Wahrheit steht in der Google Search Console unter "Core Web Vitals".

INP mit Ladezeit verwechseln. LCP misst, wann die Seite visuell geladen erscheint. INP misst, wie schnell sie auf Nutzereingaben reagiert. Beides ist unabhängig voneinander. Eine schnell ladende Seite kann trotzdem träge auf Klicks reagieren. Viele Teams optimieren Ladezeiten konsequent, vernachlässigen aber die Reaktionsfähigkeit.

Zu viele Skripte synchron im <head>. Synchron geladene Skripte blockieren den Hauptthread und erhöhen direkt den Input Delay aller frühen Interaktionen.

Lange JavaScript-Tasks nicht aufteilen. Ein einzelner Task über 50 ms blockiert den Hauptthread und verzögert die Antwort auf Nutzereingaben. Das Zerlegen langer Tasks ist eine der wirkungsvollsten Maßnahmen zur INP-Verbesserung.

Nur Desktop-Werte betrachten. INP-Probleme treten auf Mobilgeräten früher und deutlicher auf. Die Felddaten in Search Console und PageSpeed Insights unterscheiden zwischen Desktop und Mobile. Wer nur Desktop-Scores optimiert, lässt die Nutzererfahrung der Mehrheit außer Acht.

Für Webflow-Projekte lohnt sich ein Blick auf die Möglichkeiten, die das CMS zur technischen Performance-Optimierung mitbringt. Die Top 10 Webflow Funktionen, die wir als Agentur seit 2017 nutzen, geben einen praxisnahen Einstieg.