Hauptbereich
Agency
technisches-seo

Interaction to Next Paint (INP) verstehen und verbessern

Redaktion ·

INP ist die Metrik, die misst, wie schnell deine Seite auf das reagiert, was Nutzer tatsächlich tun — klicken, tippen, auf Mobile antippen. Seit dem 12. März 2024 ist Interaction to Next Paint offizieller Core Web Vital und hat First Input Delay (FID) abgelöst. Das ist mehr als ein Namenstausch: FID war eine fast geschönte Metrik, INP ist ehrlich.

Was INP eigentlich misst — und warum es härter ist als FID

INP misst die Latenz von einer Nutzer-Interaktion bis zu dem Moment, in dem der Browser den nächsten Frame zeichnen kann. Drei Phasen stecken in jeder dieser Latenzen:

Input Delay. Die Zeit zwischen der Interaktion und dem Start des Event-Handlers. Wenn der Main Thread gerade mit einer langen Aufgabe beschäftigt ist, wartet dein Klick — der Handler kommt schlicht nicht dran.

Processing Duration. Die Zeit, die alle zugehörigen Event-Handler brauchen, um durchzulaufen. Hier sitzt der Code, den du selbst geschrieben hast: das onClick, das State-Update, die Validierung.

Presentation Delay. Die Zeit nach dem Handler, bis der Browser das Ergebnis tatsächlich auf den Bildschirm rendert — Style-Recalc, Layout, Paint.

Der entscheidende Unterschied zu FID: FID maß nur die Verzögerung der ersten Interaktion und auch nur deren Input Delay — nicht die Verarbeitung, nicht das Rendering. Eine Seite konnte einen Top-FID-Wert haben und sich trotzdem bei jedem zweiten Klick zäh anfühlen. INP beobachtet alle Interaktionen über die gesamte Lebensdauer der Seite und nimmt im Kern den schlechtesten Wert. Wer also einen einzigen ruckelnden Button hat, sieht das jetzt im Score.

Die Schwellen — und wie der Wert zustande kommt

Google bewertet INP in drei Stufen, gemessen am 75. Perzentil aller Seitenaufrufe (Stand web.dev, Juni 2026):

  • gut: ≤ 200 ms
  • verbesserungswürdig: 201–500 ms
  • schlecht: > 500 ms

Gemessen werden Klicks, Tap auf Touchscreens und Tastendrücke. Scrollen, Hovern und Zoomen zählen explizit nicht — das sind keine diskreten Interaktionen mit Handler-Antwort.

Beim Zusammenfassen über die Seitenlebensdauer gilt: Hat eine Seite weniger als 50 Interaktionen, zählt schlicht die schlechteste. Bei mehr Interaktionen ignoriert das Verfahren einen Ausreißer pro 50 Interaktionen, damit ein einzelner Hänger nicht das ganze Bild kippt. Praktisch heißt das: Du kannst dir keinen dauerhaft langsamen Interaktionspfad leisten, einen seltenen Ausrutscher schon.

Die Hauptursache: lange Tasks blockieren den Main Thread

Fast jedes INP-Problem hat dieselbe Wurzel — JavaScript, das den Main Thread zu lange am Stück belegt. Der Browser kann pro Thread nur eine Sache gleichzeitig tun. Läuft eine Task länger als 50 ms (eine Long Task), kann in dieser Zeit kein Event-Handler starten und kein Frame gezeichnet werden. Jeder Klick, der in dieses Fenster fällt, sammelt Input Delay.

Typische Quellen langer Tasks:

  • große, ununterbrochene JavaScript-Bundles, die beim Laden alles auf einmal parsen und ausführen
  • schwere Event-Handler, die synchron rendern, sortieren oder filtern
  • Third-Party-Skripte (Tag-Manager, Chat-Widgets, A/B-Tools), die ungebremst im Main Thread laufen
  • teure Layout-Arbeit in der Presentation-Phase

Das verwandte Thema Render-Blocking Resources betrifft eher den initialen Aufbau — INP dagegen schmerzt dauerhaft, bei jeder Interaktion nach dem Laden.

