Wie Interaction to Next Paint Ihren schlechtesten Klick bewertet

Was ist INP (Interaction to Next Paint)?

Chrome misst Interaction to Next Paint als Dauer der schlechtesten Interaktion einer Seite, gemessen von dem Moment, in dem ein Besucher klickt, tippt oder eine Taste drückt, bis zu dem Moment, in dem der Browser den Frame zeichnet, der das Ergebnis zeigt. Die Metrik deckt den gesamten Umlauf ab: die Wartezeit, bevor ein Event-Handler startet, die Laufzeit des Handlers selbst und die Rendering-Arbeit danach. Erfassen Sie sie mit der web-vitals-Bibliothek oder einem beliebigen Feldkollektor und lesen Sie sie dann pro Route.

Chrome zählt Mausklicks, Taps auf dem Touchscreen und Tastendrücke auf physischen oder Bildschirmtastaturen, und Scrollen, Hovern und Zoomen erzeugen überhaupt keinen INP-Wert, so die Definition der Metrik, die das Chrome-Team auf web.dev veröffentlicht hat (abgerufen im September 2026). INP ist das einzige der drei Core Web Vitals, das die Reaktionsfähigkeit nach dem Laden der Seite bewertet, und es meldet nichts, bis echte Menschen auf Dinge klicken. Die Zahl, auf die Google reagiert, stammt also aus Real User Monitoring, der Messung an echten Nutzern, bei p75.

Was sind die drei Phasen einer Interaktion?

Jede Interaktion zerfällt in input delay (die Wartezeit vor dem Handler), processing duration (die Laufzeit des Handlers) und presentation delay (das Rendering bis zum Frame), und INP ist die Summe aller drei. Jede Phase hat im Browser einen anderen Verantwortlichen, deshalb sagt Ihnen eine einzelne INP-Zahl nichts, solange Sie sie nicht aufschlüsseln.

Phase	Beginnt, wenn	Endet, wenn	Was die Zeit verbrennt
Input delay	Der Besucher klickt, tippt oder drückt eine Taste	Der erste Event-Callback zu laufen beginnt	Main Thread bereits belegt mit Skriptauswertung, Timern, anderen Handlern
Processing duration	Der erste Event-Callback startet	Der letzte Callback endet	Ihr eigener Handler-Code, State-Updates des Frameworks, synchrone Arbeit
Presentation delay	Der letzte Callback endet	Der Browser zeichnet den nächsten Frame	Style-Neuberechnung, Layout, Paint, DOM-Größe

Die Formel ist eine schlichte Summe:

INP = input delay + processing duration + presentation delay

Ein Beispiel durchgerechnet. Ein Besucher tippt in einer Produktliste auf einen Filter-Chip und wartet 620ms, bis sich das Raster ändert:

620ms = 180ms input delay + 90ms processing duration + 350ms presentation delay

Der Reflex ist, den Handler zu optimieren, und der Handler ist mit 90ms das kleinste Stück. Presentation delay besitzt 56 Prozent der Interaktion, die Lösung liegt also im Rendering: Der Filter rendert 3.000 Rasterknoten neu und erzwingt eine vollständige Style-Neuberechnung. Verkleinern Sie das DOM, das die Interaktion berührt, und die 350ms brechen weg. Den Handler neu zu schreiben spart bestenfalls 90ms und bringt Sie allein nicht unter 200ms.

Ein Tipp, drei Verzögerungen

Eingabeverzögerung180ms

Verarbeitungsdauer90ms

Darstellungsverzögerung350ms

Was ist ein guter INP-Wert?

Chromes Schwellenwerte setzen gut bei 200ms oder weniger und schlecht über 500ms an, gemessen am 75. Perzentil der Seitenaufrufe und getrennt nach Mobile und Desktop. Das Chrome-Team veröffentlicht diese Grenzwerte auf web.dev, unverändert im September 2026.

INP bei p75	Bewertung
200ms oder weniger	Gut
Über 200ms bis 500ms	Verbesserungswürdig
Über 500ms	Schlecht

Zweihundert Millisekunden sind ein knappes Budget, sobald Sie es dreiteilen, und die Phase, die ihren Anteil zuerst sprengt, ist die, die Sie angreifen. Messen Sie die Aufteilung, bevor Sie Code anfassen: Ein Suchfeld scheitert am processing, ein Raster mit Infinite Scroll am presentation.

Warum hat INP FID abgelöst, und warum hat FID Websites geschmeichelt?

Google machte INP am 12. März 2024 zu einem Core Web Vital und ersetzte damit First Input Delay, und die Unterstützung für FID endete am 9. September 2024 (web.dev, Chrome-Team). FID maß eine einzige enge Sache: die Verzögerung, bevor der erste Event-Handler auf der Seite starten konnte. Es maß nie den Handler, und es maß nie den Paint danach.

	First Input Delay	Interaction to Next Paint
Welche Interaktion	Nur die erste	Die schlechteste auf der Seite
Welche Phasen	Nur input delay	Input delay, processing, presentation
Gut bei p75	100ms oder weniger	200ms oder weniger
Status	Eingestellt am 9. September 2024	Core Web Vital seit dem 12. März 2024

