Die 200 Millisekunden, die Nutzer aus dem SaaS treiben
Eine SaaS-Oberfläche wirkt langsam, lange bevor es messbar ist. Interaction to Next Paint misst dieses Zögern und entscheidet über Ranking und Nutzergefühl.
Eine SaaS-Oberfläche wirkt langsam, lange bevor sie es messbar ist. Der Nutzer klickt. Für einen Wimpernschlag passiert nichts. Genau dieses Zögern misst Interaction to Next Paint. Der Wert entscheidet mit über das Google-Ranking und noch mehr darüber, ob eine Anwendung sich souverän anfühlt oder zäh.
Das Wichtigste in Kürze
- INP hat FID abgelöst. Seit März 2024 ist Interaction to Next Paint ein Core Web Vital. Es misst die Verzögerung über alle Interaktionen einer Sitzung, nicht nur den ersten Klick. Ziel: unter 200 Millisekunden.
- Der Hauptthread ist der Engpass. Schlechte INP-Werte entstehen fast immer, weil JavaScript den Main Thread blockiert. Die Oberfläche kann erst neu zeichnen, wenn die Arbeit fertig ist.
- SaaS trifft es härter als Content-Seiten. Interaktive Anwendungen leben von Klicks, Eingaben und Zustandswechseln. Jede dieser Interaktionen fließt in den INP-Wert ein.
Verwandt:Das Model Context Protocol unter der Linux Foundation / Grok 4.5 in Cursor: in der EU vorerst gesperrt
Warum FID nicht mehr reichte
First Input Delay maß nur die Verzögerung der ersten Interaktion auf einer Seite. Für klassische Webseiten war das ein brauchbarer Indikator. Für eine SaaS-Anwendung, in der Nutzer minutenlang klicken, filtern und tippen, greift es zu kurz. Der erste Klick sagt nichts darüber, wie sich die Anwendung nach zehn Minuten Arbeit anfühlt.
Interaction to Next Paint schließt diese Lücke. Es betrachtet praktisch alle Interaktionen einer Sitzung und meldet den schlechtesten repräsentativen Wert. Damit misst INP das, was Nutzer tatsächlich erleben: die Reaktionsfähigkeit über die gesamte Nutzungsdauer. Für interaktive Oberflächen ist das der ehrlichere Maßstab.
Wo die Millisekunden verloren gehen
In fast allen Fällen liegt die Ursache beim Main Thread. Der Browser verarbeitet Interaktionen, Rendering und JavaScript auf demselben Strang. Läuft dort ein langer Task, muss die Reaktion auf den Klick warten. Der Nutzer sieht das als Ruckeln oder als Verzögerung, bis sich etwas auf dem Bildschirm bewegt.
In der Praxis sind es drei Muster. Zu große JavaScript-Bundles, die beim Laden und bei jeder Interaktion Arbeit erzeugen. Teure Re-Renders, bei denen ein Klick eine ganze Komponentenhierarchie neu berechnet. Und synchrone Handler, die Netzwerk- oder Rechenarbeit erledigen, bevor sie die Oberfläche freigeben. Wer INP verbessern will, sucht hier.
Die wirksamsten Hebel
Der erste Hebel ist Aufteilen. Lange Tasks lassen sich in kleinere Stücke zerlegen, sodass der Browser zwischendurch auf Eingaben reagieren kann. Moderne Ansätze verschieben unkritische Arbeit hinter die eigentliche Reaktion, etwa mit einem gezielten yield an den Scheduler. Der Nutzer sieht sofort eine Rückmeldung, die Restarbeit läuft danach.
Der zweite Hebel ist weniger Code zur richtigen Zeit. Code-Splitting lädt nur, was der aktuelle Bildschirm braucht. Der dritte ist Rendering-Disziplin: unnötige Re-Renders vermeiden, teure Berechnungen memoisieren, große Listen virtualisieren. Kein einzelner Trick bringt den Durchbruch. Die Summe der Entscheidungen entscheidet, ob eine Interaktion unter 200 Millisekunden bleibt.
Messen im echten Betrieb
Ein Lab-Test im Entwickler-Browser täuscht. Er läuft auf schneller Hardware mit gutem Netz und trifft selten die Interaktionen, die im Alltag wehtun. Aussagekräftig sind Felddaten von echten Nutzern. Der Chrome UX Report liefert sie aggregiert, eine eigene Erfassung über die Web-Vitals-Bibliothek zeigt, welche Interaktionen konkret die schlechten Werte erzeugen.
Der pragmatische Weg: Felddaten erheben, die schlimmsten Interaktionen identifizieren und gezielt dort optimieren. Wer stattdessen blind an vermeintlich langsamen Stellen schraubt, verbrennt Zeit an Symptomen, die niemand spürt. INP ist am Ende kein SEO-Wert, den man abhakt. Es ist der Messwert dafür, ob sich die Software gut anfühlt.
Häufige Fragen
Was ist Interaction to Next Paint (INP)?
INP ist ein Core Web Vital von Google. Es misst, wie schnell eine Website oder Anwendung sichtbar auf Nutzerinteraktionen wie Klicks, Taps und Tastatureingaben reagiert. Bewertet wird die Verzögerung über die gesamte Sitzung, nicht nur die erste Interaktion. Ein guter Wert liegt unter 200 Millisekunden.
Wann hat INP den FID-Wert ersetzt?
Im März 2024 wurde Interaction to Next Paint offiziell zum Core Web Vital und löste First Input Delay ab. FID maß nur die erste Interaktion, INP betrachtet die Reaktionsfähigkeit über die gesamte Nutzung.
Welcher INP-Wert gilt als gut?
Google bewertet einen INP unter 200 Millisekunden als gut, 200 bis 500 Millisekunden als verbesserungswürdig und über 500 Millisekunden als schlecht. Der Wert bezieht sich auf das 75. Perzentil der Seitenaufrufe.
Warum sind SaaS-Anwendungen besonders betroffen?
Weil sie interaktiv sind. Jeder Klick, jede Eingabe und jeder Zustandswechsel fließt in den INP-Wert ein. Content-Seiten haben wenige Interaktionen, eine Anwendung hunderte pro Sitzung. Entsprechend härter wirkt sich ein blockierter Main Thread aus.
Wie misst man INP zuverlässig?
Über Felddaten echter Nutzer, nicht über Lab-Tests. Der Chrome UX Report liefert aggregierte Werte, eine eigene Erfassung mit der web-vitals-Bibliothek zeigt, welche konkreten Interaktionen die schlechten Werte verursachen.
Lesetipps der Redaktion
cloudmagazinDas Model Context Protocol unter der Linux FoundationcloudmagazinGrok 4.5 in Cursor: in der EU vorerst gesperrtcloudmagazinZum ersten Mal kann man einer KI beim Denken zusehenMehr aus dem MBF Media Netzwerk
MyBusinessFutureNeue KI-Modelle senken Folgefehler in der KreditakteDigital ChiefsWas Beratungen über Transformation verschweigenSecurityTodayEin signierter Treiber macht den Endpunktschutz blindBildquelle: KI-generiert (Juli 2026)
