Interaction to Next Paint (INP) Probleme finden und beheben: Ein Schritt-für-Schritt-Leitfaden

Erfahren Sie, wie Sie Interaction to Next Paint Probleme mithilfe von RUM Daten, Chrome DevTools und der LoAF API identifizieren und beheben.

Arjen Karel Core Web Vitals Consultant
Arjen Karel - linkedin
Last update: 2026-03-04

Interaction to Next Paint (INP) Probleme finden und beheben

Diese Seite ist Teil unserer Serie über Interaction to Next Paint (INP). INP misst die Reaktivität Ihrer Website, indem die Verzögerung zwischen einer Benutzerinteraktion und der nächsten visuellen Aktualisierung erfasst wird. Ein guter INP-Wert liegt unter 200 Millisekunden, während Werte über 500 Millisekunden als schlecht eingestuft werden. Wenn Sie neu beim Thema INP sind, beginnen Sie mit der INP-Hub-Seite für einen vollständigen Überblick.

Laut dem 2025 Web Almanac scheitern 23 % der mobilen Ursprünge immer noch am INP. Wenn Ihre Website dazu gehört, sieht der Prozess wie folgt aus: Bestätigen Sie das Problem in der Search Console, diagnostizieren Sie die Grundursachen mit Real User Monitoring (RUM) Daten, reproduzieren Sie es lokal und wenden Sie gezielte Korrekturen für jede INP-Phase an.

INP-TIPP: Meistens ist der INP viel schlechter, wenn ein Benutzer während der Startphase des Seitenladevorgangs mit der Seite interagiert. Deshalb ist es beim Debugging von INP sinnvoll, alle Interaktionen sowie den Ladezustand der Seite zu protokollieren!

Schritt 1: Prüfen Sie den INP in der Search Console

Der erste Schritt besteht darin, zu bestätigen, dass Sie tatsächlich ein INP-Problem haben. Bevor Sie Codeänderungen vornehmen, verifizieren Sie das Problem in der Google Search Console, damit Sie auf Basis realer Felddaten und nicht auf Annahmen arbeiten.

Loggen Sie sich in Ihre Google Search Console ein. Klicken Sie im linken Menü auf Core Web Vitals und wählen Sie entweder Mobil oder Desktop (Tipp: Meistens treten INP-Probleme zuerst auf Mobilgeräten auf, beginnen Sie also mit Mobilgeräten).

Hier sehen Sie eine Übersicht aller Core Web Vitals bezogenen Probleme, die derzeit auf Ihrer Website bestehen. Wenn eines dieser Probleme INP-bezogen ist, haben Sie bestätigt, dass ein Problem vorliegt.

Schritt 2: Identifizieren Sie Interaction to Next Paint Probleme

Die Google Search Console liefert Ihnen außer URL-Gruppen keine Informationen, um herauszufinden, was die Probleme mit dem Interaction to Next Paint verursacht. Meistens gehen Entwickler daher blind vor. Sie fangen an, ungenutztes JavaScript zu entfernen (immer eine gute Idee) und den main thread aufzubrechen (ebenfalls eine gute Idee), aber das behebt den INP fast nie vollständig.

Deshalb müssen wir bei der Verbesserung des INP genau wissen, was vor sich geht. Wir benötigen Antworten auf vier kritische Fragen:

Welche Elemente verursachen bei Interaktion einen schlechten INP-Wert? In der Regel wird ein schlechter INP-Wert nicht durch ein einzelnes Element, sondern durch eine Kombination von Problemen verursacht. Wir müssen diese nacheinander angehen, beginnend mit den schlimmsten, und uns nach oben arbeiten.
Wann finden diese Interaktionen statt? Passieren sie während der Startphase des Seitenladevorgangs oder treten sie auch auf, wenn die Hauptseite vollständig geladen ist?
Wo finden diese Interaktionen statt? Treten sie auf jeder Seite auf oder nur auf einigen wenigen ausgewählten Seiten?
Wie können wir diese Interaktionen reproduzieren? Sie haben vielleicht schon herausgefunden, dass es schwierig ist, INP-Probleme zu reproduzieren. Deshalb müssen wir uns auf Erfolg einstellen, indem wir Geräteeigenschaften mit einem schlechten INP-Wert nachahmen.

