INP.

INP ist die Zeit von einer Nutzerinteraktion bis zur sichtbaren Antwort der Seite; Google wertet Werte unter 200 Millisekunden als gut.

Im März 2024 kam die Metrik in die Core Web Vitals und löste FID ab. Der Wechsel war bedeutsam: FID maß nur die Verzögerung der ersten Interaktion, INP betrachtet alle Interaktionen der Sitzung und misst nicht die Verzögerung, sondern den vollen Zyklus — von der Eingabe bis zum nächsten Bildaufbau.

Die Dauer teilt sich in drei Abschnitte: Eingabeverzögerung (der Haupt-Thread ist beschäftigt), Verarbeitungszeit (Ereignisbehandlung) und Darstellungsverzögerung (bis der Browser den nächsten Frame zeichnet). Die meisten Teams denken nur an den zweiten; in Felddaten entfällt der größte Anteil meist auf den ersten und den dritten.

Die wirksamsten Behandlungen der Reihe nach: unnötiges JavaScript gar nicht erst laden, lange Aufgaben teilen und schwere Berechnungen in einen Hintergrund-Thread verlagern.

In Laborwerkzeugen lässt sich die Metrik nicht verlässlich messen, denn sie betrachtet echte Nutzerinteraktionen, und ein Prüfwerkzeug interagiert nicht mit der Seite. Für INP sind Felddaten keine Option, sondern Pflicht.

Jede Aufgabe, die länger als fünfzig Millisekunden läuft, lässt die Seite für diese Zeit reaktionslos. Die Arbeit in kleine Teile zu zerlegen und dazwischen die Kontrolle an den Browser zurückzugeben ändert die Gesamtdauer nicht, hält die Seite aber bedienbar.

Für die Messung lässt sich die Meldung des Browsers selbst nutzen: Zu jeder Interaktion trifft ein Dauerwert auf der Seite ein und kann an das eigene System gesendet werden. Der Vorteil liegt im Detail — Sie sehen, welche Interaktion auf welcher Seite und an welchem Element langsam ist.

Der größte einzelne Faktor ist meist eine Entscheidung, die nie als Leistungsentscheidung getroffen wurde: die Frontend-Architektur. Seiten, die im Client neu aufbauen, halten den Haupt-Thread währenddessen beschäftigt, und jeder Klick in diesem Fenster verzögert sich.

1. Unnötiges JavaScript gar nicht erst laden — der größte Gewinn steckt in der Inventur.
2. Lange Aufgaben teilen — jede Aufgabe über fünfzig Millisekunden friert die Seite ein.
3. Schwere Berechnung in den Hintergrund verlagern — den Haupt-Thread frei machen.
4. Fremdskripte abwägen — Chat-Blase, Analyse, Werbung.
5. Auf die Zeit nach der Interaktion verschieben — alles, was beim Laden nicht gebraucht wird.
6. Aus Felddaten messen — im Labor nicht verlässlich messbar.

Die Reihenfolge ist bewusst gewählt: Ein nie geladenes Skript kostet nichts, und keine Optimierung erreicht dieses Ergebnis.

Ein praktisches Ziel, um unter der Schwelle zu bleiben, lautet: Keine Aufgabe soll fünfzig Millisekunden überschreiten — denn fällt eine Interaktion mitten in eine solche Aufgabe, wächst die Verzögerung genau um diesen Betrag.