Interaction to Next Paint (INP)

Was INP wirklich misst

INP misst keine Ladezeit. Gemessen wird die Strecke zwischen dem Moment, in dem jemand klickt, tippt oder eine Taste drückt, und dem nächsten Frame, in dem der Browser die Folge dieser Aktion sichtbar auf den Bildschirm bringt. Drei Abschnitte stecken darin: die Wartezeit, bis der Event-Handler überhaupt starten darf (input delay), die Ausführung der Handler selbst (processing time), und schließlich Layout und Paint bis zum fertigen Frame (presentation delay). Scrollen und Hover zählen nicht mit, weil beides in modernen Browsern anders verarbeitet wird. Wer also einen Wert von 700 ms sieht, weiß noch nicht, ob der Main Thread blockiert war, ob der Handler selbst zu viel gerechnet hat oder ob das anschließende Rendering zu teuer war. Diese Zerlegung ist der eigentliche Einstieg in jede INP-Analyse.

Der ausgewiesene Wert ist bewusst pessimistisch aggregiert. Über einen Seitenbesuch nimmt der Browser nicht den Durchschnitt der Interaktionen, sondern praktisch die schlechteste. Darüber legt sich eine zweite Aggregation, denn was in CrUX und damit in der Google Search Console landet, ist das 75. Perzentil über alle gemessenen Besuche. Zwei Perzentilschichten übereinander, das ist der Grund, warum eine Seite auf dem eigenen Rechner tadellos wirkt und der Bericht trotzdem rot bleibt.

Die Schwellen sind seit Einführung unverändert: bis 200 ms gut, 200 bis 500 ms verbesserungswürdig, darüber schlecht. In den zwölf Monaten bis August 2026 gab es keine belastbare Google-Ankündigung, die daran etwas geändert hätte, weder an den Grenzwerten noch an der Gewichtung innerhalb der drei Kernmetriken der Nutzererfahrung. Wenn ein Audit behauptet, INP sei neu gewichtet worden, ist die einzig sinnvolle Reaktion die Frage nach der Quelle. Als Orientierung im Kopf hilft das Frame-Budget: bei 60 Hz steht alle 16 ms ein neuer Frame an. 200 ms sind also gut ein Dutzend verpasste Frames, und genau so fühlt sich das an.

Warum FID abgelöst wurde und was das ändert

First Input Delay maß ausschließlich den input delay der allerersten Interaktion auf einer Seite. Alles, was danach kam, war unsichtbar: die Ausführung des Handlers, das Rendering, jede weitere Interaktion in derselben Sitzung. Das war eine Metrik, die fast jeden durchwinkte, weil der erste Klick auf einer frisch geladenen Seite selten das Problem ist. Das Problem ist der dritte Filterklick, der vierte Karussellwechsel, das Öffnen der mobilen Navigation, wenn ein halbes Dutzend Skripte bereits um den Main Thread konkurriert.

Seit März 2024 ersetzt INP FID als Core Web Vital, und die Verschiebung ist inhaltlich größer, als der Wechsel eines Akronyms nahelegt. Sites, die unter FID bestanden und unter INP durchfallen, sind nicht langsamer geworden, es misst nur endlich jemand die richtige Sache. Operativ verschiebt sich damit auch die Arbeit: nicht mehr „was blockiert den Main Thread beim Laden«, sondern »was blockiert ihn über die gesamte Sitzung hinweg«. Das trifft vor allem lang laufende Interfaces, hydratisierte Komponenten und alles, was per Tag Manager nachgeladen wird. Ein guter Serverantwortzeitwert hilft hier übrigens kaum: INP ist ein Client-Problem, kein Hosting-Problem.

Feld, Labor und die Lücke dazwischen

Die technische Grundlage im Browser ist die Event Timing API, die jeder Interaktion eine interactionId gibt und die Teilzeiten ausweist. Für die Ursachensuche kommt die Long Animation Frames API dazu, die zeigt, welches Skript einen langen Frame verursacht hat. DebugBear hat diese LoAF-Daten im Oktober 2025 in seinen INP-Debugger integriert, zusammen mit synthetischer INP-Messung, CrUX-URL-Scanning und fünf neuen Testregionen. Ohne Attribution auf Skriptebene bleibt jede INP-Optimierung Raten.