RUM-Tracking einrichten

Um all diese Fragen zu beantworten, müssen wir anfangen, echte Benutzer zu tracken und alle Probleme zu protokollieren, die beim Interaction to Next Paint auftreten könnten. Es gibt verschiedene Möglichkeiten, RUM-Tracking zu aktivieren. Die erste ist die Verwendung der Web Vitals Library und das Senden der Ergebnisse an Ihr eigenes Analyse-Backend. Der Vorteil dieser Methode ist, dass sie kostengünstig und flexibel ist. Der Nachteil ist, dass sie viel zusätzliche Arbeit bedeuten kann.

Eine gute Alternative zum Senden Ihrer Core Web Vitals Daten an Ihr eigenes Backend ist die Verwendung eines der vielen RUM-Tools auf dem Markt. Wir haben CoreDash genau für diese Anwendungsfälle entwickelt. CoreDash ist ein kostengünstiges, schnelles und effektives RUM-Tool, das die Aufgabe erfüllt. Natürlich gibt es viele RUM-Lösungen auf dem Markt, die ebenfalls funktionieren (allerdings zu einem höheren Preis).

Langsame Interaktionen pro Element finden, die einen hohen INP verursachen

Beginnen Sie damit, die langsamsten Interaktionen zu finden, die die schlechtesten INP-Werte verursachen. Listen Sie Ihre Seiten in CoreDash nach "INP metric by Elements" auf und Sie erhalten Ihre langsamsten Interaktionen. Klicken Sie auf die erste Zeile, um Ihre Metriken nach diesen Interaktionen zu filtern.

Finden Sie heraus, wann schlechte INP-Interaktionen auftreten

Sortieren Sie als Nächstes die gefilterten URLs nach dem Ladezustand (load state). Dies gibt Ihnen mehr Einblick in die Grundursache des INP. In diesem Fall tritt der hohe INP auf, wenn der DOM-Inhalt geladen wurde. Das bedeutet, dass Scripte bereits analysiert wurden, aber asynchrone Scripte und die Unterressourcen der Seite noch nicht geladen sind. In diesem Fall wird der INP durch frühe Klicks verursacht, wenn der Seitenladevorgang noch nicht vollständig abgeschlossen ist.

Fahren Sie fort, indem Sie auf den Ladezustand mit der höchsten Auswirkung klicken, um einen weiteren Filter zu erstellen.

URLs finden, die für hohe INP-Werte verantwortlich sind

Wenn wir schließlich nach den Elementen mit der langsamsten Interaktion und dem korrekten Ladezustand gefiltert haben, werfen wir einen Blick auf die URLs, an denen der INP am schlechtesten ist. In diesem Fall passiert dies eindeutig auf einem bestimmten Satz von Seiten.

Geräteeigenschaften finden

Wenn wir langsame Interaktionen, den Ladezustand und die 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 würden uns den Gerätespeicher, die Bandbreite, die Bildschirmgröße und andere Hardware-Eigenschaften ansehen. Sobald wir diese Eigenschaften identifiziert haben, können wir dazu übergehen, das Problem zu reproduzieren und zu protokollieren.

Verwendung der Long Animation Frames (LoAF) API für die INP-Diagnose

Die Long Animation Frames API (LoAF) sagt Ihnen genau, welche Scripte und Funktionen langsame Interaktionen verursachen. Im Gegensatz zur älteren Long Tasks API liefert Ihnen LoAF Script-URLs, Funktionsnamen und Timing-Aufschlüsselungen pro Frame. Sie ist besonders nützlich, wenn sie mit RUM Daten aus einem Tool wie CoreDash kombiniert wird.

Dieser Observer sammelt LoAF-Einträge für Frames, die länger als 50 ms dauern, und erfasst Script-Attribution, Dauer und Blockierzeit:

// Long Animation Frames für INP-Attribution beobachten
const observer = new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    // Nur Frames protokollieren, die länger als 50 ms dauern
    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 enthüllt, welche Scripte zu jeder Phase des INP beitragen. Das scripts-Array nennt Ihnen die exakte Quelldatei und den Funktionsnamen, während renderStart und styleAndLayoutStart Ihnen helfen, die Verarbeitungszeit von der Darstellungsverzögerung zu trennen. LoAF ist derzeit Chromium-exklusiv (Chrome 123+). Verlassen Sie sich beim Debugging für Firefox und Safari stattdessen auf den Trace im Performance-Panel und RUM Daten. Weitere Informationen darüber, wie sich async vs defer beim Laden von JavaScript auf diese Timings auswirkt, finden Sie in unserem speziellen Leitfaden.

Schritt 3: Reproduzieren und Debuggen von Interaktionen, die einen hohen INP-Wert verursachen

Mit diesen Daten in der Hand können wir anfangen, die Grundursachen zu beheben.

Bereiten Sie sich auf den Erfolg vor: Reproduzieren Sie die Umstände des INP-Fehlers

Als Nächstes sollten wir versuchen, den fehlerhaften INP nachzustellen. Dazu ahmen wir die Umstände nach, unter denen der INP scheitern könnte.

Verwenden Sie das Chrome Performance Panel: Öffnen Sie die Chrome-Entwicklertools (Strg+Umschalt+I) und wählen Sie das Performance-Panel aus. In der oberen Leiste können Sie den CPU-Throttle (drosseln Sie ihn auf 4-fache Verlangsamung, um ein normales Mobilgerät zu emulieren), den Network-Throttle (wählen Sie das Fast 3G-Preset, um ein durchschnittliches Mobilgerät nachzuahmen) und die Hardware-Concurrency auf 4 oder 8 einstellen, um Ihr durchschnittliches Mobilgerät zu simulieren.

Um Chrome mit weniger verfügbarem Speicher zu laden (obwohl das Herabsetzen der Netzwerk- und CPU-Einstellungen oft ausreicht), starten Sie Chrome in einem Docker-Container und weisen Sie weniger Speicher zu.

Laden Sie die Seite neu, interagieren Sie und prüfen Sie den INP mit dem Core Web Vitals Visualizer

Simulieren Sie nun die Bedingungen und bestätigen Sie, dass die INP-Werte mit den Berichten Ihrer RUM Daten übereinstimmen.

Seite neu laden und zum richtigen Zeitpunkt auf das richtige Element klicken

Debuggen Sie den INP mit einem Performance-Trace

Dies ist der Moment, auf den Sie sich in den vorherigen Schritten vorbereitet haben. Es ist an der Zeit herauszufinden, warum eine bestimmte Interaktion den schlechten Interaction to Next Paint Wert verursacht.

Öffnen Sie die Chrome Developer Console (Strg+Umschalt+I), navigieren Sie zum Performance-Panel und klicken Sie diesmal auf das Symbol mit dem kreisförmigen Pfeil, um die Seite neu zu laden und die Aufzeichnung zu starten (oder verwenden Sie das Tastenkürzel Strg+Umschalt+E). Während die Aufzeichnung läuft, interagieren Sie mit dem Element, das den schlechten INP verursacht. Stoppen Sie die Aufzeichnung nach einigen Sekunden und untersuchen Sie die Timeline. Suchen Sie nach dem Interaktionsereignis im Track "Interactions" und untersuchen Sie dann die entsprechenden Aufgaben im Track "Main", um genau zu sehen, welcher Code während jeder Phase ausgeführt wird.

Lesen des Performance-Trace

