Interaction to Next Paint (INP)

Interaction to Next Paint, kurz INP, ist eine der drei Core Web Vitals von Google. Die Kennzahl misst die Reaktionsschnelligkeit, also wie schnell eine Seite sichtbar reagiert, wenn jemand klickt, tippt oder eine Taste drückt. Ein niedriger INP-Wert bedeutet, dass die Oberfläche praktisch sofort reagiert, ein hoher, dass der Besucher klickt und dann wartet, während die Seite eingefroren wirkt. INP ist im März 2024 zum Core Web Vital geworden und hat First Input Delay abgelöst. Dieser Leitfaden erklärt, was INP misst, welcher Wert gut ist und mit welchen Maßnahmen sich die Reaktionsschnelligkeit gezielt verbessern lässt.

Was INP misst

INP beobachtet jede Interaktion, die ein Besucher während der Nutzung ausführt, und misst, wie lange sie bis zur sichtbaren Reaktion braucht. Eine Interaktion ist eine einzelne Eingabe wie ein Klick, ein Tippen oder ein Tastendruck. Scrollen und das Überfahren mit der Maus zählen nicht, weil sie nicht über denselben Verarbeitungsweg laufen. Aus allen gemessenen Interaktionen meldet INP einen einzelnen Wert, der die schlechteste realistische Reaktionszeit der Seite abbildet, also nicht einen Durchschnitt, der die langsamen Momente verdeckt.

Auf Seiten mit vielen Interaktionen lässt INP einige wenige Ausreißer außen vor, damit nicht eine einzige Verzögerung den Wert bestimmt. Der Anspruch bleibt aber streng, denn eine einzige nicht reagierende Interaktion ist genau das, was eine Seite defekt wirken lässt.

Die drei Phasen einer Interaktion

Jede Interaktionsdauer besteht aus drei aufeinanderfolgenden Teilen, und zu wissen, welcher überwiegt, ist entscheidend:

• Eingabeverzögerung (Input Delay): die Zeit von der Eingabe, bis der Browser mit dem Event-Handler beginnen kann. Hier ist meist der Haupt-Thread mit anderer Arbeit belegt.
• Verarbeitungszeit (Processing Time): wie lange die Event-Handler laufen.
• Darstellungsverzögerung (Presentation Delay): die Zeit vom Ende der Handler bis zum nächsten gezeichneten Frame, der die Änderung zeigt.

Ein langsamer INP besteht fast nie aus allen drei Phasen gleichzeitig. Eine lange Eingabeverzögerung deutet auf einen blockierten Haupt-Thread, eine lange Verarbeitungszeit auf schwere Handler, eine lange Darstellungsverzögerung auf aufwendiges Rendern.

Ein Beispiel aus der Praxis

Man stelle sich eine Produktseite mit Filtern vor. Der Besucher tippt auf einen Filter. Zunächst ist der Browser vielleicht schon mit einem Analyse-Skript beschäftigt, der Tipp wartet also, das ist die Eingabeverzögerung. Wenn der Handler endlich läuft, sortiert er eine Liste mit 500 Produkten neu und baut das DOM synchron um, das ist die Verarbeitungszeit. Anschließend muss der Browser die neue Liste anordnen und zeichnen, das ist die Darstellungsverzögerung. In Summe wartet der Besucher nach einem einzigen Tipp 600 Millisekunden, deutlich im schlechten Bereich. Die Lösung ist nicht eine Änderung, sondern drei kleine, je auf eine Phase gerichtet: das Analyse-Skript aus diesem Moment heraushalten, die Neusortierung verzögern, damit der Filter zuerst aufleuchtet, und die anschließende DOM-Arbeit verkleinern.

Was ist ein guter INP-Wert?

Google definiert drei Bereiche, gemessen am 75. Perzentil der realen Interaktionen über mobile und stationäre Geräte:

• Gut: 200 Millisekunden oder weniger
• Verbesserungswürdig: zwischen 200 und 500 Millisekunden
• Schlecht: mehr als 500 Millisekunden

200 Millisekunden sind die Schwelle, unterhalb derer sich eine Interaktion unmittelbar anfühlt. Weil der Maßstab das 75. Perzentil ist, müssen drei von vier Interaktionen darunter bleiben, und meist entscheiden mobile Geräte mit langsameren Prozessoren, ob eine Seite besteht.

Wie sich INP von First Input Delay unterscheidet

INP hat FID abgelöst, weil FID zu wenig gemessen hat. FID betrachtete nur die Eingabeverzögerung der allerersten Interaktion und ignorierte Verarbeitungszeit, Darstellungsverzögerung und jede weitere Interaktion. Eine Seite konnte einen perfekten FID erreichen und sich trotzdem zäh anfühlen, sobald der Besucher zu klicken begann. INP misst jede Interaktion von der Eingabe bis zum nächsten Zeichnen und liegt damit viel näher an der realen Erfahrung. FID ist vollständig aus den Core Web Vitals entfernt.

Feld- und Labdaten

