Was ist der INP?

Interaction to Next Paint misst, wie lange eine Seite braucht, um zu zeigen, dass sie verstanden hat, was der Nutzer gerade getan hat. Die Uhr startet mit dem Klick, der Berührung oder dem Tastendruck und stoppt beim ersten Bild, das das Ergebnis widerspiegelt. Gemessen wird nicht, wie lange die Aktion zu Ende dauert, sondern wie lange es dauert, bis überhaupt etwas zu sehen ist.

Diese Unterscheidung ist der Kern der Kennzahl. Ein Knopf, der ein Menü öffnet, darf eine halbe Sekunde brauchen, um dessen Inhalt zu laden, und trotzdem einen guten INP haben, wenn das Menü sofort leer erscheint und sich danach füllt. Umgekehrt schneidet ein Knopf mit sehr wenig Arbeit schlecht ab, wenn der Browser beim Drücken gerade mit etwas anderem beschäftigt war.

Es zählen nur drei Arten von Interaktion: Klick oder Berührung, Tastendruck und Tastatureingaben auf fokussierbaren Elementen. Scrollen oder Überfahren mit der Maus zählt nicht, auch wenn ruckelndes Scrollen sich genauso schlecht anfühlt. Dafür gibt es andere Signale innerhalb der Core Web Vitals.

Dieses Detail erklärt, warum sich der INP nicht mit Ladetricks schönen lässt. Eine Seite kann in einer halben Sekunde vollständig ankommen und auf den ersten Klick miserabel reagieren, weil der Browser noch mit dem JavaScript beschäftigt ist, das mit ihr kam. Auslieferungsgeschwindigkeit und Reaktionsfähigkeit sind zweierlei, und der Nutzer merkt Letzteres früher: Dass eine Seite lädt, erwartet er, dass sie stumm bleibt, während er sie schon benutzt, nicht.

Deshalb lohnt es, Page Speed als zwei getrennte Fragen zu denken. Wie lange es dauert, bis etwas zu sehen ist, beantwortet der LCP; wie lange es dauert, bis etwas reagiert, der INP. Wer nur die erste optimiert, bekommt Seiten, die schnell aussehen und sich schwer anfühlen, und dieser Bruch zeigt sich in der Absprungrate früher als in jedem technischen Bericht.

Jede gemessene Interaktion zerfällt in drei aufeinanderfolgende Phasen, und ihre Summe wird mit den Schwellen verglichen. Google wertet einen INP bis 200 Millisekunden als gut, bis 500 als verbesserungswürdig, darüber als schlecht. Wie bei den übrigen Felddaten wird am 75. Perzentil echter Besuche bewertet, ein guter Wert auf dem Notebook des Teams sagt also nichts.

Welche Phase am schwersten wiegt, entscheidet vollständig darüber, wo gearbeitet wird. Überwiegt die Eingabeverzögerung, sind lange bereits laufende Aufgaben das Problem, und die Lösung liegt im Tag Manager und bei fremden Skripten. Überwiegt die Darstellung, ist die Größe des Dokuments das Problem, und das wird in der Vorlage des CMS behoben.

Zwischen den drei Phasen besteht eine Asymmetrie, die man im Kopf behalten sollte. Eingabeverzögerung und Darstellung hängen vom Gesamtzustand der Seite ab: wie viele Skripte laufen, wie groß das Dokument ist, was sonst gerade passiert. Die Verarbeitung dagegen hängt am konkreten Code des gedrückten Knopfes. Die erste Art Problem behebt man einmal und verbessert damit alle Interaktionen, die zweite muss Element für Element behoben werden.

In einer Prüfung zum technischen SEO entscheidet dieser Unterschied die Reihenfolge. Es lohnt, mit dem zu beginnen, was die ganze Vorlage betrifft, weil eine einzige Korrektur dort das Perzentil auf einen Schlag bewegt, während das Optimieren eines einzelnen Knopfes nur die Besuche verbessert, die ihn drücken.

Bis März 2024 war First Input Delay die Kennzahl für Interaktivität, und der Wechsel war keine Kosmetik. Der FID maß nur die erste Interaktion eines Besuchs und von dieser nur die Wartephase, ohne Verarbeitung und ohne Zeichnen. Heraus kam eine Kennzahl, die leicht zu bestehen war: Fast alle Seiten schafften sie, auch wenn sie sich im Gebrauch zäh anfühlten.