Die Hebel — Arbeit aufbrechen statt verschieben

Long Tasks splitten. Brich lange synchrone Funktionen in kleinere Häppchen und gib dem Main Thread zwischendurch die Kontrolle zurück. Modern dafür: scheduler.yield() — ein bewusstes „atme kurz durch”, nach dem die eigene Aufgabe priorisiert weiterläuft. Als Fallback tut es ein await auf eine setTimeout-Promise oder requestIdleCallback für unkritische Arbeit. Dazwischen kann der Browser auf wartende Klicks reagieren.

Arbeit von der Interaktion entkoppeln. Trenne die sichtbare Reaktion von der teuren Arbeit. Beim Klick zuerst nur das UI-Feedback rendern (Button-State, Spinner), die eigentliche Berechnung danach in einem yield oder im nächsten Frame. Der Nutzer sieht sofort, dass etwas passiert — das ist gefühlt schneller, auch wenn das Ergebnis gleich lange braucht.

Weniger und leichteres JavaScript. Code-Splitting, damit nicht alles beim ersten Render parst. Ungenutzten Code entfernen. Third-Party-Skripte hinterfragen und verzögert laden. Jede Zeile JS, die nicht läuft, kann auch keine Long Task erzeugen.

Web Worker für schwere Rechenarbeit. Was nicht aufs DOM zugreifen muss — Parsing großer Datenmengen, Sortieren, Kryptografie — gehört in einen Web Worker. Der läuft in einem eigenen Thread, der Main Thread bleibt frei für Interaktionen.

Abgrenzung zu LCP und CLS

Die drei Core Web Vitals messen verschiedene Dinge, und sie konkurrieren teilweise sogar:

  • LCP misst die Ladegeschwindigkeit — wann das größte Element sichtbar ist. Ein Ladeproblem.
  • INP misst die Reaktionsschnelligkeit nach dem Laden — wie flüssig die Seite auf Eingaben reagiert. Ein Laufzeitproblem.
  • CLS misst die visuelle Stabilität — ob Inhalte unerwartet springen. Ein Layout-Problem.

Der Konflikt: Wer LCP durch aggressives Vorladen von viel JavaScript verbessert, kann INP verschlechtern, weil mehr Skript-Arbeit den Main Thread belastet. Gute Performance heißt, alle drei zusammen zu betrachten — nicht eine Metrik gegen die andere zu optimieren. Wer tiefer in den Gesamtzusammenhang von Rendering und Indexierung will, findet ihn im Überblick zu technischem SEO.

FAQ

Seit wann ist INP ein Core Web Vital? Seit dem 12. März 2024. An diesem Tag hat INP First Input Delay (FID) als drittes Core Web Vital abgelöst. FID gibt es als Diagnose-Metrik nicht mehr im offiziellen Set.

Was ist der gute INP-Wert? Ein INP von 200 Millisekunden oder weniger gilt als gut, gemessen am 75. Perzentil der Seitenaufrufe. 201 bis 500 ms ist verbesserungswürdig, über 500 ms ist schlecht.

Warum ist INP strenger als FID? FID maß nur die Eingabeverzögerung der allerersten Interaktion. INP misst alle Interaktionen über die ganze Seitenlebensdauer und schließt auch Verarbeitungs- und Rendering-Zeit ein. Ein einzelner langsamer Button fällt jetzt auf.

Was ist die häufigste Ursache für schlechtes INP? Lange JavaScript-Tasks, die den Main Thread blockieren. Solange eine Task läuft, kann kein Event-Handler starten und kein Frame gezeichnet werden — jeder Klick in diesem Fenster wird langsam.

Hilft scheduler.yield() wirklich? Ja. scheduler.yield() gibt dem Browser zwischendurch die Kontrolle zurück, sodass wartende Interaktionen drankommen, und setzt die eigene Aufgabe danach priorisiert fort. Wo es noch nicht verfügbar ist, helfen Aufteilung über setTimeout oder Web Worker.

Themenuebersicht

Technisches SEOCore Web VitalsPageSpeed & Performance