FID schmeichelte Websites aus zwei Gründen. Die erste Interaktion auf einer Seite ist für die meisten Besucher eine billige: ein Cookie-Banner wegklicken, ein Suchfeld fokussieren, in einem Consent-Dialog auf Akzeptieren tippen. Die teuren Interaktionen kommen später, wenn sich der Besucher auf die Seite eingelassen hat, und FID hat sie nie angesehen.

FID stoppte seine Uhr außerdem, bevor Ihr Code lief, deshalb erzielte ein Filter-Handler, der den Main Thread 900ms blockierte, einen perfekten FID, solange der Browser den Handler schnell betreten konnte. web.dev sagt ausdrücklich, dass das Mitzählen der Verarbeitungszeit in FID Entwickler dazu hätte drängen können, Handler-Logik in einen asynchronen Callback zu verpacken und sie so aus der gemessenen Task herauszuschieben, ohne der wartenden Person zu helfen. INP schließt beide Lücken.

Welche Interaktion meldet INP, wenn eine Seite Hunderte hat?

Chrome meldet die schlechteste Interaktion der Seite, mit einem Zugeständnis an Ausreißer auf stark genutzten Seiten. Bei Seiten mit 50 oder weniger Interaktionen wird die höchste zum INP der Seite. Über 50 legt Chrome pro 50 aufgezeichneten Interaktionen eine hohe Interaktion beiseite, eine Sitzung mit 130 Interaktionen verwirft also die zwei höchsten und meldet die nächstniedrigere.

Hier stapeln sich zwei Aggregationen, und sie zu verwechseln ist ein häufiger Fehler in der Fehlersuche: Die Regel der schlechtesten Interaktion wählt eine Zahl pro Seitenaufruf, dann wählt das 75. Perzentil über die Seitenaufrufe hinweg eine Zahl pro URL. Lesen Sie diese Verteilung so, wie Sie Largest Contentful Paint lesen, mit p75 neben p90 und der Anzahl der Messwerte.

Was verursacht ein langsames INP, und was behebt jede Ursache?

Ein langsames INP hat drei Ursachenfamilien, eine pro Phase, und jede verlangt eine andere Lösung.

Input delay entsteht durch einen Main Thread, der beim Eintreffen des Klicks schon beschäftigt ist: Skriptauswertung während des Seitenaufbaus, Timer und Fetch-Handler, die um denselben Thread konkurrieren. Reduzieren Sie die Menge an JavaScript, die überhaupt läuft, und zerlegen Sie jede Long Task, also jede lange Aufgabe über 50ms, damit der Browser eine Lücke bekommt, um Eingaben anzunehmen.

Processing duration entsteht durch Handler, die auf einen Schlag zu viel tun. Geben Sie den Main Thread mit scheduler.yield() oder setTimeout() frei, damit der Browser einen Zwischenframe zeichnen kann, und schieben Sie alles, was der Besucher nicht sofort braucht, hinter requestAnimationFrame() plus ein Yield. Erst Feedback zeichnen, dann arbeiten.

Presentation delay entsteht beim Rendering. Große DOMs kosten mehr Rendering-Zeit als kleine, flachen Sie den Baum also ab und fügen Sie Elemente während der Interaktion ein, statt sie vorab auszuliefern. Grenzen Sie den Umfang der Style-Neuberechnung ein und nutzen Sie content-visibility, um Arbeit außerhalb des Bildschirms zu überspringen. Jagen Sie zuerst Layout-Thrashing: Einen Style zu schreiben und ihn in derselben Task zurückzulesen erzwingt ein synchrones Layout, und alle Lesevorgänge vor allen Schreibvorgängen zu bündeln beseitigt das. Dieselbe Rendering-Arbeit bewegt Cumulative Layout Shift, prüfen Sie nach der Korrektur also beides.

Wie finden Sie die Interaktion, die INP nach unten zieht?

Sehen Sie sich die Sitzungen an, in denen ein Besucher geklickt hat und nichts passiert ist. Ein INP von 640ms bei p75 sagt, dass die Seite langsam ist; es sagt nicht, welches Bedienelement, welche Route oder welches Gerät.

Flowsery zeichnet die Sitzung auf und markiert Rage Clicks, Dead Clicks und JavaScript-Fehler automatisch, und genau so sieht eine hängende Interaktion von der Seite des Besuchers aus: derselbe Button viermal gedrückt, weil nie ein Frame gezeichnet wurde. Übereinstimmende Sitzungen bündeln sich zu einem Issue, Issues werden danach sortiert, wie viele Nutzer sie treffen, und jedes landet mit Replay und Reproduktionsschritten in Slack, Linear oder Jira. Die Erfassung läuft über ein Skript unter 10 KB, cookiefrei und EU-gehostet, ohne Daten-Sampling, damit die langsamen Interaktionen nicht die sind, die aus der Stichprobe fallen.

