Interaction to Next Paint (INP)

Kurzdefinition

Interaction to Next Paint, kurz INP, misst, wie schnell eine Seite sichtbar reagiert, wenn jemand klickt, tippt oder eine Taste drückt. Für jede Interaktion misst der Browser die Zeit von der Eingabe bis zum nächsten gezeichneten Frame. Am Ende des Besuchs meldet INP eine der langsamsten dieser Interaktionen.

INP ist eines der drei Core Web Vitals, neben Largest Contentful Paint (LCP) und Cumulative Layout Shift (CLS). LCP fragt: Wann erschien der Hauptinhalt? INP fragt: Als ich die Seite benutzt habe, hat sie reagiert?

Die Grenzwerte, die zählen

Die veröffentlichten Bereiche für INP lauten:

• Gut: höchstens 200 Millisekunden
• Verbesserungswürdig: mehr als 200 und bis zu 500 Millisekunden
• Schlecht: mehr als 500 Millisekunden

Wie bei den anderen Core Web Vitals zählt das 75. Perzentil der Seitenaufrufe, getrennt nach Mobil und Desktop. Eine Seite besteht, wenn mindestens drei von vier Aufrufen bei 200 Millisekunden oder darunter bleiben.

Die Zahlen sind nicht willkürlich. Forschung zur wahrgenommenen Reaktionszeit legt nahe, dass Rückmeldungen innerhalb von etwa 100 Millisekunden als sofort empfunden werden. Der Grenzwert von 200 Millisekunden lässt Spielraum für echte Geräte. Dauert eine Reaktion eine halbe Sekunde, bemerken die meisten Menschen die Verzögerung und tippen noch einmal.

Welche Interaktionen zählen

INP beobachtet drei Arten von Eingaben:

• Klicks mit der Maus
• Tippen auf einem Touchscreen
• Tastendrücke auf einer physischen oder virtuellen Tastatur

Hovern und Scrollen zählen nicht. Scrollen per Tastatur ist ein Sonderfall: Der Tastendruck ist eine Interaktion, das ausgelöste Scrollen nicht.

Eine Interaktion löst oft mehrere Events aus. Ein Tippen kann pointerdown, pointerup und click erzeugen. Der Browser fasst sie zusammen und nimmt die längste Event-Dauer als Latenz dieser Interaktion.

Gibt es während eines Besuchs gar keine Interaktion, entsteht kein INP-Wert. Deshalb haben Seiten, die vor allem gelesen werden, etwa lange Artikel, oft wenige INP-Daten. Shops, Konfiguratoren und Web-Apps erzeugen dagegen viele.

Wie der Wert zustande kommt

INP ist kein Durchschnitt. Bei den meisten Seiten ist es die langsamste Interaktion des Besuchs. Auf Seiten mit sehr vielen Interaktionen ignoriert der Browser pro 50 Interaktionen einen der höchsten Werte. So bestimmt ein einzelner Ausreißer auf einer viel genutzten Seite nicht das Ergebnis. In der Praxis liegt der gemeldete Wert nah an den schlechtesten Interaktionen, die Nutzer tatsächlich erlebt haben.

Das ist Absicht. Eine Seite, die auf neun Klicks sofort reagiert und beim zehnten einfriert, fühlt sich für die Person, die zum zehnten Mal klickt, trotzdem kaputt an.

Die drei Phasen einer Interaktion

Jede Interaktionslatenz zerfällt in drei aufeinanderfolgende Phasen. Wenn du weißt, welche langsam ist, weißt du, wo du suchen musst.

1. Eingabeverzögerung (Input Delay): die Zeit von der Eingabe, bis die Event-Handler starten. Sie wächst, wenn der Main Thread mit etwas anderem beschäftigt ist, etwa mit einem Skript, das noch vom Laden läuft, mit der Hydration eines JavaScript-Frameworks oder mit einem Timer.
2. Verarbeitungsdauer (Processing Duration): die Zeit, die die Event-Handler selbst brauchen. Schwere Handler, die Daten filtern, große Teile der Seite neu rendern oder Analytics synchron senden, machen diese Phase lang.
3. Darstellungsverzögerung (Presentation Delay): die Zeit vom Ende der Handler bis der Browser das nächste Frame zeichnet. Ein großes DOM, aufwendige Style- und Layout-Berechnungen und große Rendering-Updates bremsen hier.

Der Main Thread des Browsers erledigt den Großteil dieser Arbeit nacheinander. Jede Aufgabe, die ihn länger als 50 Millisekunden blockiert, heißt Long Task. Long Tasks sind die häufigste Ursache für einen schlechten INP.

Warum INP First Input Delay ersetzt hat

Google hat INP am 12. März 2024 zum Core Web Vital gemacht und damit First Input Delay (FID) abgelöst. FID hatte zwei Schwächen. Es betrachtete nur die erste Interaktion eines Besuchs, und es maß nur die Eingabeverzögerung, nicht die Zeit für die Handler und nicht die Zeit bis zur Aktualisierung des Bildschirms.