Im Chrome Performance-Panel erscheint die Interaktion als farbiger Balken im Track "Interactions". Klicken Sie darauf, um die gesamte INP-Dauer und deren Aufschlüsselung zu sehen. Darunter, im Track "Main", sehen Sie die einzelnen Aufgaben, die während der Interaktion gelaufen sind. Achten Sie auf:

  • Aufgaben vor dem Event-Handler: Diese tragen zum Input Delay bei.
  • Der Event-Handler selbst: Dies ist die Processing Time.
  • Rendering-Arbeit nach Abschluss des Handlers: Dies ist der Presentation Delay.

Vergleichen Sie diese Ergebnisse mit Ihren LoAF-Daten, um zu bestätigen, dass die im Trace identifizierten Scripte mit den Attributionsdaten Ihres RUM-Tools übereinstimmen. Dies ist auch ein guter Moment, um zu prüfen, ob JavaScript-Scroll-Handler zum Problem beitragen.

Schritt 4: Behebung von INP-Problemen

Sie wissen, welche Interaktion langsam ist und warum. Zeit, es zu beheben. Der Interaction to Next Paint kann in 3 Phasen unterteilt werden: Input Delay, Processing Time und Presentation Delay.

Jede Phase benötigt einen anderen Ansatz. Hier ist eine Zusammenfassung. Folgen Sie den Links für vollständige Optimierungs-Leitfäden.

Input Delay minimieren:

Input Delay ist die Zeit zwischen der Interaktion mit der Seite und dem Beginn des Event-Callbacks. Während ein gewisser Input Delay unvermeidbar ist (Browser benötigen Zeit, um die Callbacks zu planen), können Sie ihn minimieren:

  1. Vermeiden Sie lange Aufgaben (long tasks). Wann immer eine Aufgabe läuft, blockiert sie den main thread und lässt die Event-Callbacks warten. Dies ist besonders wichtig bei der Optimierung von frühen Klicks (da zu diesem Zeitpunkt die meisten Scripte ausgeführt werden). Strategien zur Reduzierung der JavaScript-Blockierung finden Sie in unserem Leitfaden zu async vs defer JavaScript.
  2. Seien Sie vorsichtig beim Erstellen neuer Aufgaben. Zum Beispiel wiederkehrende Aufgaben über setTimeout() oder Aufgaben, die wahrscheinlich vor dem INP-Ereignis auftreten, wie Callbacks beim mouseover-Ereignis.
  3. Frühe Interaktion messen und bewerten. Wenn ein interaktives Element früh präsentiert wird (z. B. ein Suchfeld) und durch JavaScript gesteuert wird, das erst später lädt, löst jede Interaktion mit dem Element keine sofortige Layout-Aktualisierung aus. Priorisieren Sie entweder die Funktionalität oder blenden Sie das Element aus bzw. deaktivieren Sie es, bevor es ordnungsgemäß funktioniert.
  4. Verwenden Sie Web Workers, um JavaScript außerhalb des main threads des Browsers auszuführen. Web Workers ermöglichen es Scripten, außerhalb des main threads zu laufen. Dies verhindert, dass der main thread blockiert und INP Input Delay Probleme verursacht.
  5. Laden Sie "Nice-to-have"-Drittanbieter-Scripte während der Idle Time des Browsers. Einige Scripte sind kritischer als andere. Es ist sinnvoll, diese Scripte zu priorisieren und weniger wichtige Scripte während der Idle Time des Browsers zu laden. Zum Beispiel ein Chat-Script. In unserem Leitfaden zu 14 Methoden zum Aufschieben von JavaScript finden Sie praktische Techniken.

Processing Time minimieren

Processing Time ist die Zeit, die der Browser benötigt, um alle Callback-Funktionen für das Ereignis auszuführen.
  1. Entfernen Sie unnötigen Code. Unnötiger Code ist entweder veralteter Code, der immer noch läuft, oder neuer Code, der auf dieser spezifischen Seite nicht benötigt wird, aber dennoch CPU-Zeit beansprucht. Dies ist mit Abstand der einfachste Weg, den INP sofort zu verbessern.
  2. Verschieben Sie Code, der nicht vor dem nächsten Paint ausgeführt werden muss. Teilen Sie Code in kritischen Code auf, der vor dem INP ausgeführt werden muss, und nicht-kritischen Code (z. B. das Senden von Analysen) und planen Sie diesen nach dem Paint-Ereignis mit der Methode requestIdleCallback() ein.
  3. Optimieren Sie Code, der vor dem Paint ausgeführt werden muss. Überprüfen Sie Ihren Code und schreiben Sie langsame oder ineffektive Teile neu.
  4. Geben Sie sofortiges Feedback. Geben Sie bei komplizierten oder möglicherweise langsamen Aufgaben sofortiges Feedback, bevor Sie den Hauptcode ausführen.

