Seit März 2024 gehört Interaction to Next Paint zu den Core Web Vitals und hat First Input Delay abgelöst. Für viele Seitenbetreiber kam das überraschend, denn die alte Kennzahl stand bei fast jedem auf grün. Hier steht der neue Wert einmal in Ruhe erklärt. Nach dem Wechsel sah das plötzlich anders aus, ohne dass irgendjemand etwas an der Seite geändert hätte.
Das liegt nicht daran, dass Google strenger geworden wäre. Es liegt daran, dass der alte Wert eine schmeichelhafte Frage gestellt hat.
Was FID gemessen hat und warum das zu wenig war
First Input Delay maß die Verzögerung zwischen der allerersten Interaktion eines Besuchers und dem Moment, in dem der Browser überhaupt anfangen konnte, darauf zu reagieren. Zwei Einschränkungen stecken darin. Erstens nur die erste Interaktion. Zweitens nur bis zum Beginn der Verarbeitung, nicht bis zum sichtbaren Ergebnis.
Praktisch hieß das: Wenn die Seite nach dem Laden kurz ruhig war und der Besucher in genau diesem Moment klickte, war der Wert hervorragend. Was danach passierte, wenn er das Menü öffnete, einen Filter setzte oder ein Formularfeld ausfüllte, floss gar nicht ein. Genau dort erleben Menschen aber die Zähigkeit einer Seite.
Was INP anders macht
Interaction to Next Paint schaut sich alle Interaktionen während des Besuchs an und misst jeweils die gesamte Dauer: von der Eingabe über die Verarbeitung bis zu dem Moment, in dem der Browser das Ergebnis auf den Bildschirm bringt. Aus allen gemessenen Interaktionen wird dann ein Wert nahe dem schlechtesten gebildet, damit einzelne Ausreißer nicht untergehen.
Als gut gilt ein Wert unter 200 Millisekunden, ab 500 gilt es als schlecht. Der Unterschied zum alten Verfahren ist erheblich, weil jetzt genau die Momente zählen, in denen viel gleichzeitig passiert: das Öffnen eines Menüs mit Animation, das Umschalten eines Filters, das Absenden eines Formulars.
Woran es in der Praxis hängt
Die Ursachen sind fast immer dieselben. An erster Stelle stehen lange Aufgaben im Hauptprozess des Browsers. Wenn ein Skript zweihundert Millisekunden am Stück rechnet, kann in dieser Zeit nichts anderes passieren, auch keine Reaktion auf einen Klick. Solche Blöcke entstehen bei großen Datenmengen, aufwendigen Filterlogiken oder Bibliotheken, die alles auf einmal aufbauen.
An zweiter Stelle steht die schiere Menge an Skripten von Dritten. Analysewerkzeuge, Chatfenster, Bewertungsanzeigen, Kartendienste, Zustimmungsdialoge. Jedes einzelne wirkt harmlos, in Summe konkurrieren sie um dieselbe Rechenzeit. Bei Seiten mit gewachsenem Werkzeugbestand ist das der größte Posten.
An dritter Stelle stehen Effekte, die bei jeder Interaktion das gesamte Layout neu berechnen lassen. Aufklappmenüs, die die Höhe animieren, sind ein Klassiker. Wer stattdessen mit Transformationen arbeitet, entlastet den Browser deutlich.
Was man konkret tun kann
Der erste Schritt ist Messen mit echten Daten. In der Search Console stehen die Feldwerte, und in den Entwicklerwerkzeugen des Browsers lässt sich eine einzelne Interaktion aufzeichnen und aufschlüsseln. Ohne diese Aufzeichnung optimiert man ins Blaue.
Danach: Lange Aufgaben aufteilen, damit der Browser zwischendurch Luft zum Reagieren hat. Skripte von Dritten durchgehen und alles entfernen, was niemand mehr auswertet. Zustimmungsdialoge so einbinden, dass sie nicht bei jedem Aufruf die halbe Seite neu aufbauen. Und Animationen auf Eigenschaften beschränken, die der Browser günstig verarbeiten kann.
Ein oft übersehener Punkt: Eine sichtbare Rückmeldung innerhalb weniger Millisekunden hilft messbar. Wenn ein Knopf sofort seinen Zustand ändert, während die eigentliche Arbeit im Hintergrund läuft, verbessert das nicht nur den Eindruck, sondern auch den Wert.
Wie viel Aufwand ist angemessen
Wie bei den anderen Core Web Vitals gilt: Es ist ein Signal unter vielen und ersetzt keine gute Antwort auf die Frage des Besuchers. Wenn deine Seite bei INP im gelben Bereich liegt und inhaltlich stark ist, ist das kein Notfall.
Anders sieht es aus, wenn Besucher tatsächlich mit der Seite arbeiten müssen, also bei Konfiguratoren, Filtern, Buchungsstrecken und Formularen mit vielen Feldern. Dort entscheidet Reaktionsfähigkeit darüber, ob jemand den Vorgang zu Ende bringt. Und dieser Effekt ist deutlich mehr wert als jede Positionsverbesserung in einer Trefferliste.
Unsere Reihenfolge bei bestehenden Seiten ist deshalb: erst messen, dann die zwei oder drei größten Blöcke suchen, dann gezielt eingreifen. Der Versuch, alles gleichzeitig zu verbessern, endet meistens in viel Aufwand mit wenig sichtbarem Ergebnis.
Mehr dazu, wie wir das in Projekten umsetzen, steht bei technische Umsetzung von Weblösungen.
Oliver Misch
Geschäftsführer der medienplus GmbH
Arbeitet seit über 15 Jahren an Websites, Technik und Sichtbarkeit und schreibt hier über das, was ihm im Alltag mit Kunden begegnet. Bei digital unit in Köln ist er der erste Kontakt für neue Projekte.