Viele Websites hatten nahezu perfekte FID-Werte, während ihre Nutzer später im Besuch zähe Menüs und Filter erlebten. INP schließt diese Lücke, weil es alle Interaktionen und den gesamten Weg bis zum nächsten Frame abdeckt. Wenn ein Audit oder Dashboard noch FID als Metrik für die Reaktionsfähigkeit ausweist, ist es veraltet.

Was einen schlechten INP meistens verursacht

• Ausgelasteter Main Thread beim Laden. Nutzer interagieren oft, während die Seite noch Skripte ausführt. Große Bundles, Framework-Hydration und Third-Party-Tags erzeugen Eingabeverzögerung genau dann, wenn Menschen zum ersten Mal tippen.
• Teure Event-Handler. Ein Klick, der Datenverarbeitung, ein komplettes Neu-Rendern eines Komponentenbaums und mehrere Tracking-Aufrufe in einem synchronen Block auslöst, lässt Nutzer warten.
• Großes DOM und teures Layout. Seiten mit Tausenden Elementen, tief verschachtelten Strukturen oder Code, der direkt nach einer Style-Änderung Layout-Werte ausliest, zwingen den Browser zu aufwendigen Neuberechnungen.
• Third-Party-Skripte. Chat-Widgets, A/B-Test-Tools, Tag-Manager und Werbeskripte konkurrieren um denselben Main Thread. Einzeln mag jedes in Ordnung sein, zusammen erzeugen sie Long Tasks.
• Langsame Geräte. Ein Handler, der auf dem Entwickler-Laptop 40 Millisekunden braucht, kann auf einem Android-Smartphone der Mittelklasse ein Mehrfaches davon brauchen. Deshalb ist der mobile INP meistens schlechter als der Desktop-INP.

Wie du INP verbesserst

Behebe die Phase, die langsam ist, und beginne mit den Interaktionen, die für Nutzer und Geschäft am wichtigsten sind.

Gegen Eingabeverzögerung reduzierst du das JavaScript, das während und direkt nach dem Laden läuft. Teile Bundles auf, verschiebe Skripte, die nicht sofort gebraucht werden, und lade Third-Party-Tags später oder nur dort, wo sie gebraucht werden. Frameworks mit partieller oder progressiver Hydration können die Arbeit verringern, die frühe Interaktionen blockiert. Die Rendering-Seite dieser Abwägungen behandelt der Eintrag zu JavaScript-Rendering für SEO.

Gegen lange Verarbeitungsdauer gibst du zuerst sichtbares Feedback und erledigst die schwere Arbeit danach. Zerlege lange Tasks in kleinere und gib zwischendurch den Main Thread frei, damit der Browser dazwischen zeichnen kann. In Chromium-basierten Browsern ist scheduler.yield() dafür der sauberste Weg, anderswo funktioniert ein Fallback mit setTimeout. Verschiebe aufwendige Berechnungen in einen Web Worker, entprelle Handler, die bei jedem Tastendruck feuern, und sende Analytics, ohne das Update zu blockieren.

jsasync function onFilterChange(event) {
  updateCheckboxState(event.target);   // zuerst sichtbares Feedback
  await scheduler.yield();             // Browser zeichnen lassen
  renderFilteredProducts();            // schwere Arbeit danach
  queueAnalytics("filter_change");     // Unkritisches zuletzt
}

Gegen Darstellungsverzögerung hältst du das DOM schlank, renderst große Listen nicht auf einmal und vermeidest es, Layout-Eigenschaften direkt nach dem Schreiben von Styles auszulesen. Mit CSS content-visibility kann der Browser Rendering-Arbeit für Inhalte außerhalb des sichtbaren Bereichs überspringen.

INP richtig messen

Felddaten

INP ist im Kern eine Feldmetrik. Der Chrome User Experience Report sammelt sie bei zustimmenden Chrome-Nutzern über ein rollierendes Fenster von 28 Tagen. PageSpeed Insights zeigt den Wert für URL oder Origin, wenn genug Daten vorhanden sind, und der Core-Web-Vitals-Bericht in der Google Search Console gruppiert betroffene URLs.

CrUX zeigt dir, dass es ein Problem gibt, aber nicht, welche Interaktion es verursacht. Dafür hilft Real User Monitoring. Die Open-Source-Bibliothek web-vitals hat einen Attribution-Build, der das Ziel der Interaktion, ihren Typ und die Dauer jeder der drei Phasen meldet. Zusammen mit der Long Animation Frames API kann sie auf das Skript zeigen, das ein langsames Frame verursacht.

Labordaten

Ein normaler Lighthouse-Navigationstest lädt die Seite und hört dann auf. Niemand klickt, also kann er INP nicht messen. Stattdessen meldet Lighthouse die Total Blocking Time (TBT), die zusammenfasst, wie stark der Main Thread während des Ladens blockiert war. TBT hängt mit Problemen bei der Eingabeverzögerung zusammen, aber eine Seite kann eine niedrige TBT haben und trotzdem einen langsamen Handler, der den INP ruiniert.

