INP (Interaction to Next Paint)

Was ist INP?

Stell dir vor, du klickst auf ein Hamburger-Menü und es dauert eine halbe Sekunde, bis es aufgeht. In dieser halben Sekunde weißt du nicht: Hat die Seite den Klick registriert? Muss ich nochmal klicken? Ist meine Maus kaputt? Genau diese Wartezeit — zwischen Klick und sichtbarer Reaktion — misst INP.

INP gehört seit einer Weile offiziell zu den Core Web Vitals und hat dort den alten Wert FID (First Input Delay) abgelöst. FID war zu mild: Er hat nur die erste Interaktion gemessen und nur den Moment bis zur Verarbeitung, nicht bis zum sichtbaren Ergebnis. INP ist strenger und realistischer. Es schaut sich alle Interaktionen auf einer Seite an — Klicks, Taps, Tastatureingaben — und nimmt den schlechtesten Wert als Referenz.

Ein Beispiel: Du tippst im Kontaktformular deinen Namen ein, die Tastatur ruckelt nach jedem Buchstaben, weil im Hintergrund ein dickes Analytics-Skript jedes Eingabe-Event abfängt. INP: 480 Millisekunden. Spürbar lahm, auch wenn der Rest der Seite blitzschnell war.

Wie wird INP gemessen?

INP misst die Zeit zwischen dem Moment, in dem der Nutzer eine Eingabe auslöst, und dem nächsten sichtbaren Frame, in dem das Ergebnis angezeigt wird. Gemessen werden drei Phasen:

1. Input Delay — Wartezeit, bis der Browser das Event überhaupt verarbeiten kann (meistens blockiert durch laufendes JavaScript).
2. Processing Time — wie lange der Event Handler selbst braucht.
3. Presentation Delay — wie lange der Browser danach braucht, um den neuen Frame zu rendern.

Die Summe ist der INP-Wert. Google nutzt den 98. Perzentil-Wert aller Interaktionen auf einer Seite — also den zweitschlechtesten Klick, nicht den Durchschnitt. Damit lässt sich nicht durch "99 schnelle Klicks und einen zähen" schönrechnen.

Die 200-Millisekunden-Grenze ist bewusst gewählt: Darunter fühlt sich eine Interaktion für das menschliche Gehirn "sofort" an. Alles darüber wirkt verzögert.

Warum ist INP für deine Website wichtig?

Ein schlechter INP ist der Hauptgrund, warum sich moderne Websites trotz schnellem Laden "laggy" anfühlen. Nutzer erwarten, dass Klicks und Taps instant passieren. Wenn der Browser stattdessen 400 Millisekunden mit JavaScript beschäftigt ist, bevor er reagiert, entsteht der Eindruck einer kaputten App.

Besonders tückisch ist das Phänomen bei Frameworks wie React oder Next.js: Die Seite wird serverseitig gerendert und sieht sofort fertig aus — ist aber noch "tot", bis Hydration abgeschlossen ist. Hydration meint den Prozess, in dem der Browser das ausgelieferte HTML mit dem passenden JavaScript-Zustand verknüpft, damit Interaktionen überhaupt funktionieren. Klickt ein Nutzer auf einen Button, bevor die Hydration durch ist, wartet der Klick — oder geht verloren. Das drückt den INP ins Rote, ohne dass LCP oder CLS auffällig sind.

Für SEO zählt INP seit Kurzem direkt ins Ranking-Signal ein. Für Conversions noch wichtiger: Der Moment zwischen "Jetzt kaufen"-Klick und "Warenkorb öffnet sich" entscheidet, ob jemand den Kauf durchzieht oder zweifelnd innehält. Jede Millisekunde über 200 kostet Vertrauen.

Reales Beispiel: Ein Online-Shop mit Elementor, Page-Builder-Overhead und fünf zusätzlichen Tracking-Skripten. INP beim Filter-Klick: 680 Millisekunden. Nach Cleanup — Tracking konsolidiert, ungenutzte Widgets entfernt, JavaScript aufgeteilt in kleinere Chunks — lag INP bei 140 Millisekunden. Conversion Rate stieg um 8 Prozent, ohne eine Zeile am Design zu ändern.

Wie du INP verbesserst

Fast alle INP-Probleme kommen von zu viel oder zu schwerem JavaScript, das den Main-Thread blockiert. Die wichtigsten Hebel:

• JavaScript aufteilen. Statt eines 800-KB-Bundles besser mehrere kleine Chunks, die nur bei Bedarf geladen werden (Code Splitting).
• Long Tasks entschärfen. Alles, was länger als 50 Millisekunden am Main-Thread klebt, blockiert Interaktionen. Große Berechnungen aufteilen oder in Web Worker auslagern.
• Event Handler schlank halten. Kein schweres Parsing oder DOM-Manipulation direkt im Click-Handler. Lieber später per requestIdleCallback nachlegen.
• Third-Party-Skripte reduzieren. Jeder Tracker, jedes Chat-Widget, jedes A/B-Test-Tool frisst Main-Thread-Zeit. Weniger ist besser — oder zumindest asynchron laden.
• Minification und Tree Shaking. Ungenutzten Code aus Bundles werfen, Rest komprimieren.
• requestAnimationFrame für visuelle Updates, requestIdleCallback für Hintergrundarbeit, setTimeout 0 als Notlösung zum Aufbrechen langer Tasks.

Bei WordPress-Seiten lohnt sich ein Blick auf Plugin-Ballast: Jedes Plugin, das im Frontend JavaScript auslädt, ist ein Kandidat für den INP-Killer. Häufige Verdächtige sind WPML, schwere Slider-Plugins und veraltete Formular-Builder.