Was INP ist und wie man es misst.
INP ist die Zeit von einer Nutzerinteraktion bis zur sichtbaren Antwort der Seite, und Google zählt unter 200 Millisekunden als gut.
Das ist die Metrik, die im März 2024 in die Core Web Vitals kam und FID ablöste. Der Wechsel zählte, denn FID maß nur die VERZÖGERUNG der ERSTEN Interaktion — die Zeit vom Klick des Nutzers bis zum Beginn der Verarbeitung im Browser. Ob das Ergebnis des Klicks je den Bildschirm erreichte, wurde nie gemessen.
Die praktische Folge: Eine Seite konnte auf den ersten Klick schnell antworten und bei jeder weiteren Interaktion einfrieren — und FID kam trotzdem perfekt heraus. INP betrachtet die Interaktionen der ganzen Sitzung und misst nicht die Verzögerung, sondern den vollen Zyklus. Eine viel härtere und viel ehrlichere Prüfung.
Drei Phasen
Die Dauer einer Interaktion zerfällt in drei Teile, und die Diagnose verlangt ihre Trennung.
- Eingabeverzögerung — der Nutzer klickte, aber der Hauptthread ist mit anderer Arbeit beschäftigt. Die Zeit, bis der Handler zu laufen beginnt.
- Verarbeitungszeit — wie lange brauchten die Event-Handler selbst? Die direkte Verantwortung Ihres Codes.
- Darstellungsverzögerung — der Handler ist fertig, aber wann konnte der Browser zum Malen des nächsten Frames übergehen?
Die meisten Teams denken nur an die zweite Phase und optimieren die Event-Handler. In den Felddaten entfällt der größte Anteil aber meist auf die erste und dritte Phase — das Problem ist nicht, dass Ihr Handler langsam ist, sondern dass der Hauptthread mit etwas anderem beschäftigt ist.
Die praktischste Folge dieser Unterscheidung: Die meisten INP-Probleme leben an einer von der Interaktion unabhängigen Stelle — in langen Skripten beim Seitenladen, in Drittanbieter-Code oder in der Hydrationsarbeit eines schweren Frameworks.
Der Hauptthread
Im Browser läuft JavaScript auf einem einzigen Thread, und dieser Thread ist zugleich für Layoutrechnung und Malen zuständig. Während eine lange JavaScript-Aufgabe läuft, kann der Browser nichts malen und keinen Klick beantworten — die Seite wirkt eingefroren.
Die wirksamste INP-Behandlung ist deshalb das Teilen langer Aufgaben. Jede Aufgabe über fünfzig Millisekunden lässt die Seite für diese Dauer reaktionslos. Die Arbeit in kleine Stücke zu teilen und dazwischen dem Browser die Kontrolle zurückzugeben ändert die Gesamtzeit nicht — hält die Seite aber benutzbar.
Die zweite Behandlung: die Arbeit ganz vom Hauptthread nehmen. Schwere Berechnungen können in Hintergrund-Threads wandern; dort laufender Code blockiert die Oberfläche nie. Nicht für jede Arbeit möglich, aber für rechenintensive die sauberste Lösung.
Die dritte und ertragreichste: die unnötige Arbeit gar nicht erst tun. Eine unbenutzte Bibliothek zu laden und auszuführen kostet mehr, als die beste Teilstrategie sparen kann. Der erste Schritt der INP-Arbeit ist nicht Optimierung, sondern Inventur.
Das schnellste JavaScript ist das JavaScript, das nie läuft.
Warum es sich im Labor nicht messen lässt
Die ärgerlichste Seite von INP: Laborwerkzeuge können es nicht verlässlich messen. Der Grund steckt in der Definition: Die Metrik betrachtet echte Nutzerinteraktionen, und ein Prüfwerkzeug interagiert nicht mit der Seite. Werkzeuge können eine Schätzung liefern, aber die repräsentiert nicht die echte Nutzung.
Für INP sind Felddaten deshalb keine Option, sondern eine Notwendigkeit. Der Browser sammelt die Werte, die echte Nutzer erleben, und diese Daten werden sowohl in Googles eigenen Berichten als auch über einen kleinen Messcode auf der eigenen Seite erreichbar.
Der Vorteil der eigenen Messung ist das Detail: Sie sehen, welche Interaktion auf welcher Seite an welchem Element langsam war. Googles Sammelbericht gibt Ihnen eine Zahl; die eigene Messung sagt, woher diese Zahl kommt.
Eine Datenschutznotiz: Diese Messung braucht keine Cookies und sammelt keine personenbezogenen Daten — aufgezeichnet werden nur Dauerwerte und der Selektor des berührten Elements. Auf dieser Website sagt der Datenschutztext, dass keine Cookies verwendet werden, und die Suite misst das bei jedem Lauf; keine hinzukommende Messung darf diese Aussage brechen.
Wo anfangen
Anders als bei den anderen beiden Metriken beginnt die INP-Arbeit mit einer Inventur. Die Quelle des Problems ist meist nicht Ihr Interaktionscode, sondern die Summe der auf der Seite laufenden Arbeit — also muss zuerst diese Summe sichtbar werden.
- Listen Sie die geladenen Skripte — wie viele Dateien, wie viele Byte, welche sind Drittanbieter?
- Finden Sie die langen Aufgaben — das Performance-Panel markiert Aufgaben über fünfzig Millisekunden; welche Datei ist die Quelle?
- Wiegen Sie die Drittanbieter — Chat-Blase, Analytik, Werbung. Die Kosten jedes einzelnen für den Hauptthread lassen sich getrennt messen.
- Fragen Sie nach dem wirklich Nötigen — welche Bibliothek dient welchem Merkmal? Entfernen Sie Unbenutztes.
- Verschieben Sie den Rest — Arbeit ohne Interaktionsbedarf kann hinter das erste Malen rücken.
- Teilen Sie die langen Aufgaben — das Unteilbare wandert in einen Hintergrund-Thread.
Diese Reihenfolge legt den größten Gewinn nach oben: Ein nie geladenes Skript kostet null, und keine Optimierung erreicht dieses Ergebnis. Auf dieser Website sind die Vendor-Bibliotheken nach gzip 55,7 Kilobyte, und auf der Liste stehen nur die fünf wirklich benutzten Module — das konkrete Gegenstück der Inventurdisziplin.
Eine Messnotiz: INP wird in den Felddaten als 75. Perzentil berichtet — die Zeit, die drei Viertel der Nutzer erleben. Der auf Ihrem starken Gerät gemessene Wert liegt am besten Ende dieser Verteilung und repräsentiert das echte Nutzererlebnis nicht. Auf einem schwachen Gerät zu testen ist für INP kritischer als für die anderen beiden Metriken.
Der Preis der Framework-Wahl
Die Entscheidung mit der größten Wirkung auf INP ist meist eine, die nie als Performance-Entscheidung getroffen wird: welches Frontend-Framework verwendet wird. Auf dem Server erzeugte und im Client rehydrierte Seiten beschäftigen den Hauptthread für die Dauer dieser Hydration, und jeder Klick in diesem Fenster verzögert sich.
Das macht Frameworks nicht schlecht — komplexe Anwendungen mögen sie brauchen. Aber für eine Präsentationsseite, ein Blog oder eine Vitrine hat dieser Preis selten einen Gegenwert. Auf dieser Website gibt es keine clientseitige Hydration; die Seiten kommen als Dateien, und JavaScript baut nur die Bewegungsschicht.
Das gemessene Ergebnis: eigener Code nach gzip 28 Kilobyte, Vendor-Bibliotheken 55,7 Kilobyte. Zusammen 83,7 Kilobyte, deutlich unter der Budgetdecke von 150 Kilobyte. Diese Zahl ist kein Optimierungserfolg, sondern die natürliche Folge einer Architekturentscheidung.