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

Interaction to Next Paint ist der schwierigste Core Web Vital für KI-Agenten. Er kann nicht simuliert werden. Lighthouse hat keinen INP-Score. Ein KI-Agent ohne echte Benutzerdaten kann Ihnen nicht sagen, welche Interaktion langsam ist, wer sie erlebt oder wann im Lebenszyklus der Seite sie auftritt. So beheben Sie INP, wenn Sie Felddaten haben.

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

Warum INP für KI-Agenten anders ist

INP misst, wie schnell Ihre Website auf Benutzerinteraktionen reagiert: Klicks, Tippen, Tastendrücke. Es wird die einzige schlechteste Interaktion aus der gesamten Sitzung ausgewählt. Das Schlüsselwort ist echt. Ein Benutzer klickt auf ein Filter-Dropdown auf Ihrer Produktseite, während ein Analytics-Skript von Drittanbietern ausgeführt wird. Diese Verzögerung von 380ms wird zum INP für diese Sitzung.

Kein Lab-Tool kann dies reproduzieren. Lighthouse verwendet die Total Blocking Time als Proxy, aber TBT misst die Blockierung des Main Threads während des Seitenladevorgangs. INP misst die Reaktionszeit auf Interaktionen, die zu unvorhersehbaren Momenten während der gesamten Sitzung auftreten. Eine Seite mit null TBT kann immer noch einen schrecklichen INP haben, wenn ein Hintergrund-Timer im falschen Moment ausgelöst wird. Ein Agent ohne Felddaten ist dafür blind. Er optimiert TBT und erklärt den Sieg, während echte Benutzer 400ms darauf warten, dass ihre Klicks registriert werden.

Drei Phasen, drei verschiedene Lösungen

INP unterteilt sich in drei Phasen. Jede erfordert eine andere Lösung.

Input Delay: Der Main Thread war beschäftigt, als der Benutzer interagierte. Während des Ladezustands sind die üblichen Ursachen große ausführende JavaScript-Bundles, die Initialisierung von Analytics-Skripten oder Framework-Hydratation. Im vollständigen Zustand (Seite vollständig geladen) sind Hintergrund-Timer, Skripte von Drittanbietern, die nach Updates suchen, oder Service-Worker-Aktivitäten die Schuldigen.

Processing: Der Event-Handler selbst ist zu langsam. Layout Thrashing (DOM lesen, DOM schreiben, DOM in einer Schleife lesen), synchrone DOM-Abfragen innerhalb des Handlers, teure Re-Renders oder einfach zu viel Arbeit in einem einzigen Task ohne Yielding.

Presentation: Der Browser braucht zu lange zum Rendern, nachdem der Handler beendet ist. Große DOM-Bäume (Tausende von Knoten, die eine Stil-Neuberechnung benötigen), fehlendes CSS Containment oder teure Paint-Operationen, die durch die DOM-Änderungen des Handlers ausgelöst werden.

Welches Skript blockiert Ihre Seite

CoreDash erfasst die Zuordnung von Long Animation Frames (LoAF) aus echten Benutzersitzungen. Dadurch kann der Agent INP tatsächlich beheben, anstatt nur zu raten.

LoAF benennt genau die 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 blockierte den Main Thread für 280ms während der Interaktion auf dem Filter der Checkout-Seite.

Anstelle von "Ihre Seite ist langsam" erhalten Sie "diese Datei, diese Funktion, diese Dauer". Vergleichen Sie das mit Lighthouse, das Ihnen mitteilt, dass die Total Blocking Time 450ms beträgt, und Sie selbst herausfinden lässt, welches Ihrer 30 Skripte dies verursacht hat.

Der Agent öffnet die Datei, liest den Code und schreibt den Fix: zurückstellen, in kleinere Tasks aufteilen oder entfernen, wenn es niemand braucht.

Laden vs. geladen: zwei verschiedene Probleme

Ob die Interaktion im loading- oder complete-Zustand stattfand, ändert die Lösung grundlegend.

Wenn INP nur im Ladezustand schlecht ist, liegt das Problem in der Ladereihenfolge der Skripte. Zu viel JavaScript wird ausgeführt, bevor die Seite interaktiv ist. Die Lösung liegt in der Zurückstellung von Skripten: Nicht kritische Skripte zurückstellen, Code-Splitting, Parser-blockierendes JavaScript reduzieren.

Wenn der INP im vollständigen Zustand schlecht ist, haben Sie ein JavaScript-Laufzeitproblem. Etwas läuft im Hintergrund auf einer vollständig geladenen Seite. Skripte von Drittanbietern, die nach Updates suchen, Analytics, das Beacons sendet, oder Ihr eigener Code, der teure Operationen mit einem Timer ausführt.

CoreDash verfolgt den Seitenladezustand für jede INP-Messung. CWV Superpowers nutzt dies, um die Hälfte der Ursachen auszuschließen, bevor Skripte überhaupt betrachtet werden.

Proportionales Denken für INP

INP beträgt auf der Checkout-Seite 350ms. Die Phasenaufschlüsselung aus Felddaten:

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

Presentation ist der Engpass. 200ms klingen isoliert betrachtet nicht alarmierend. Aber es sind 57% des Gesamtwerts. Die Behebung der Presentation bringt mehr als die Optimierung von Input Delay oder Processing zusammen.

Ohne die Prozentsätze jagt ein Agent dem Input Delay nach, weil 70ms einen bestimmten Schwellenwert überschreiten. Zeigen Sie ihm die Aufschlüsselung und er geht direkt auf die 57% zu. Das Ergebnis: Ein Fix, der den INP unter 200ms senkt, im Vergleich zu drei verstreuten Fixes, die kaum etwas bewirken.

Typische Lösungen nach Phase

Input Delay während des Ladens: Nicht kritische Skripte zurückstellen. Ungenutztes JavaScript entfernen. Code-Splitting durchführen, damit nur der Code für die aktuelle Seite geladen wird.

Input Delay im vollständigen Zustand: Überprüfen Sie Skripte von Drittanbietern, die nach dem Laden der Seite ausgeführt werden. Verwenden Sie die LoAF-Daten aus CoreDash, um das fehlerhafte Skript zu finden. Verschieben Sie es mit requestIdleCallback in die Leerlaufzeit.

Processing: Yielding an den Main Thread mit scheduler.yield() oder setTimeout(0). Teilen Sie lange Event-Handler in kleinere Tasks auf. Vermeiden Sie Forced Layouts (Lesen von Layout-Eigenschaften unmittelbar nach dem Schreiben ins DOM).

Presentation: Verwenden Sie content-visibility: auto für große DOM-Bereiche im nicht sichtbaren Bereich (wird seit September 2025 von allen gängigen Browsern unterstützt). Reduzieren Sie die Anzahl der DOM-Knoten, die von den Änderungen des Handlers betroffen sind. Verwenden Sie CSS Containment, um den Repaint auf einen kleineren Bereich zu isolieren.

Überprüfung mit Felddaten

INP-Verbesserungen zeigen sich in CoreDash innerhalb von ein oder zwei Tagen bei echtem Traffic. Fragen Sie dieselbe Seite und dasselbe Gerätesegment ab. Der p75-Wert sollte sinken und die Phasenverteilung sollte sich verschieben.

Beachten Sie auch die Aufteilung nach Ladezustand. Wenn Ihr Fix auf den INP im Ladezustand abzielte, bestätigen Sie, dass sich die Zahlen im Ladezustand verbessert haben, ohne dass sich die Zahlen im vollständigen Zustand verschlechtert haben. Felddaten bieten Ihnen diese Granularität. Lab-Daten nicht.