Um eine Interaktion im Labor nachzustellen, nutzt du das Performance-Panel der Chrome DevTools. Die Live-Metriken zeigen den INP deiner eigenen Interaktionen, während du die Seite bedienst. Schalte die CPU-Drosselung ein, um ein langsameres Smartphone zu simulieren, zeichne einen Trace auf, während du die langsame Interaktion wiederholst, und such im Main-Thread-Bereich nach Long Tasks. Lighthouse bietet außerdem einen Timespan-Modus, der INP aufzeichnet, während du interagierst.

Ein Beispiel Schritt für Schritt

Ein Onlineshop sieht einen schlechten mobilen INP für seine Kategorieseiten. Das Team setzt den Attribution-Build von web-vitals ein und stellt fest, dass die meisten langsamen Interaktionen Taps auf den Größenfilter sind, mit einer Verarbeitungsdauer von rund 400 Millisekunden auf Mittelklasse-Smartphones.

Der Trace zeigt einen einzigen Long Task: Der Klick-Handler aktualisiert den Filterzustand, rendert alle 120 Produktkarten neu, schreibt die URL um und feuert zwei Tracking-Aufrufe, alles in einem Block. Die Lösung: die Checkbox sofort aktualisieren, den Main Thread freigeben, die Produktliste in kleineren Stücken rendern und das Tracking danach senden. Nutzer sehen das Häkchen jetzt innerhalb eines Frames, die Liste folgt kurz danach. Die Labor-Traces bestätigen, dass der Long Task verschwunden ist. Der Feld-INP verbessert sich in den folgenden Wochen, während neue Aufrufe die alten Daten ersetzen.

INP und SEO

Google nutzt die Core Web Vitals als Teil der Page Experience in seinen Ranking-Systemen und empfiehlt gute Werte. Ebenso klar sagt Google, dass Relevanz zuerst kommt. Ein besserer INP bringt eine irrelevante Seite nicht nach vorn.

Das stärkere Argument ist, was INP misst: ob Menschen deine Seite tatsächlich benutzen können. Langsame Reaktionen bei Filtern, Formularen, Menüs und Checkout-Schritten treffen die Besucher, die gerade etwas tun wollen. Auf vielen Websites haben genau die Templates den schlechtesten INP, die dem Umsatz am nächsten sind. Reaktionsfähigkeit zählt außerdem auf Smartphones am meisten, wo Mobile SEO und die Mobile-First-Indexierung ohnehin den Fokus setzen.

Häufige Fehler

• die TBT in Lighthouse optimieren und annehmen, damit sei der INP gelöst
• Interaktionen nur auf einem schnellen Desktop-Rechner testen
• weiterhin FID als Interaktionsmetrik berichten
• jedes Third-Party-Skript auf jedem Template laden, auch dort, wo es niemand braucht
• den ersten Klick optimieren und spätere Interaktionen ignorieren
• einen ganzen Seitenbereich neu rendern, obwohl sich nur ein Element geändert hat
• erwarten, dass sich die Felddaten am Tag nach dem Deployment verbessern

Crawl-Foundry-Perspektive

Der Site Audit von Crawl Foundry nutzt den offiziellen Lighthouse-Runner (Lighthouse 13) auf unseren eigenen Servern, jede Messung läuft als isolierte Aufgabe. Der Site Audit ist eine bezahlte Datenaktion, deren Preis du vor dem Start siehst. Die Lighthouse-Messung selbst kostet dich nichts extra.

Wir wollen genau sein, was das für INP zeigen kann und was nicht. Ein Lighthouse-Seitenaufruf klickt nichts an und liefert deshalb keinen INP-Wert. Er zeigt aber, wie stark der Main Thread beim Laden blockiert ist, und das ist eine häufige Ursache für Eingabeverzögerung. Nutze das als Spur und bestätige die langsame Interaktion dann mit Felddaten, Real User Monitoring oder einem DevTools-Trace. Weil der Site Audit von Crawl Foundry auch Statuscodes, Indexierbarkeit und interne Links erfasst, kannst du diese Arbeit auf indexierbare Templates konzentrieren, die für die Suche zählen.

Verwandte Begriffe

• Seitengeschwindigkeit
• Server-Side Rendering
• Page-Experience-Metriken
• Website-Geschwindigkeit optimieren
• Nutzersignale im SEO

Quellen für den Review

• web.dev: Interaction to Next Paint (INP)
• web.dev: Interaction to Next Paint optimieren
• web.dev: Lange Aufgaben optimieren
• Google Search Central Blog: Introducing INP to Core Web Vitals
• Google Search Central: Core Web Vitals und Google-Suchergebnisse
• Chrome for Developers: Long Animation Frames API
• W3C: Event Timing API