Presentation Delay minimieren

Presentation Delay repräsentiert die Zeit, die der Browser benötigt, um visuelle Aktualisierungen zu rendern, die auf die Interaktion folgen. Wenn die Seite aktualisiert werden muss, rendert der Browser zuerst den betroffenen Teil der Seite neu, malt dann den neuen Inhalt und sendet ihn an den Compositor (GPU und Raster).
  1. Halten Sie den DOM klein und einfach. Für einen Browser ist es viel einfacher, eine Seite mit wenigen und einfachen, nicht verschachtelten DOM-Elementen (HTML-Knoten) zu rendern, als eine Seite mit vielen verschachtelten DOM-Knoten zu rendern. Lesen Sie mehr über die Behebung einer übermäßigen DOM-Größe.
  2. Verwenden Sie content-visibility zum Lazy-Render von Inhalten außerhalb des Bildschirms. Content-visibility beschleunigt das Rendering sichtbarer Teile der Seite, indem es das Rendering von Inhalten außerhalb des Bildschirms verzögert und diese Inhalte erst bei Bedarf rendert.

Schnelle Lösung: yield an den main thread mit scheduler.yield()

Das Yielding an den main thread zwischen kritischer und nicht-kritischer Arbeit verbessert alle drei INP-Phasen gleichzeitig. Die scheduler.yield() API bietet einen sauberen Weg, dies zu tun. Hier ist eine wiederverwendbare Helper-Funktion 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);
  });
}

// Verwendung in einem Event-Handler
async function handleButtonClick() {
  // Kritische Arbeit: UI aktualisieren
  updateVisualFeedback();

  // Yield, um den Browser malen zu lassen
  await yieldToMain();

  // Nicht-kritische Arbeit: Analyse, Logging
  sendAnalyticsEvent('button_click');
  logInteraction();
}

Jede INP-Phase im Detail

Jede Phase hat ihre eigenen Optimierungsstrategien:

  • Input Delay: Erfahren Sie, wie Sie die Zeit zwischen der Benutzerinteraktion und dem Beginn der Ereignisverarbeitung minimieren können. Der Input Delay ist in der Regel die kleinste der drei Phasen, steigt aber während des Seitenstarts an, wenn der main thread mit der Script-Ausführung beschäftigt ist.
  • Processing Time: Optimieren Sie den Event-Handler-Code, der während der Interaktion ausgeführt wird. Auf den meisten Seiten zahlt sich hier der Großteil Ihres Optimierungsaufwands aus.
  • Presentation Delay: Reduzieren Sie die Rendering- und Painting-Arbeit, die auf die Ereignisverarbeitung folgt. Auf komplexen Seiten mit großen DOMs ist dies oft die zeitaufwendigste Phase.

Weitere Strategien, die alle drei Phasen betreffen, finden Sie in unseren Leitfäden zur Verbesserung des INP durch Verzicht auf JavaScript-Scrolling und zur Wahl zwischen async und defer für Ihr JavaScript.

Ask AI why your INP spiked.

CoreDash is the only RUM tool with MCP support. Connect it to your AI agent and query your Core Web Vitals data in natural language. No more clicking through dashboards.

See How It Works
Interaction to Next Paint (INP) Probleme finden und beheben: Ein Schritt-für-Schritt-LeitfadenCore Web Vitals Interaction to Next Paint (INP) Probleme finden und beheben: Ein Schritt-für-Schritt-Leitfaden