INP mit einem KI-Agenten beheben: 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 Nutzerdaten kann Ihnen nicht sagen, welche Interaktion langsam ist, wer sie erlebt oder wann sie im Lebenszyklus der Seite auftritt. So beheben Sie INP, wenn Sie über Felddaten verfügen.

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 Nutzerinteraktionen reagiert: Klicks, Tippen, Tastendrücke. Es wählt die einzige schlechteste Interaktion aus der gesamten Sitzung aus. Das Schlüsselwort ist echt. Ein Nutzer klickt auf ein Filter-Dropdown auf Ihrer Produktseite, während ein Analytics-Skript eines Drittanbieters 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 Seitenaufbaus. 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 auslöst. Ein Agent ohne Felddaten ist dafür blind. Er optimiert TBT und erklärt den Sieg, während echte Nutzer 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 Nutzer interagierte. Während des Ladezustands (loading state) sind die üblichen Ursachen die Ausführung großer JavaScript-Bundles, die Initialisierung von Analytics-Skripten oder Framework-Hydratisierung. Im vollständigen Zustand (Seite vollständig geladen) sind Hintergrund-Timer, Drittanbieter-Skripte, die nach Updates suchen, oder Service-Worker-Aktivitäten die Ursache.

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

Presentation: Der Browser braucht zu lange, um nach Abschluss des Handlers zu zeichnen (paint). 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 Long Animation Frames (LoAF)-Zuordnung aus echten Nutzersitzungen. Das ermöglicht es dem Agenten, INP tatsächlich zu beheben, anstatt zu raten.

LoAF benennt 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 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 sagt, dass die Total Blocking Time 450ms beträgt, und es Ihnen überlässt herauszufinden, welches Ihrer 30 Skripte dies verursacht hat.

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

Laden vs. geladen: zwei verschiedene Probleme

Ob die Interaktion während des loading- oder complete-Zustands stattfand, ändert die Lösung grundlegend.

Wenn INP nur während des Ladezustands schlecht ist, liegt das Problem in der Ladereihenfolge der Skripte. Es wird zu viel JavaScript ausgeführt, bevor die Seite interaktiv ist. Die Lösung liegt im script deferral: Stellen Sie nicht-kritische Skripte zurück, nutzen Sie Code-Splitting, reduzieren Sie Parser-blockierendes JavaScript.

Wenn INP im vollständigen Zustand schlecht ist, haben Sie ein JavaScript-Laufzeitproblem. Etwas läuft im Hintergrund auf einer vollständig geladenen Seite. Drittanbieter-Skripte suchen nach Updates, Analytics senden Beacons oder Ihr eigener Code führt teure Operationen über einen Timer aus.

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 Schlussfolgern für INP

INP beträgt 350ms auf der Checkout-Seite. Die Phasenaufschlüsselung aus den 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 von Presentation bewirkt mehr als die Optimierung von Input Delay oder Processing zusammen.

Ohne die Prozentsätze jagt ein Agent dem Input Delay hinterher, weil 70ms irgendeinen Schwellenwert überschreiten. Zeigen Sie ihm die Aufschlüsselung, und er zielt direkt auf die 57% ab. Das Ergebnis: Eine Lösung, die INP unter 200ms senkt, im Gegensatz zu drei verstreuten Fixes, die kaum etwas bewegen.

Typische Lösungen nach Phase

Input Delay während des Ladens: Stellen Sie nicht-kritische Skripte zurück (defer). Entfernen Sie ungenutztes JavaScript. Nutzen Sie Code-Splitting, damit nur der Code für die aktuelle Seite geladen wird.

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

Processing: Nutzen Sie ein yield an den Main Thread mit scheduler.yield() oder setTimeout(0). Teilen Sie lange Event-Handler in kleinere Tasks auf. Vermeiden Sie erzwungene Layouts (forced layouts - das 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 (below the fold) (wird in allen gängigen Browsern seit September 2025 unterstützt). Reduzieren Sie die Anzahl der DOM-Knoten, die von den Änderungen des Handlers betroffen sind. Nutzen 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.

Beobachten Sie auch die Aufteilung der Ladezustände (load state split). Wenn Ihr Fix auf INP im Ladezustand abzielte, bestätigen Sie, dass sich die Zahlen im Ladezustand verbessert haben, ohne dass sich die Zahlen im vollständigen Zustand (complete state) verschlechtert haben. Felddaten geben Ihnen diese Granularität. Lab-Daten tun das nicht.