Über Interaction to Next Paint
Was ist Interaction to Next Paint?
Interaction to Next Paint misst, wie lange eine Seite braucht, um sichtbar auf eine Interaktion zu reagieren – etwa auf ein Tippen, einen Klick oder einen Tastendruck. Die Messung reicht vom Zeitpunkt der Interaktion bis zu dem Moment, in dem der Bildschirm als Nächstes aktualisiert wird.
Erfasst wird dabei das Gefühl, dass eine Seite nicht reagiert: das Menü, das sich nicht öffnet, oder die Schaltfläche, die zweimal gedrückt wird, weil beim ersten Mal nichts passiert ist. Diese Verzögerung entsteht fast immer dadurch, dass der Hauptthread mit etwas anderem beschäftigt ist.
Im März 2024 wurde es zu einem Core Web Vital und ersetzte den First Input Delay. Die Änderung war relevant, weil die alte Metrik nur die Verzögerung maß, bevor die Verarbeitung der ersten Interaktion begann. Dadurch wurden Seiten begünstigt, die einmal prompt reagierten und anschließend deutlich langsamer wurden.
Was gilt als guter INP?
Google stuft 200 Millisekunden oder weniger als gut ein, 200 bis 500 Millisekunden als verbesserungsbedürftig und alles über 500 Millisekunden als schlecht – wiederum am 75. Perzentil der tatsächlichen Interaktionen.
Im Gegensatz zu LCP handelt es sich hierbei nicht um eine einzelne Messung pro Seitenaufruf. Ein Besucher interagiert während einer Sitzung viele Male mit der Seite, und INP berücksichtigt dabei annähernd den schlechtesten dieser Werte. Eine Seite wird daher anhand ihres langsamsten Moments und nicht anhand ihres typischen Verhaltens bewertet.
Dadurch ist INP von den drei Metriken am schwersten zu manipulieren. Eine Seite kann für einen Test so optimiert werden, dass sie schnell lädt; während einer gesamten Sitzung reaktionsfähig zu bleiben, hängt jedoch davon ab, wie sie entwickelt wurde.
Was normalerweise einen schlechten INP verursacht
INP-Probleme sind fast immer JavaScript-Probleme – genauer gesagt lange Aufgaben, die den Hauptthread blockieren, während der Besucher versucht, die Seite zu verwenden.
- Schwere Event-Handler, die ihre Aufgaben synchron ausführen, bevor sie die Kontrolle abgeben.
- Große Skripte, die noch geparst und ausgeführt werden, während die Seite bereits fertig aussieht.
- Drittanbieter-Tags – Chat-Widgets, Analytics, A/B-Tests und Werbeskripte –, die um denselben Thread konkurrieren.
- Aufwendige Layout-Arbeiten, die durch eine Interaktion ausgelöst werden, z. B. das erneute Rendern einer langen Liste.
- Frameworks, die mehr von der Seite erneut rendern, als sich durch die Interaktion tatsächlich geändert hat.
Drittanbieter verdienen besondere Aufmerksamkeit, denn sie sind der Teil der Seite, für den niemand verantwortlich ist, und der sich ändert, ohne dass jemand etwas ausrollt.
So können Sie das verbessern
- Teilen Sie lange Aufgaben auf und geben Sie den Browser zwischendurch frei, damit er dazwischen rendern kann.
- Zeigen Sie zuerst das sichtbare Ergebnis einer Interaktion an und erledigen Sie anschließend die verbleibenden Aufgaben.
- Verzögern Sie alles, was für die erste Interaktion nicht benötigt wird – insbesondere Skripte von Drittanbietern.
- Überprüfen Sie den Tag-Manager. Die meisten Websites enthalten Tags, die seit Jahren niemand mehr benötigt.
- Rendern Sie nicht ganze Bereiche neu, wenn sich nur ein Element geändert hat.
- Testen Sie auf einem Smartphone der Mittelklasse, auf dem der Thread deutlich leichter ausgelastet wird als auf einem Laptop.
Was dieses Tool prüft
Der INP-Test liest die Felddaten der Seite von Google aus – Messwerte, die von echten Besuchern in Chrome erfasst wurden – und zeigt, wo sie im Vergleich zu den oben genannten Schwellenwerten liegen.
INP kann nur gemessen werden, wenn jemand tatsächlich interagiert. Daher ist diese Metrik auf einer wenig besuchten Seite oder auf einer Seite, die Nutzer einfach nur lesen, am ehesten nicht verfügbar. Das ist kein Fehler, sondern bedeutet, dass es noch nichts zu berichten gibt.
Wie es weitergeht
Responsiveness ist ein Skriptproblem. Beginnen Sie daher mit dem, was auf der Seite ausgeführt wird. Prüfen Sie auf
JavaScript-Fehler, sehen Sie mit dem Tool
Seitenanfrage, wie viele separate Dateien geladen werden, und stellen Sie mit einem vollständigen
Website-Audit sicher, dass nichts grundsätzlich beschädigt ist.