Interaction to Next Paint, kurz INP, ist seit dem 12. März 2024 offiziell der dritte Core Web Vital von Google und hat den First Input Delay (FID) vollständig abgelöst. Anders als FID misst INP nicht mehr nur die allererste Interaktion einer Besucherin oder eines Besuchers mit einer Seite, sondern die Reaktionsfähigkeit über die gesamte Lebensdauer eines Seitenbesuchs hinweg, von Klicks über Tastatureingaben bis zu Taps auf mobilen Geräten. Für Website-Betreiber bedeutet das: Eine Seite, die beim ersten Klick noch flüssig reagiert, aber bei jeder weiteren Interaktion ins Stocken gerät, wurde von FID nie erfasst und wird jetzt mit INP erstmals sichtbar. Dieser Beitrag erklärt, was INP genau misst, welche Schwellenwerte gelten, wie sich die Kennzahl von FID unterscheidet, mit welchen Werkzeugen sie sich messen lässt, welche technischen Ursachen hinter einem schlechten Wert stehen und mit welchen Maßnahmen sich INP in der Praxis verbessern lässt.
Was misst Interaction to Next Paint eigentlich?
INP misst die Zeitspanne von dem Moment, in dem eine Nutzerin oder ein Nutzer mit einer Seite interagiert, klickt, tippt oder eine Taste drückt, bis zu dem Moment, in dem der Browser den nächsten Frame zeichnet, der diese Interaktion sichtbar widerspiegelt. Erfasst werden dabei drei Teilphasen: die Verzögerung, bis der zuständige Event-Handler überhaupt zu laufen beginnt, die eigentliche Verarbeitungszeit dieses Handlers, und die Zeit, bis der Browser das visuelle Ergebnis tatsächlich darstellt. Anders als bei früheren Metriken beobachtet INP dabei alle Interaktionen über die gesamte Sitzung einer Seite hinweg, nicht nur eine einzelne. Bei den meisten Seitenaufrufen bildet INP praktisch die langsamste beobachtete Interaktion ab; nur bei einer sehr hohen Zahl an Interaktionen auf einer Seite blendet Google einzelne Ausreißer aus, um die Kennzahl nicht durch Einzelfälle zu verzerren.
Diese Umstellung ist keine reine Randnotiz für Entwickler. Weil INP als vollwertiger Core Web Vital eingeführt wurde, ist die Kennzahl seit März 2024 auch Teil der Page-Experience-Signale, die Google bei der Bewertung einer Seite berücksichtigt, gemeinsam mit Largest Contentful Paint (LCP) und Cumulative Layout Shift (CLS), den beiden anderen Core Web Vitals.
Die offiziellen Schwellenwerte von Google
Google bewertet INP anhand von drei Stufen, gemessen am 75. Perzentil der Seitenaufrufe einer URL oder Gruppe von URLs. Das bedeutet: Mindestens 75 Prozent der gemessenen Seitenaufrufe müssen den jeweiligen Schwellenwert einhalten, damit eine Seite in diese Kategorie fällt.
| Bewertung | INP-Wert |
|---|---|
| Gut | weniger als 200 Millisekunden |
| Verbesserungswürdig | 200 bis 500 Millisekunden |
| Schlecht | mehr als 500 Millisekunden |
Diese Werte gelten für Feld-Daten, also für tatsächlich gemessene Nutzerinteraktionen auf echten Geräten mit echten Netzwerkbedingungen, nicht für eine einzelne Labormessung unter Idealbedingungen. Eine Seite kann in einem einmaligen Labortest gut abschneiden und trotzdem im Feld eine schlechte Bewertung erhalten, etwa weil ein Großteil der echten Besucher über langsamere Mobilgeräte zugreift.
INP vs. FID: Warum First Input Delay abgelöst wurde
First Input Delay hatte einen strukturellen blinden Fleck: Die Metrik maß ausschließlich die Verzögerung bis zum Start der ersten Interaktion auf einer Seite, nicht die Verarbeitungszeit dieser Interaktion und schon gar nicht spätere Interaktionen. Eine Seite, die beim ersten Klick sofort reagierte, aber bei jedem weiteren Klick für eine halbe Sekunde einfror, konnte bei FID trotzdem einen exzellenten Wert erzielen. Genau diese Lücke schließt INP.
| Dimension | FID (bis März 2024) | INP (seit März 2024) |
|---|---|---|
| Erfasster Zeitraum | Nur die erste Interaktion einer Sitzung | Alle Interaktionen über die gesamte Seiten-Lebensdauer |
| Gemessene Phase | Nur die Verzögerung bis zum Start des Event-Handlers | Verzögerung, Verarbeitungszeit und Darstellung bis zum nächsten Frame |
| Status als Core Web Vital | Bis 11. März 2024 | Seit 12. März 2024, offizieller dritter Core Web Vital |
FID bleibt als reiner Diagnosewert in einzelnen Tools weiterhin sichtbar, zählt aber seit dem Wechsel nicht mehr zu den drei Kennzahlen, die Google für die Bewertung der Page Experience heranzieht.
Wie lässt sich INP messen?
Für die Messung von INP stehen mehrere Werkzeuge zur Verfügung, die sich in einem entscheidenden Punkt unterscheiden: Feld-Daten aus echten Nutzerinteraktionen gegenüber simulierten Labor-Daten. PageSpeed Insights zeigt beides nebeneinander, sofern für eine URL ausreichend Feld-Daten vorliegen, und stützt sich für die Feld-Daten auf den Chrome UX Report (CrUX), also auf anonymisierte, aggregierte Messwerte echter Chrome-Nutzer. Die Google Search Console bietet mit ihrem Core-Web-Vitals-Bericht eine dritte Perspektive: Sie gruppiert betroffene URLs nach ähnlichem Layout und zeigt, wie viele davon als gut, verbesserungswürdig oder schlecht eingestuft sind, ebenfalls auf Basis von CrUX-Feld-Daten.
Google Lighthouse liegt dagegen auf der Labor-Seite und bringt eine wichtige Einschränkung mit: Ein automatisierter Lighthouse-Durchlauf simuliert standardmäßig keine echten Klicks oder Taps, weshalb er INP nicht direkt berichten kann. Stattdessen liefert Lighthouse die Total Blocking Time (TBT) als Labor-Annäherung an die Reaktionsfähigkeit einer Seite. TBT korreliert mit INP, ersetzt eine echte Feldmessung aber nicht. Wer INP unter Laborbedingungen mit echten, gescripteten Interaktionen messen will, kann das über Lighthouse User Flows tun, die gezielt Klicks oder Eingaben simulieren und dabei auch einen INP-Wert ausgeben. Für eine belastbare Einschätzung der eigenen Website bleibt jedoch der Blick auf Feld-Daten aus CrUX oder der Search Console entscheidend, weil nur sie das tatsächliche Verhalten realer Geräte und Netzwerke abbilden.
Typische Ursachen für einen schlechten INP-Wert
Ein schlechter INP-Wert hat fast immer dieselbe Grundursache: Der Haupt-Thread des Browsers ist zum Zeitpunkt einer Interaktion mit anderer Arbeit beschäftigt und kann nicht rechtzeitig reagieren. Vier Muster tauchen dabei besonders häufig auf. Lange JavaScript-Tasks, die den Haupt-Thread am Stück für mehrere hundert Millisekunden blockieren, verzögern jede Interaktion, die währenddessen eintrifft. Teure Event-Handler, die bei einem Klick oder einer Eingabe umfangreiche synchrone Berechnungen ausführen, statt Arbeit aufzuteilen oder auszulagern, wirken sich direkt auf die Verarbeitungsphase von INP aus.
Layout-Thrashing entsteht, wenn ein Skript innerhalb desselben Interaktionszyklus wiederholt DOM-Eigenschaften ausliest und unmittelbar danach wieder schreibt, wodurch der Browser gezwungen wird, das Layout mehrfach neu zu berechnen, statt es einmal zu bündeln. Und gerade bei modernen JavaScript-Frameworks fällt ein vierter Faktor ins Gewicht: hohe Hydration-Kosten. Serverseitig gerenderte Seiten, die im Browser nachträglich mit Event-Listenern und Zustand angereichert werden müssen, blockieren den Haupt-Thread oft genau in der Phase, in der ungeduldige Nutzer bereits die ersten Klicks setzen. Wie stark JavaScript-lastige Frameworks die Core Web Vitals insgesamt beeinflussen, haben wir im Beitrag zu JavaScript SEO ausführlicher eingeordnet.
Optimierungsansätze in der Praxis
Die Optimierung von INP läuft technisch fast immer auf dasselbe Ziel hinaus: den Haupt-Thread so entlasten, dass er im Moment einer Interaktion frei ist. Code-Splitting reduziert dabei die Menge an JavaScript, die pro Seite überhaupt geladen und ausgeführt werden muss, indem nur der Code geladen wird, der für die aktuelle Route oder Komponente tatsächlich gebraucht wird. Debouncing und gezieltes Yielding brechen lange Aufgaben in kleinere Häppchen auf, etwa über setTimeout, requestIdleCallback oder die neuere scheduler.yield()-API, sodass der Browser zwischen den Häppchen wieder auf Eingaben reagieren kann, statt eine einzelne, lange Aufgabe blockierend durchzurechnen.
Generell gilt: Weniger Arbeit auf dem Haupt-Thread bedeutet einen besseren INP-Wert. Rechenintensive Aufgaben, die keinen direkten DOM-Zugriff benötigen, lassen sich in einen Web Worker auslagern und laufen dort, ohne Interaktionen zu blockieren. Auch Drittanbieter-Skripte, etwa für Tracking, Tag-Manager oder Chat-Widgets, sind ein häufig unterschätzter Faktor, weil sie eigenen, oft nicht selbst kontrollierten Code auf derselben Seite ausführen. Sie lassen sich durch async- oder defer-Ladung, eine bewusste Reduktion auf das Nötigste und regelmäßige Audits entschärfen. Gerade auf Mobilgeräten mit schwächerer Rechenleistung wirken sich all diese Maßnahmen besonders stark aus, was INP zu einem zentralen Baustein einer durchdachten mobilen Nutzerfreundlichkeit macht.
INP und SEO: Warum die Kennzahl für die Sichtbarkeit zählt
INP ist als Core Web Vital Teil der Page-Experience-Signale, die Google offiziell in die Bewertung einer Website einbezieht. Wichtig für die Einordnung: Google selbst beschreibt Core Web Vitals als einen Rankingfaktor unter vielen, dessen Gewicht im Vergleich zur inhaltlichen Relevanz einer Seite vergleichsweise gering ausfällt. Bei zwei Seiten mit ähnlich relevantem Inhalt kann ein deutlich besserer INP-Wert aber durchaus den Unterschied machen, wer vorne steht. Wichtiger als der reine Rankingeffekt ist meist der direkte Effekt auf Nutzerverhalten und Conversion: Eine Seite, die bei jeder Interaktion spürbar hakt, verliert Geduld und Vertrauen, unabhängig davon, ob Google das im Einzelfall überhaupt misst. Technisches SEO, das Core Web Vitals wie INP von Anfang an mitdenkt, gehört deshalb zum Kern eines soliden SEO-Fundaments, nicht zu einer nachgelagerten Optimierung.
Fazit
Interaction to Next Paint schließt eine reale Messlücke, die First Input Delay über Jahre offen ließ: die Reaktionsfähigkeit einer Seite über ihre gesamte Nutzungsdauer hinweg, nicht nur beim allerersten Klick. Mit klaren Schwellenwerten von unter 200 Millisekunden für eine gute Bewertung und über 500 Millisekunden für eine schlechte Bewertung liefert Google eine eindeutige Zielgröße, die sich über PageSpeed Insights, den Chrome UX Report, die Google Search Console und, mit Einschränkungen, über Lighthouse messen lässt. Wer die typischen Ursachen kennt, lange JavaScript-Tasks, teure Event-Handler, Layout-Thrashing und hohe Hydration-Kosten, kann mit Code-Splitting, gezieltem Yielding und einer bewussten Reduktion von Drittanbieter-Skripten gezielt gegensteuern und damit sowohl die technische Kennzahl als auch das tatsächliche Nutzererlebnis der eigenen Website verbessern.