Die wichtigste Unterscheidung im Reporting: Labor ist nicht Feld. Ein synthetischer Test simuliert eine Interaktionsfolge auf einem definierten Gerät, CrUX misst echte Nutzer mit echten Geräten und echter Netzqualität. Wie weit das auseinanderläuft, hat DebugBear 2025 an einem Demo-Set gezeigt: nur 4 von 22 Desktop-URLs erreichten einen synthetischen INP von 150 ms oder weniger, während 15 von 22 einen guten CrUX-INP unter 200 ms hatten. Das prominenteste Beispiel war Discord mit über 3 Sekunden Total Blocking Time und 81 ms CrUX-INP. Wer TBT als Stellvertretermetrik für INP verkauft, verkauft eine Näherung, die in beide Richtungen kräftig danebenliegen kann.

Zwei Werkzeugänderungen sind für Reporting-Setups relevant. PageSpeed Insights und die zugehörige API sind laut Googles Release Notes am 20. Oktober 2025 auf Lighthouse 13.0 umgestellt worden, das veraltete Feld ruleScore wurde entfernt, empfohlen wird ruleImpact. Wer INP-Werte per API in ein Dashboard zieht, sollte auf umbenannte oder entfernte Audit-Felder testen statt anzunehmen, dass alte Lighthouse-Bezeichner stabil bleiben. Und am 16. Dezember 2025 meldete web.dev, dass INP und LCP nach Safari 26.2 den Status Baseline Newly available erreicht haben. Die Messung ist damit nicht mehr auf Chrome beschränkt, CrUX selbst bleibt aber Chrome-basiert, echtes Cross-Browser-Bild gibt es weiterhin nur über eigenes RUM.

Praktischer Hinweis für Vergleiche über Märkte hinweg: CrUX liefert INP in einer Granularität von 25 ms, und die Länderunterschiede sind erheblich. DebugBear ermittelte 2025 einen typischen INP von rund 75 ms in Südkorea und etwa 100 ms in den USA, Deutschland und Japan. Gerätemix und Land verschieben den Wert also spürbar, bevor irgendjemand eine Zeile Code angefasst hat.

Was die Felddaten hergeben

Der Web Almanac 2025, basierend auf CrUX-Messungen aus Juni und Juli 2025, gibt die derzeit beste Bestandsaufnahme. Auf Mobilgeräten hatten 77 % der Seiten ein gutes INP, nach 74 % im Vorjahr, also drei Prozentpunkte Verbesserung. 21 % lagen im verbesserungswürdigen Bereich, 3 % waren schlecht. Auf dem Desktop waren es 97 %, womit sich eine Lücke von 20 Punkten zwischen mobil und Desktop auftut. Bei den Top-1000-Sites stieg der Anteil guter INP-Werte von 53 % auf 63 %, ein Sprung von zehn Punkten, was zeigt, wo die Optimierungsarbeit tatsächlich stattfindet.

Die interessantere Zahl steht daneben. Mobil bestanden 62 % LCP, 77 % INP und 81 % CLS, aber nur 48 % alle drei Metriken gleichzeitig. INP ist also nicht der größte Flaschenhals der Webpopulation, LCP bleibt der härtere Brocken. Wer sein Budget rein nach Schmerzgrad verteilt, sollte das wissen, bevor er ein Quartal in Interaktionslatenz investiert, während der Largest Contentful Paint auf Mobilgeräten bei drei Sekunden hängt. Umgekehrt: bei Interfaces mit vielen Interaktionen, also Filterseiten, Konfiguratoren, Suchen mit Facetten, dreht sich das Verhältnis um, und dort ist INP die Metrik, die den Nutzer wirklich verliert. Auch visuelle Sprünge im Layout hängen oft an denselben Skripten, die den Main Thread blockieren.

INP im SEO- und Netlinking-Betrieb