INP braucht echte Interaktionen, deshalb sind Felddaten aus dem Chrome UX Report und aus Real User Monitoring maßgeblich. Laborwerkzeuge können keinen echten INP erzeugen, weil niemand klickt. Stattdessen nutzen sie die Total Blocking Time als Näherung dafür, wie wahrscheinlich der Haupt-Thread blockiert ist, wenn eine Interaktion eintrifft. Eine schlechte Total Blocking Time im Labor ist also ein Warnsignal für einen schlechten INP im Feld. Im Browser lassen sich reale Interaktionen über die Event Timing API aufzeichnen:

new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    console.log('Interaktion:', entry.name, Math.round(entry.duration), 'ms');
  }
}).observe({ type: 'event', durationThreshold: 40, buffered: true });

Die JavaScript-Bibliothek web-vitals meldet INP mit Attribution und benennt die langsamste Interaktion samt Element, und das Performance-Panel der Chrome DevTools zeigt eine Interaktionsspur auf der Zeitachse.

Wie bei den anderen Core Web Vitals werden die Felddaten pro URL ausgewiesen, sofern eine Seite genug Interaktionen hat, andernfalls fallen sie auf einen Origin-Durchschnitt zurück.

Was einen hohen INP verursacht

Schlechte Reaktionsschnelligkeit lässt sich fast immer auf einen belegten Haupt-Thread oder zu viel Arbeit in den Handlern zurückführen:

• Lange Aufgaben belegen den Haupt-Thread und verhindern, dass er auf Eingaben reagiert.
• Schwere Event-Handler, die aufwendige Arbeit synchron erledigen, verlängern die Verarbeitungszeit.
• Ein großes, komplexes DOM macht jede Neuberechnung nach einer Interaktion langsamer.
• Hydration und erneutes Rendern von Frameworks binden den Haupt-Thread, besonders früh im Seitenleben.
• Drittanbieter-Skripte führen eigene Aufgaben auf dem Haupt-Thread aus und konkurrieren mit den eigenen Handlern.

Warum INP oft der schwierigste Core Web Vital ist

Viele Seiten bestehen LCP und CLS, scheitern aber an INP. Der Grund ist, dass Ladeleistung und Stabilität vor allem beim ersten Aufbau anfallen, während die Reaktionsschnelligkeit über die gesamte Nutzung immer wieder auf die Probe gestellt wird. Je interaktiver eine Seite ist, je mehr JavaScript sie ausführt und je mehr Drittanbieter-Skripte mitlaufen, desto häufiger konkurriert Arbeit um den Haupt-Thread genau dann, wenn ein Nutzer klickt. Besonders Single-Page-Apps und stark mit Plugins bestückte Seiten trifft das. INP ist deshalb selten mit einer einzigen Maßnahme gelöst, sondern verlangt, die Arbeit im Haupt-Thread grundsätzlich zu reduzieren und über die Zeit zu verteilen.

INP verbessern

1. Lange Aufgaben aufteilen und dem Haupt-Thread die Kontrolle zurückgeben

Jede Aufgabe, die länger als etwa 50 Millisekunden dauert, blockiert Eingaben. Lange Arbeit in kleinere Stücke aufteilen und dem Browser zwischendurch die Kontrolle zurückgeben. Die moderne Methode ist scheduler.yield(), mit einem Fallback:

async function verarbeite(items) {
  for (const item of items) {
    verarbeiteEinzeln(item);
    if (scheduler?.yield) {
      await scheduler.yield();
    } else {
      await new Promise(r => setTimeout(r));
    }
  }
}

2. Zuerst Rückmeldung geben, schwere Arbeit verschieben

Im Event-Handler zunächst nur das Nötigste tun, um dem Besucher zu zeigen, dass etwas passiert, und den Browser zeichnen lassen, bevor der aufwendige Teil läuft. Die Interaktion fühlt sich dann sofort an, auch wenn die eigentliche Arbeit Zeit braucht.

async function handleClick() {
  zeigeSpinner();           // günstig: sofortige Rückmeldung
  await scheduler.yield();  // den Browser zeichnen lassen
  rendereErgebnisse();      // die schwere Arbeit läuft danach
}

3. Weniger JavaScript ausliefern

Weniger Skript bedeutet einen freieren Haupt-Thread und kürzere Aufgaben. Code-Splitting, Tree-Shaking und das Entfernen von totem Code senken die Grundlast bei jeder Interaktion. Auf Deutsch wie Englisch ist ungenutztes JavaScript der direkteste Hebel auf die Eingabeverzögerung.

4. Schwere Berechnungen auslagern

Arbeit, die nicht das DOM berührt, etwa das Parsen oder Sortieren großer Datenmengen, kann in einem Web Worker auf einem eigenen Thread laufen. Der Haupt-Thread bleibt frei für Eingaben.

5. Aufwendige Handler entlasten

Handler an häufig ausgelösten Ereignissen wie Eingabe oder Größenänderung feuern oft öfter als nötig. Mit Debounce oder Throttle läuft die teure Arbeit erst, wenn die Aktivität abklingt.

6. DOM und Rendering schlank halten