Der INP misst alle Interaktionen und alle drei Phasen und behält die schlechteste. Deshalb sprang bei vielen Seiten die Ampel von Grün auf Gelb, ohne dass sich etwas geändert hätte. Sie wurden nicht schlechter: Die alte Regel maß nicht, was sie zu messen vorgab.

Diese Geschichte trägt eine Lehre über die Geschwindigkeit hinaus. Eine Kennzahl, die fast jeder besteht, beschreibt nicht die Wirklichkeit, sondern ihre eigene Schwelle. Dasselbe gilt für jeden KPI in einem Bericht aus der Web-Analyse.

Der Wechsel hatte außerdem eine praktische Folge für die Berichterstattung. Viele Kundenberichte zeigten den FID noch Monate nach seiner Abschaffung, weil die Kennzahl fest in der Berichtsvorlage stand und niemand sie überprüfte. Heraus kamen Präsentationen mit einer grünen Ampel, die keiner tatsächlichen Bewertung durch Google mehr entsprach.

Es lohnt, jeden geerbten KPI nach demselben Maßstab zu prüfen: Wenn sich niemand erinnert, wann der Schwellenwert festgelegt wurde, beschreibt er vermutlich eine Lage, die es nicht mehr gibt. Das gilt für Geschwindigkeit ebenso wie für betriebswirtschaftliche Kennzahlen, etwa die Conversion je Kanal in einem Bericht aus der Web-Analyse, den seit zwei Jahren niemand angefasst hat.

Der erste Schritt ist nicht Optimieren, sondern Herausfinden, welche einzelne Interaktion den Wert nach unten zieht. Die Feldwerkzeuge benennen das schuldige Element, und oft ist es genau eines: ein Katalogfilter, ein Variantenwähler auf einer E-Commerce-Produktseite, ein Aufklappmenü mit zu vielen Ebenen.

Von da an sind die Hebel wenige und bekannt. Lange JavaScript-Aufgaben zerteilen, damit der Browser zwischen den Stücken auf den Nutzer reagieren kann. Aus dem Ereignisbehandler alles herausnehmen, was für die sofortige Antwort nicht gebraucht wird. Das Dokument verkleinern, weil jeder zusätzliche Knoten die Layoutberechnung verteuert. Und nachsehen, welche fremden Skripte über den Google Tag Manager geladen werden, denn dort wächst das Problem meist, ohne dass es jemand entschieden hätte.

Für die Kontrolle danach gelten dieselben Regeln wie bei den anderen Felddaten: Die Werte in Search Console brauchen Wochen, am Folgetag zu messen sagt nichts. Und weil der INP unmittelbar das berührt, was der Nutzer spürt, lohnt der Abgleich mit Absprungrate und Conversion der betroffenen Seite.

Ein häufiger Fall verdient eine eigene Erwähnung, weil er sich ohne Codeänderung lösen lässt. Viele Seiten laden über den Tag Manager Skripte, die niemand mehr nutzt: ein einmal getestetes Heatmap-Werkzeug, ein abgelöster Chat, ein Pixel einer beendeten Kampagne. Jedes davon konkurriert bei jedem Besuch um den Hauptthread. Diese Liste durchzusehen und Totes zu löschen ist meist die billigste Verbesserung überhaupt.

Die zweite billige Maßnahme ist die Frage, was beim Laden laufen muss und was warten könnte. Eine Heatmap oder ein Sitzungswerkzeug muss nicht in der ersten Sekunde starten; sie bis nach der ersten Interaktion zu verschieben ändert nichts an dem, was sie messen, und gibt genau den Moment frei, den der INP beobachtet.

• Die Startseite optimieren, während das Problem in einer Produkt- oder Filtervorlage sitzt, die niemand misst.
• Den INP mit der Gesamtdauer der Aktion verwechseln: Es zählt, wann die Antwort zu sehen ist, nicht wann die Arbeit endet.
• Nur auf dem Desktop prüfen, obwohl die Mobile-First-Indexierung entscheidet und ältere Telefone für dieselbe Aufgabe ein Vielfaches brauchen.
• Eine Ladeanimation einbauen und das Problem für gelöst halten: Die Animation verbessert die Wahrnehmung, nicht die Kennzahl.
• Die Schwellen als Prüfung behandeln. Von 480 auf 320 Millisekunden zu kommen verbessert das echte Erleben, auch wenn das Etikett gelb bleibt — genau wie beim LCP.