Häufig gestellte Fragen

Misst INP das Scrollen?

Nein. Chrome zählt Mausklicks, Taps auf dem Touchscreen und Tastendrücke und schließt Scrollen, Hovern und Zoomen aus. Ein ruckelndes Scrollen ist eine echte Beschwerde, die keinen INP-Wert erzeugt, diagnostizieren Sie es also stattdessen über Frame-Timing und Long Tasks.

Warum ist mein INP in Lighthouse gut und im Feld schlecht?

Lighthouse führt eine skriptgesteuerte Interaktion auf einem konfigurierten Gerät aus, und INP bewertet die schlechteste Interaktion, die echte Besucher auf ihrer eigenen Hardware gemacht haben. Ihr Laborlauf klickt den Button, den Sie ihm vorgegeben haben; Ihre Besucher klicken den teuren Filter auf einem vier Jahre alten Android-Handy. Behandeln Sie das Labor als Regressionsprüfung und das Feld als Urteil.

Sollte ich First Input Delay weiter verfolgen?

Nein. FID war ab dem 12. März 2024 kein Core Web Vital mehr, und die Unterstützung endete am 9. September 2024, es taucht also nicht mehr in der Search Console auf und hat kein Gewicht in der Bewertung. Verschieben Sie das Dashboard-Panel auf INP und behalten Sie die FID-Reihe nur, um alte Vorfälle nachzulesen.

Kann ein einzelner langsamer Klick die ganze Seite durchfallen lassen?

Nicht für sich allein. Die schlechteste Interaktion wird zum INP dieses Seitenaufrufs, dann liest Google das 75. Perzentil dieser Werte über alle Seitenaufrufe der URL. Ein 3-Sekunden-Klick in einer Sitzung bewegt nichts; dasselbe langsame Bedienelement, das ein Viertel Ihrer Sitzungen trifft, lässt die URL durchfallen.

Wie wird INP in einer Single-Page-App gemessen?

INP sammelt sich über die Lebensdauer der Seite, Interaktionen aus einer Route bleiben also im selben Messfenster wie die nächste, bis eine harte Navigation es zurücksetzt. Ein langsamer Klick auf einem Einstellungsbildschirm kann gegen die URL gemeldet werden, auf der der Besucher gelandet ist. Chromes Unterstützung für Soft Navigations zum Aufteilen dieser Fenster ist experimentell, segmentieren Sie in Ihren eigenen Felddaten also nach Route.

Welches Budget pro Phase hält INP unter 200ms?

Fünfzig Millisekunden input delay, 50ms processing duration und 100ms presentation delay sind eine praktikable Aufteilung. Messen Sie die tatsächliche Aufteilung pro Route, bevor Sie entscheiden, was Sie beheben, denn ein handler-lastiges Suchfeld und ein render-lastiges Produktraster scheitern aus entgegengesetzten Gründen an derselben Schwelle.

Was zählt als Long Task, und warum ist das für INP wichtig?

Ein Long Task ist jeder ununterbrochene Hauptthread-Block über 50ms, derselbe Schwellenwert, auf den auch die Fixes für die Eingabeverzögerung zielen. Während ein Long Task läuft, kann der Browser keinen Event-Handler starten, sodass diese Zeit direkt in die Eingabeverzögerung fließt. Wird der Long Task in kleinere Stücke zerlegt, bekommt der Browser eine Lücke, um den Klick anzunehmen und den Handler früher zu starten.

Wie stoppt man Layout-Thrashing, das die Darstellungsverzögerung in die Länge zieht?

Layout-Thrashing entsteht, wenn Code einen Stil schreibt und ihn im selben Task wieder ausliest, was ein synchrones Layout erzwingt, das der Browser sonst aufschieben würde. Werden in einem Task erst alle Lesezugriffe und dann alle Schreibzugriffe gebündelt, verschwindet das erzwungene Layout mitsamt der Verzögerung. Das prüft man innerhalb der Darstellungsverzögerung zuerst, noch vor DOM-Größe und content-visibility.

Mit welchem Werkzeug misst man INP auf der eigenen Website?

INP wird mit der web-vitals-Bibliothek oder einem anderen Field-Collector instrumentiert und pro Route ausgelesen. Da INP erst dann etwas meldet, wenn echte Besucher klicken, tippen oder eine Taste drücken, muss diese Zahl aus Real User Monitoring stammen statt aus einem einzelnen Lighthouse-Lauf. Gelesen wird der Wert am 75. Perzentil, genau wie Chrome ihn bewertet.

Warum verwirft Chrome auf Seiten mit vielen Klicks manche Interaktionen?

Ab 50 erfassten Interaktionen legt Chrome für je 50 eine besonders hohe beiseite, damit ein paar Ausreißer nicht den Wert der ganzen Seite bestimmen. Eine Seite mit 130 Interaktionen verwirft die zwei höchsten und meldet die nächsttiefere als ihren INP. Seiten mit 50 oder weniger Interaktionen überspringen diesen Schritt und nutzen die einzige schlechteste Interaktion direkt.