Ein kleineres DOM macht die Stil- und Layoutarbeit nach einer Interaktion schneller und verkürzt die Darstellungsverzögerung. DOM-Lese- und Schreibvorgänge bündeln, um Layout-Thrashing zu vermeiden, und in Frameworks unnötiges erneutes Rendern durch Memoization verhindern. Es lohnt sich außerdem, den Zustand nicht bei jeder Eingabe zu aktualisieren, sondern nur dann, wenn sich sichtbar etwas ändert.

7. Drittanbieter-Skripte zähmen

Drittanbieter-Code führt Aufgaben auf dem Haupt-Thread aus. Nicht essenzielle Tags erst laden, wenn die Seite interaktiv ist, für schwere Widgets Fassaden verwenden und Tags entfernen, die ihren Aufwand nicht mehr rechtfertigen.

8. Framework-Rendering steuern

Single-Page-Apps bündeln viel Arbeit auf dem Haupt-Thread. In React lassen sich nicht dringende Zustandsänderungen mit startTransition markieren, damit eine Interaktion zeichnen kann, bevor das teure erneute Rendern läuft, und useDeferredValue hält eine Eingabe reaktionsfähig. Große Bäume nicht bei jedem Tastendruck neu rendern. Beim Laden kann Hydration Interaktionen blockieren, hier helfen partielle oder progressive Hydration und eine Islands-Architektur.

9. INP in WordPress reduzieren

In WordPress entsteht hoher INP meist durch zu viele Plugins und schwere Einbettungen, die jeweils Skripte auf dem Haupt-Thread ausführen. Nicht genutzte Plugins entfernen, nicht essenzielle Skripte mit einem Performance-Plugin verzögern und schwere Einbettungen wie Chat-Widgets und Videoplayer durch Fassaden ersetzen, die erst bei Interaktion laden.

INP und die anderen Core Web Vitals

INP ist eine von drei Core Web Vitals, neben Largest Contentful Paint für die Ladeleistung und Cumulative Layout Shift für die visuelle Stabilität. Sie teilen häufig eine gemeinsame Ursache: Dasselbe überschüssige JavaScript, das das Laden verlangsamt, blockiert auch den Haupt-Thread, von dem die Reaktionsschnelligkeit abhängt. Einen Überblick über alle drei gibt die Seite zu den Core Web Vitals.

INP prüfen und verifizieren

Weil INP eine Feldmetrik ist, kommt die eigentliche Bestätigung aus dem Chrome UX Report über das nachlaufende 28-Tage-Fenster oder aus Real User Monitoring, das INP auf dem eigenen Verkehr früher meldet. Zur Fehlersuche im Performance-Panel der DevTools eine Interaktion aufzeichnen und ihre drei Phasen ablesen, und im Labor die Total Blocking Time als Frühindikator beobachten. Auf einem Mittelklasse-Smartphone mit gedrosselter CPU testen und die wichtigsten Interaktionen ausführen, etwa Menüs öffnen, Listen filtern und Formulare absenden.

Die Attribution der web-vitals-Bibliothek nennt zusätzlich, welche der drei Phasen überwog und welches Element die langsamste Interaktion ausgelöst hat, sodass sich der genaue Handler statt eines Verdachts angehen lässt.

Häufige Fragen

Was ist ein guter INP-Wert?

200 Millisekunden oder weniger am 75. Perzentil der realen Interaktionen gilt als gut. Zwischen 200 und 500 Millisekunden ist verbesserungswürdig, mehr als 500 Millisekunden ist schlecht.

Was ist der Unterschied zwischen INP und FID?

First Input Delay maß nur die Eingabeverzögerung der ersten Interaktion. INP misst jede Interaktion der gesamten Sitzung end-to-end, inklusive Verarbeitungszeit und nächstem Zeichnen. INP hat FID im März 2024 als Core Web Vital abgelöst.

Was verursacht einen hohen INP?

Meist ein belegter Haupt-Thread und schwere Event-Handler: lange Aufgaben, aufwendiger Handler-Code, ein großes DOM, Framework-Hydration und Drittanbieter-Skripte verlängern eine der drei Phasen.

Zählt Scrollen für INP?

Nein. INP misst einzelne Interaktionen wie Klicks, Tippen und Tastendrücke. Scrollen und das Überfahren mit der Maus zählen nicht.

Wie messe ich INP?

Über Felddaten aus dem Chrome UX Report oder Real User Monitoring, weil INP echte Interaktionen braucht. Zur Fehlersuche über das Performance-Panel der DevTools und die web-vitals-Bibliothek, im Labor die Total Blocking Time als Näherung.

Ist INP ein Google-Ranking-Faktor?

Ja. INP ist eine der drei Core Web Vitals und damit Teil der Page-Experience-Signale, bewertet anhand der Felddaten echter Nutzer.

Wie lange dauert es, bis sich Verbesserungen zeigen?

Im Real User Monitoring auf dem eigenen Verkehr zeigen sich Verbesserungen relativ schnell, in den offiziellen Felddaten des Chrome UX Report über das nachlaufende 28-Tage-Fenster, also über einige Wochen.