Klare Position: INP ist kein Ranking-Hebel, mit dem man Positionen kauft. Google hält daran fest, dass Core Web Vitals von den Ranking-Systemen genutzt werden, gute Werte in der Search Console oder in Drittanbieter-Tools aber keine prominente Platzierung garantieren. Relevanz, Qualität, Autorität und Links bleiben notwendig. Die Core Updates vom 11. bis 29. Dezember 2025, vom 27. März bis 8. April 2026 und vom 21. Mai bis 2. Juni 2026 kamen jeweils ohne INP-spezifische Hinweise. Die Volatilitätszahlen, die zum März-Update kursierten, etwa die von SE Ranking berichteten rund 79,5 % veränderter Top-3-URLs und 24,1 % der Top-10-Seiten, die aus den Top 100 fielen, beschreiben allgemeine Ranking-Bewegung und nicht einen INP-Effekt. Wer sie als Beleg für eine neue Gewichtung der Metrik verkauft, macht aus Korrelation eine Behauptung.

Wo INP im Netlinking trotzdem operativ zählt, ist die Bewertung von Hosts. Ein Medium, das nach einem Klick auf die Kategorienavigation eine Sekunde braucht, hat ein Leserproblem, und ein Artikel, den niemand zu Ende liest, transportiert auch keinen Kontext für den Link darin. Wir messen INP auf den französischen Redaktionsmedien, die wir im Eigenbetrieb führen, aus demselben Grund, aus dem wir Ladezeiten messen: weil die Qualität der Umgebung Teil dessen ist, was man beim Kauf einer Platzierung bekommt. Bei der Auswahl eines Hosts über ein Medienverzeichnis, das ohne Anmeldung einsehbar ist, sagt die Reaktionsfähigkeit der Seite mehr über die redaktionelle Pflege aus als jede Autoritätskennzahl. Und wenn Sie nachrechnen, was eine Platzierung konkret kostet, gehört die technische Verfassung des Mediums in dieselbe Rechnung wie Trafficvolumen und Themenpassung.

Was in Audits regelmäßig schiefgeht

Der häufigste Fehler ist, das Labor mit dem Feld zu verwechseln. Ein Team optimiert wochenlang gegen einen Lighthouse-Wert, der auf einem simulierten Gerät entsteht, und wundert sich, dass der CrUX-Wert 28 Tage später unbewegt bleibt. Das Feld hat immer recht, das Labor dient der Ursachensuche, nicht der Erfolgsmessung. Zweiter Klassiker: der Durchschnitt. Wer INP als Mittelwert reportet, glättet genau die Ausreißer weg, auf die die Metrik ausgelegt ist.

Dann die üblichen Verursacher, die aus eigener Audit-Erfahrung in fast jedem Fall auftauchen. Consent-Banner, die beim ersten Klick eine Skriptkaskade auslösen. Tag Manager mit einem Dutzend Custom-HTML-Tags, die auf denselben Event hören. Hydration von Komponenten, die zum Interaktionszeitpunkt noch nicht bereit sind, was den input delay direkt in die Höhe zieht. Und Tests auf einem aktuellen Entwicklerrechner, während der reale Traffic auf Mittelklasse-Android läuft, wo derselbe Handler ein Vielfaches an Zeit braucht.

Ein methodischer Fehler kommt dazu: nur die Startseite messen. INP entsteht dort, wo interagiert wird, also auf Listen- und Filterseiten, im Warenkorb, in der Suche. CrUX aggregiert auf URL-Ebene nur für ausreichend besuchte Seiten, alles andere landet im Origin-Wert und verschwindet in der Mischung. Ohne eigenes RUM mit Attribution nach Interaktionstyp, betroffenem Element, Gerät und Geografie bleibt die Analyse grob. Und der teuerste Fehler von allen: ein Quartal Interaktionslatenz zu optimieren auf einer Domain, deren eigentliches Problem zwölf verweisende Domains und dünne thematische Abdeckung sind. INP repariert kein Autoritätsdefizit, es verhindert nur, dass eine sonst funktionierende Seite ihre Nutzer beim dritten Klick verliert.