INP mit einem KI-Agenten beheben: Die Metrik, die Lab-Tools nicht messen können

Interaction to Next Paint ist für KI-Agenten der schwierigste Core Web Vital. Er lässt sich nicht simulieren. Lighthouse liefert keinen INP-Wert. Ohne echte Nutzerdaten kann dir ein KI-Agent nicht sagen, welche Interaktion langsam ist, wer sie erlebt oder wann im Lebenszyklus der Seite sie auftritt. So behebst du INP, wenn du field data hast.

Zuletzt geprüft von Arjen Karel im März 2026

Warum INP für KI-Agenten anders ist

INP misst, wie schnell deine Seite auf Nutzerinteraktionen reagiert: Klicks, Taps, Tastendrücke. Er greift sich die schlechteste Interaktion der gesamten Session heraus. Das entscheidende Wort ist echt. Ein Nutzer klickt auf deiner Produktseite auf ein Filter-Dropdown, während ein Drittanbieter-Analytics-Skript läuft. Diese Verzögerung von 380 ms wird zum INP dieser Session.

Kein Lab-Tool kann das reproduzieren. Lighthouse nutzt Total Blocking Time als Proxy, aber TBT misst, wie lange der Main Thread beim Laden der Seite blockiert ist. INP misst die Reaktionszeit auf Interaktionen, die zu unvorhersehbaren Zeitpunkten während der Session auftreten. Eine Seite mit null TBT kann trotzdem einen katastrophalen INP haben, wenn ein Hintergrund-Timer im falschen Moment feuert. Ein Agent ohne field data ist dafür blind. Er optimiert TBT und meldet Erfolg, während echte Nutzer 400 ms darauf warten, dass ihr Klick registriert wird.

Drei Phasen, drei verschiedene Fixes

INP teilt sich in drei Phasen auf. Jede erfordert einen anderen Fix.

Input Delay: Der Main Thread war beschäftigt, als der Nutzer interagierte. Im loading-Status sind die typischen Ursachen: große JavaScript-Bundles, die ausgeführt werden, initialisierende Analytics-Skripte oder die Framework-Hydration. Im complete-Status (Seite vollständig geladen) sind Hintergrund-Timer, Drittanbieter-Skripte, die nach Updates pollen, oder Service-Worker-Aktivitäten schuld.

Processing: Der Event-Handler selbst ist zu langsam. Layout Thrashing (DOM lesen, DOM schreiben, DOM lesen in einer Schleife), synchrone DOM-Abfragen im Handler, teure Re-Renders oder schlicht zu viel Arbeit in einem einzelnen Task ohne yielding.

Presentation: Der Browser braucht nach Abschluss des Handlers zu lange für den Paint. Große DOM-Bäume (tausende Nodes, deren Styles neu berechnet werden müssen), fehlendes CSS Containment oder aufwendige Paint-Operationen, die durch DOM-Änderungen des Handlers ausgelöst werden.

Welches Skript deine Seite blockiert

CoreDash erfasst die Long-Animation-Frames-Attribution (LoAF) aus echten Nutzer-Sessions. Damit kann der Agent den INP gezielt beheben, statt nur zu raten.

LoAF nennt die genaue JavaScript-Datei, die Funktion und die Dauer. Der Agent rät nicht, welches Skript den Main Thread blockiert. CoreDash sagt es ihm: gtm-container.js hat den Main Thread während der Interaktion am Filter der Checkout-Seite für 280 ms blockiert.

Statt „Deine Seite ist langsam“ erfährst du: „Diese Datei, diese Funktion, diese Dauer.“ Vergleiche das mit Lighthouse: Es meldet 450 ms Total Blocking Time und überlässt es dir, herauszufinden, welches deiner 30 Skripte die Ursache war.

Der Agent öffnet die Datei, liest den Code und schreibt den Fix: verzögert laden, in kleinere Tasks aufteilen oder rauswerfen, wenn es niemand braucht.

Loading vs. loaded: zwei verschiedene Probleme

Ob die Interaktion während des Status loading oder complete stattfand, ändert den Fix komplett.

Ist der INP nur im loading-Status schlecht, liegt das Problem bei der Ladereihenfolge der Skripte. Zu viel JavaScript wird ausgeführt, bevor die Seite interaktiv ist. Der Fix liegt im verzögerten Laden von Skripten: unkritische Skripte verzögern, Code-Splitting einsetzen, parser-blockierendes JavaScript reduzieren.

Ist der INP im complete-Status schlecht, hast du ein Problem mit Runtime-JavaScript. Auf einer vollständig geladenen Seite läuft etwas im Hintergrund: Drittanbieter-Skripte, die nach Updates pollen, Analytics-Tools, die Beacons senden, oder eigener Code, der aufwendige Operationen per Timer ausführt.

CoreDash erfasst den Ladestatus der Seite für jede INP-Messung. CWV Superpowers schließt damit die Hälfte der Ursachen aus, bevor du überhaupt auf die Skripte schaust.

Proportionales Denken für den INP

Der INP auf der Checkout-Seite liegt bei 350 ms. Die Phasenaufteilung aus den field data:

• Input Delay: 70 ms (20 %)
• Processing: 80 ms (23 %)
• Presentation: 200 ms (57 %)

Presentation ist der Engpass. Isoliert betrachtet klingen 200 ms nicht dramatisch. Aber es sind 57 % des Gesamtwerts. Presentation zu beheben bringt deutlich mehr, als Input Delay und Processing zusammen zu optimieren.

Ohne die Prozentangaben jagt ein Agent dem Input Delay hinterher, weil 70 ms irgendeinen Schwellenwert überschreiten. Zeigst du ihm die Aufteilung, geht er direkt die 57 % an. Das Ergebnis: ein einzelner Fix, der den INP unter 200 ms drückt – statt drei verstreuter Maßnahmen, die kaum etwas bewirken.

Typische Fixes nach Phase

Input Delay während des Ladens: Lade unkritische Skripte verzögert. Entferne ungenutztes JavaScript. Nutze Code-Splitting, damit nur der Code für die aktuelle Seite lädt.

Input Delay im complete-Status: Überprüfe Drittanbieter-Skripte, die nach dem Laden der Seite laufen. Finde das verantwortliche Skript über die LoAF-Daten von CoreDash. Verschiebe es mit requestIdleCallback in die Idle-Zeit.

Processing: Yield an den Main Thread mit scheduler.yield() oder setTimeout(0). Teile lange Event-Handler in kleinere Tasks auf. Vermeide Forced Layouts (Layout-Eigenschaften direkt nach dem Schreiben in das DOM abfragen).

Presentation: Nutze content-visibility: auto für große DOM-Bereiche below the fold (seit September 2025 in allen gängigen Browsern unterstützt). Reduziere die Zahl der DOM-Nodes, die von den Änderungen des Handlers betroffen sind. Nutze CSS Containment, um den Repaint auf einen kleineren Bereich zu begrenzen.

Mit field data verifizieren

INP-Verbesserungen zeigen sich in CoreDash nach ein bis zwei Tagen mit echtem Traffic. Frage dasselbe Seiten- und Gerätesegment ab. Der p75-Wert sollte sinken und die Phasenverteilung sich verschieben.

Behalte auch die Aufteilung nach Ladestatus im Auge. Wenn dein Fix auf den INP im loading-Status abzielte: Prüfe, ob sich die Werte dort verbessert haben, ohne dass sich die Zahlen im complete-Status verschlechtern. Field data liefert dir diese Granularität. Lab data nicht.