Finde und behebe Probleme mit Interaction to Next Paint (INP): Eine Schritt-für-Schritt-Anleitung
Lerne, wie du Interaction to Next Paint-Probleme mit RUM-Daten, Chrome DevTools und der LoAF-API identifizierst und behebst.
Finde und behebe Probleme mit dem Interaction to Next Paint (INP)
Diese Seite ist Teil unserer Interaction to Next Paint (INP)-Serie. Der INP misst die Reaktionsfähigkeit deiner Website. Er trackt die Verzögerung zwischen einer Nutzerinteraktion und dem nächsten visuellen Update. Ein guter INP-Wert liegt unter 200 Millisekunden. Werte über 500 Millisekunden gelten als schlecht. Wenn der INP neu für dich ist, starte mit der INP-Übersichtsseite für einen kompletten Überblick.
Laut dem Web Almanac 2025 fallen 23 % der mobilen Origins immer noch beim INP durch. Wenn deine Seite dazugehört, ist dies der Prozess: Bestätige das Problem in der Search Console. Diagnostiziere die Ursachen mit RUM-Daten (Real User Monitoring). Repliziere sie lokal. Wende gezielte Fixes auf jede INP-Phase an.
INP-TIPP: Meistens ist der INP viel schlechter, wenn ein Nutzer während der Startphase des Seitenladevorgangs mit der Seite interagiert. Deshalb ist es beim Debuggen des INP sinnvoll, alle Interaktionen und den Ladestatus der Seite zu loggen!
Table of Contents!
Schritt 1: Prüfe den INP in der Search Console
Im ersten Schritt bestätigst du, dass du tatsächlich ein INP-Problem hast. Bevor du Code änderst, verifiziere das Problem in der Google Search Console. So arbeitest du mit echten field data statt mit Annahmen.
Logge dich in deine Google Search Console ein. Klicke im linken Menü auf Core Web Vitals und wähle Mobile oder Desktop (Tipp: Meistens treten INP-Probleme zuerst auf mobilen Geräten auf, starte also mit Mobile).
Hier siehst du eine Übersicht aller aktuellen Core Web Vitals-Probleme auf deiner Seite. Wenn eines dieser Probleme den INP betrifft, hast du das Problem bestätigt.
Schritt 2: Identifiziere Interaction to Next Paint-Probleme
Die Google Search Console liefert dir außer URL-Gruppen keine Informationen, um die Ursachen für Probleme mit dem Interaction to Next Paint zu finden. Deshalb gehen Entwickler meistens blind vor. Sie entfernen ungenutztes JavaScript (immer eine gute Idee) und brechen den main thread auf (ebenfalls eine gute Idee). Das behebt den INP aber fast nie vollständig.
Deshalb müssen wir bei der Verbesserung des INP genau wissen, was passiert. Wir brauchen Antworten auf vier kritische Fragen:
Welche Elemente verursachen bei Interaktion einen schlechten INP-Wert? Meistens wird ein schlechter INP-Wert nicht durch ein einziges Element verursacht, sondern durch eine Kombination von Problemen. Wir müssen sie nacheinander angehen. Beginne mit den schlimmsten und arbeite dich vor.
Wann passieren diese Interaktionen? Passieren sie während der Startphase der Ladezeit oder selbst dann, wenn die Hauptseite vollständig geladen ist?
Wo passieren diese Interaktionen? Passieren sie auf jeder Seite oder nur auf ausgewählten Seiten?
Wie können wir diese Interaktionen replizieren? Du hast vielleicht schon gemerkt, dass es schwer ist, INP-Probleme zu replizieren. Deshalb müssen wir gute Voraussetzungen schaffen, indem wir die Geräteeigenschaften mit einem schlechten INP-Wert nachahmen.
Richte RUM-Tracking ein
Um all diese Fragen zu beantworten, müssen wir echte Nutzer tracken und alle Probleme loggen, die beim Interaction to Next Paint auftreten können. Es gibt mehrere Wege, RUM-Tracking zu aktivieren. Der erste ist die Nutzung der Web Vitals-Bibliothek. Sende die Ergebnisse an dein eigenes Analytics-Backend. Der Vorteil dieser Methode: Sie ist günstig und flexibel. Der Nachteil: Sie bedeutet oft viel zusätzliche Arbeit.
Eine gute Alternative zum Senden der Core Web Vitals-Daten an dein eigenes Backend ist eines der vielen RUM-Tools auf dem Markt. Wir haben CoreDash genau für diese Anwendungsfälle entwickelt. CoreDash ist ein günstiges, schnelles und effektives RUM-Tool, das seinen Zweck erfüllt. Es gibt natürlich viele andere RUM-Lösungen, die den Job ebenfalls erledigen (allerdings zu einem höheren Preis).
Finde langsame Interaktionen pro Element, die einen hohen INP verursachen
Finde zuerst die langsamsten Interaktionen, die die schlechtesten INP-Werte verursachen. Liste deine Seiten in CoreDash nach „INP metric by Elements“ auf. So erhältst du deine langsamsten Interaktionen. Klicke auf die erste Zeile, um deine Metriken nach diesen Interaktionen zu filtern.
Finde heraus, wann schlechte INP-Interaktionen auftreten
Sortiere als Nächstes die gefilterten URLs nach Load State. Das gibt dir mehr Einblick in die Ursache des INP. In diesem Fall tritt der hohe INP auf, wenn der DOM-Content geladen ist. Das bedeutet, Skripte wurden geparst, aber asynchrone Skripte und die Unterressourcen der Seite sind noch nicht geladen. In diesem Fall wird der INP durch frühe Klicks verursacht, wenn die Ladezeit der Seite noch nicht ganz abgeschlossen ist.
Klicke weiter auf den Load State mit dem höchsten Impact, um einen weiteren Filter zu erstellen.
Finde URLs, die für hohe INP-Werte verantwortlich sind
Wenn wir nach den Elementen mit der langsamsten Interaktion und dem richtigen Load State gefiltert haben, schauen wir uns zuletzt die URLs mit dem schlechtesten INP an. In diesem Fall passiert das eindeutig auf einer bestimmten Gruppe von Seiten.
Finde Geräteeigenschaften
Nachdem wir langsame Interaktionen, den Load State und URLs identifiziert haben, die einen hohen Interaction to Next Paint verursachen, schauen wir uns an, welche Arten von Besuchern die schlechtesten INP-Werte verursachen. Wir betrachten Device Memory, Bandwidth, Screen Size und andere Hardware-Eigenschaften. Sobald wir diese Eigenschaften identifiziert haben, können wir das Problem replizieren und loggen.
Nutze die Long Animation Frames (LoAF) API für die INP-Diagnose
Die Long Animation Frames API (LoAF) zeigt dir genau, welche Skripte und Funktionen langsame Interaktionen verursachen. Im Gegensatz zur älteren Long Tasks API liefert LoAF Skript-URLs, Funktionsnamen und Timing-Breakdowns pro Frame. Sie ist besonders nützlich in Kombination mit RUM-Daten aus einem Tool wie CoreDash.
Dieser Observer sammelt LoAF-Einträge für Frames, die länger als 50 ms sind. Er erfasst Skriptzuordnung, Dauer und Blockierzeit:
// Beobachte Long Animation Frames für die INP-Zuordnung
const observer = new PerformanceObserver((list) => {
for (const entry of list.getEntries()) {
// Logge nur Frames, die länger als 50 ms sind
if (entry.duration > 50) {
console.log('Long Animation Frame:', {
duration: entry.duration,
blockingDuration: entry.blockingDuration,
renderStart: entry.renderStart,
styleAndLayoutStart: entry.styleAndLayoutStart,
scripts: entry.scripts.map(script => ({
sourceURL: script.sourceURL,
sourceFunctionName: script.sourceFunctionName,
invokerType: script.invokerType,
invoker: script.invoker,
duration: script.duration
}))
});
}
}
});
observer.observe({ type: 'long-animation-frame', buffered: true }); Die LoAF API zeigt, welche Skripte zu jeder INP-Phase beitragen. Das scripts-Array nennt dir die genaue Quelldatei und den Funktionsnamen. renderStart und styleAndLayoutStart helfen dir, die Processing Time vom Presentation Delay zu trennen. LoAF gibt es aktuell nur in Chromium (Chrome 123+). Für das Debugging in Firefox und Safari musst du dich auf den Trace im Performance-Panel und RUM-Daten verlassen. Mehr darüber, wie sich async vs defer JavaScript auf diese Timings auswirkt, findest du in unserem speziellen Guide.
Schritt 3: Repliziere und debugge Interaktionen, die einen hohen INP-Wert verursachen
Mit diesen Daten können wir anfangen, die Ursachen zu beheben.
Schaffe gute Voraussetzungen: Repliziere die Bedingungen des schlechten INP
Als Nächstes sollten wir versuchen, den schlechten INP nachzustellen. Wir tun dies, indem wir die Umstände nachahmen, unter denen der INP schlecht ausfällt.
Nutze das Chrome Performance-Panel: Öffne die Chrome-Entwicklertools (Strg+Umschalt+I) und wähle das Performance-Panel. In der oberen Leiste kannst du das CPU Throttle auswählen (drossele auf 4x slowdown, um ein normales Mobilgerät zu emulieren). Wähle das Network Throttle (wähle das fast 3G-Preset für ein durchschnittliches Mobilgerät). Setze die Hardware Concurrency auf 4 oder 8, um ebenfalls ein durchschnittliches Mobilgerät zu imitieren.
Um Chrome mit weniger Arbeitsspeicher zu laden, starte Chrome in einem Docker-Container und weise ihm weniger RAM zu. Meistens reicht es aber schon, die Netzwerk- und CPU-Einstellungen zu drosseln.
Lade die Seite neu, interagiere und prüfe den INP mit dem Core Web Vitals Visualizer
Simuliere nun die Bedingungen. Bestätige, dass die INP-Werte mit den Berichten deiner RUM-Daten übereinstimmen.
Lade die Seite neu und klicke zur richtigen Zeit auf das richtige Element
Debugge den INP mit einem Performance-Trace
Auf diesen Moment hast du dich in den vorherigen Schritten vorbereitet. Es ist an der Zeit, herauszufinden, warum eine bestimmte Interaktion den schlechten Interaction to Next Paint-Wert verursacht.
Öffne die Chrome Developer Console (Strg+Umschalt+I) und wechsle in das Performance-Panel. Klicke diesmal auf das Icon mit dem runden Pfeil, um die Seite neu zu laden und die Aufzeichnung zu starten (oder nutze den Shortcut Strg+Umschalt+E). Während die Aufzeichnung läuft, interagiere mit dem Element, das den schlechten INP verursacht. Stoppe die Aufzeichnung nach einigen Sekunden und untersuche die Timeline. Suche nach dem Interaktions-Event im „Interactions“-Track. Inspiziere dann die entsprechenden Tasks im „Main“-Track. So siehst du genau, welcher Code während jeder Phase ausgeführt wird.
Den Performance-Trace lesen
Im Chrome Performance-Panel erscheint die Interaktion als farbiger Balken im „Interactions“-Track. Klicke darauf, um die gesamte INP-Dauer und ihre Aufschlüsselung zu sehen. Darunter, im „Main“-Track, siehst du die einzelnen Tasks, die während der Interaktion liefen. Achte auf:
- Tasks vor dem Event-Handler: Diese tragen zum Input Delay bei.
- Der Event-Handler selbst: Das ist die Processing Time.
- Rendering-Arbeit nach Abschluss des Handlers: Das ist das Presentation Delay.
Vergleiche diese Ergebnisse mit deinen LoAF-Daten. Bestätige so, dass die im Trace identifizierten Skripte mit den Zuordnungsdaten deines RUM-Tools übereinstimmen. Dies ist auch ein guter Zeitpunkt, um zu prüfen, ob JavaScript Scroll Handlers zu dem Problem beitragen.
Schritt 4: Behebe INP-Probleme
Du weißt, welche Interaktion langsam ist und warum. Es ist Zeit, das zu beheben. Der Interaction to Next Paint lässt sich in drei Phasen unterteilen: Input Delay, Processing Time und Presentation Delay.
Jede Phase erfordert einen anderen Ansatz. Hier ist eine Zusammenfassung. Folge den Links für vollständige Optimierungs-Guides.
Minimiere das Input Delay:
Das Input Delay ist die Zeit zwischen der Interaktion mit der Seite und dem Start des Event-Callbacks. Ein gewisses Input Delay ist unvermeidbar (Browser brauchen Zeit, um Callbacks zu planen), aber du kannst es minimieren:
- Vermeide long tasks. Jedes Mal, wenn ein Task läuft, blockiert er den main thread und lässt die Event-Callbacks warten. Das ist besonders bei der Optimierung von frühen Klicks wichtig (da die meisten Skripte zu dieser Zeit ausgeführt werden). Strategien zur Reduzierung von blockierendem JavaScript findest du in unserem Guide zu async vs defer JavaScript.
- Sei vorsichtig beim Erstellen neuer Tasks. Zum Beispiel bei wiederkehrenden Tasks via
setTimeout()oder Tasks, die wahrscheinlich vor dem INP-Event auftreten, wie Callbacks beimmouseover-Event. - Miss und bewerte frühe Interaktionen. Wenn ein interaktives Element früh angezeigt wird (zum Beispiel eine Website-Suche) und von JavaScript gesteuert wird, das später lädt, löst eine Interaktion mit dem Element kein sofortiges Layout-Update aus. Priorisiere entweder die Funktionalität oder verstecke/deaktiviere das Element, bevor es richtig funktioniert.
- Nutze Web Worker, um JavaScript abseits des main threads auszuführen. Web Worker ermöglichen es, Skripte außerhalb des main threads auszuführen. Das verhindert, dass der main thread blockiert und Probleme mit dem INP Input Delay verursacht.
- Lade unwichtigere Third-Party-Skripte in der Browser Idle Time. Einige Skripte sind wichtiger als andere. Es ist sinnvoll, diese Skripte zu priorisieren und weniger wichtige Skripte (wie ein Chat-Skript) während der Browser Idle Time zu laden. Siehe unseren Guide über 14 Methoden, um JavaScript zu verzögern für praktische Techniken.
Minimiere die Processing Time
- Entferne nicht benötigten Code. Nicht benötigter Code ist entweder alter Code, der noch läuft, oder neuer Code, der auf dieser spezifischen Seite nicht gebraucht wird, aber trotzdem CPU-Zeit verbraucht. Dies ist mit Abstand der einfachste Weg, den INP sofort zu verbessern.
- Verzögere Code, der nicht vor dem nächsten Paint laufen muss. Teile den Code auf. Trenne kritischen Code, der vor dem INP laufen muss, von nicht-kritischem Code (zum Beispiel das Senden von Analytics). Plane Letzteren mit der
requestIdleCallback()-Methode für die Zeit nach dem Paint-Event. - Optimiere Code, der vor dem Paint laufen muss. Prüfe deinen Code und schreibe langsame oder ineffektive Teile um.
- Gib sofortiges Feedback. Bei komplizierten oder potenziell langsamen Tasks solltest du sofortiges Feedback geben, bevor der Hauptcode ausgeführt wird.
Minimiere das Presentation Delay
- Halte das DOM klein und einfach. Für einen Browser ist es viel einfacher, eine Seite mit wenigen und einfachen, unverschachtelten DOM-Elementen (HTML-Knoten) zu rendern als eine Seite mit vielen verschachtelten DOM-Knoten. Lies mehr über das Beheben von übermäßiger DOM-Größe.
- Nutze content-visibility, um Off-Screen-Content lazy zu rendern.
content-visibilitybeschleunigt das Rendering sichtbarer Seitenteile. Es verzögert das Rendering von Off-Screen-Content und rendert diesen erst im richtigen Moment.
Quick Fix: Yield zum main thread mit scheduler.yield()
Das Yielding zum main thread zwischen kritischer und nicht-kritischer Arbeit verbessert alle drei INP-Phasen auf einmal. Die scheduler.yield()-API bietet einen sauberen Weg dafür. Hier ist eine wiederverwendbare Hilfsfunktion mit einem Fallback für Browser, die die API noch nicht unterstützen:
async function yieldToMain() {
if ('scheduler' in window && 'yield' in window.scheduler) {
return await window.scheduler.yield();
}
return new Promise((resolve) => {
setTimeout(resolve, 0);
});
}
// Nutzung in einem Event-Handler
async function handleButtonClick() {
// Kritische Arbeit: Update der UI
updateVisualFeedback();
// Yield, um den Browser zeichnen zu lassen
await yieldToMain();
// Nicht-kritische Arbeit: Analytics, Logging
sendAnalyticsEvent('button_click');
logInteraction();
} Jede INP-Phase im Detail
Jede Phase hat ihre eigenen Optimierungsstrategien:
- Input Delay: Lerne, wie du die Zeit zwischen der Nutzerinteraktion und dem Start der Event-Verarbeitung minimierst. Das Input Delay ist normalerweise die kürzeste der drei Phasen. Es schießt jedoch beim Start der Seite in die Höhe, wenn der main thread mit der Skriptausführung beschäftigt ist.
- </b>Processing Time: Optimiere den Event-Handler-Code, der während der Interaktion läuft. Auf den meisten Seiten zahlt sich hier der Großteil deiner Optimierungsarbeit aus.
- Presentation Delay: Reduziere die Rendering- und Painting-Arbeit nach der Event-Verarbeitung. Auf komplexen Seiten mit großen DOMs ist dies oft die längste Phase.
Zusätzliche Strategien, die alle drei Phasen betreffen, findest du in unseren Guides zum Verbessern des INP durch den Verzicht auf JavaScript Scrolling und zur Wahl zwischen async und defer für dein JavaScript.
CoreDash spricht MCP.
Häng es an Claude oder einen beliebigen AI Agent und frag: Warum ist mein INP letzten Dienstag hochgegangen?
So funktioniert's
