INP in den Core Web Vitals: Was er ist und wie du ihn verbesserst

Was ist Interaction to Next Paint (INP)?

Interaction to Next Paint (INP) ist der Core Web Vital (CWV) für Reaktionsfähigkeit: die Zeit von einem Klick, Tap oder Tastendruck bis zum nächsten Frame auf dem Bildschirm, gemessen an der langsamsten Interaktion eines Seitenbesuchs. Ein guter INP liegt bei 200 Millisekunden oder weniger beim 75. Perzentil. INP hat First Input Delay (FID) am 12. März 2024 abgelöst.

Ein schlechter INP fällt Besuchern durch Buttons auf, die einen Moment lang nicht reagieren: Sie tippen auf das Menü, nichts passiert, also tippen sie noch einmal. INP ist neben LCP und CLS einer der drei Core Web Vitals, und Google nutzt sie als Ranking-Signal.

Auf Seiten mit vielen Klicks ignoriert INP einen Ausreißer pro 50 Interaktionen. Ein Besuch ohne einen einzigen Klick, Tap oder Tastendruck hat keinen INP.

INP vs. FID: Was hat sich im März 2024 geändert?

INP hat First Input Delay (FID) am 12. März 2024 als Core Web Vital abgelöst. FID maß nur die Wartezeit, bevor der Browser die erste Interaktion eines Besuchs verarbeitete. INP misst jede Interaktion – von der Eingabe bis zum nächsten Frame auf dem Bildschirm.

INP zählt also auch die Arbeit mit, die FID nie erfasst hat: die Event-Handler nach der Wartezeit sowie Style, Layout und Paint, bevor sich der Bildschirm ändert. Ein Klick, dessen Handler nach 10 ms startet und dann 300 ms läuft, hat FID bestanden und scheitert am INP.

Welche Interaktionen misst INP?

INP misst Klicks, Taps und Tastendrücke, inklusive Bildschirmtastaturen. Jeder Tastendruck beim Tippen in einem Formularfeld ist eine eigene Interaktion. Scrollen, Hovern und Zoomen zählen nicht als Interaktionen.

Scroll-Code kann Klicks trotzdem verlangsamen. Ein Klick auf einen Ankerlink, der eine JavaScript-Scroll-Animation startet, ist eine Interaktion – und der Scroll-Code läuft darin. Ein Handler, der bei jedem Scroll-Event läuft, hält den Main Thread beschäftigt. Ein Tap beim Scrollen muss deshalb warten. scroll-behavior: smooth in CSS sorgt ganz ohne Skript für weiches Scrollen.

Die drei Phasen einer INP-Interaktion (Subparts)

Jede von INP gemessene Interaktion hat drei aufeinanderfolgende Phasen: Input Delay, Processing Duration und Presentation Delay. Der INP einer Interaktion ist ihre Summe. Bei der längsten Phase setzt der Fix an. Die Chrome DevTools zeigen alle drei im INP-Breakdown eines Traces.

Ein Tap während des Ladens im Core Web Vitals Visualizer. Der Handler brauchte 0 ms. Der nächste Frame wartete danach 478 ms auf Ladevorgänge der Seite; eine Wartezeit nach dem Handler zählt als Presentation Delay.

• Input delay: Die Eingabe wartet, bis der bereits auf dem Main Thread laufende Task beendet ist. Meist ist das ein Skript, das beim Laden läuft: ein Tag-Manager, ein Chat-Widget oder ein Framework, das noch hydriert.
• Processing duration (auch Processing Time genannt): Die Event-Handler der Interaktion laufen. Ein Handler ist langsam, wenn er zu viel auf einmal tut: etwa ein Analytics-Tag, das beim Klick feuert, oder ein Skript, das nach jeder Änderung das Layout abfragt und den Browser zwingt, das Layout immer wieder neu zu berechnen.
• Presentation delay: Nach den Handlern berechnet der Browser Styles und Layout neu und zeichnet den nächsten Frame. Ein großes DOM macht das langsam, ebenso ein Re-Render, der weite Teile der Seite verändert. Andere Tasks vor diesem Frame zählen ebenfalls hierzu.

Was ist ein guter INP-Wert?

Ein guter INP-Wert liegt bei 200 Millisekunden oder weniger. Zwischen 200 und 500 Millisekunden ist er verbesserungsbedürftig, über 500 Millisekunden schlecht. Google wertet das 75. Perzentil der Seitenaufrufe aus, separat für Smartphones und Desktop.

Das 75. Perzentil (p75) bedeutet: Drei von vier Seitenaufrufen brauchen einen INP von 200 ms oder weniger, langsame Smartphones eingeschlossen. Smartphones scheitern zuerst: Ein langsamerer Prozessor führt dasselbe JavaScript länger aus. Tippt der Besucher, ist der Main Thread deshalb öfter belegt.

Laut dem State of Web Vitals haben 91,8 % der Websites einen guten INP auf Smartphones.

So misst du Interaction to Next Paint (INP)

Der von Google genutzte INP stammt von echten Besuchern in Chrome: dem Chrome UX Report (CrUX), den PageSpeed Insights und die Search Console anzeigen. Ein RUM-Tool (Real User Monitoring) zeigt dir, welcher Klick auf welcher Seite langsam ist. Chrome DevTools zeigt dir, warum.

Search Console und PageSpeed Insights

Der Core-Web-Vitals-Bericht in der Search Console gruppiert URLs mit unzureichendem INP nach Problemen, inklusive Beispiel-URLs für jede Gruppe. „INP-Problem: länger als 200 ms (Mobil)“ bedeutet, dass Smartphone-Besuche dieser Gruppe ähnlicher URLs beim 75. Perzentil über 200 ms liegen; „INP-Problem: länger als 500 ms (Mobil)“ steht für mehr als 500 ms. Deine Seite kann sich für dich schnell anfühlen, obwohl der Bericht Fehler meldet: Viele deiner Besucher nutzen langsamere Smartphones als du und tippen auch während des Ladens. PageSpeed Insights zeigt den INP beim p75 über die letzten 28 Tage für eine URL – oder für die gesamte Website, wenn die URL zu wenige Chrome-Besuche hat. Ein Fix wird in beiden erst verzögert sichtbar: Die Search Console braucht bis zu 28 Tage.

Betroffene URLs pro Tag für ein INP-Problem in der Search Console.

Real User Monitoring

CrUX liefert eine einzige Zahl pro URL oder URL-Gruppe. Ein RUM-Skript auf deiner eigenen Website misst jeden Besuch: Es erfasst das geklickte Element und ob die Seite noch geladen hat. In CoreDash wird der INP nach beidem aufgeschlüsselt. So siehst du, welche Interaktion langsam ist: der Filter-Button auf Smartphones beim Laden der Seite.

RUM-Tools messen den INP mittlerweile auch in Safari und Firefox. CrUX – und damit Google – erfasst nur Chrome. RUM und Search Console können deshalb unterschiedliche Zahlen zeigen.

Eigene Klicks in Chrome DevTools

Öffne das Performance-Panel in den Chrome DevTools. Die Live-Metriken zeigen den INP deiner eigenen Session beim Klicken – samt Protokoll jeder Interaktion und ihrer drei Subparts. Stelle die CPU auf 4x Slowdown, damit sich dein Laptop eher wie ein Smartphone verhält. Klicke auch, während die Seite noch lädt: Ein Klick beim Laden wartet auf die Skripte, die in genau diesem Moment laufen. Um zu sehen, was lief: Nimm beim Klicken einen Trace auf. Der Interactions-Track markiert die Interaktion und der Main-Track zeigt die Tasks darunter. Die Extension Core Web Vitals Visualizer zeigt denselben Breakdown direkt auf der Seite.

Die Bibliothek web-vitals loggt jede Interaktion, die den INP verschlechtert, in die Konsole – samt Element und Subparts:

<script type="module">
  import {onINP} from 'https://unpkg.com/web-vitals@6/dist/web-vitals.attribution.js?module';
  onINP(console.log, {reportAllChanges: true});
</script>

Lighthouse

Ein normaler Lighthouse-Lauf hat keinen INP: Er lädt die Seite und klickt nie. Der ähnlichste Lab-Wert ist die Total Blocking Time (TBT): die Zeit, die der Main Thread während des Ladens blockiert war. INP ist meist viel niedriger als TBT, aber eine bessere TBT verbessert auch den INP. Warum Lighthouse und deine Field Data unterschiedliche Zahlen zeigen: Lighthouse vs field data.

So verbesserst du den INP

Die langsamsten Interaktionen auf Smartphones bestimmen deinen INP. Finde sie in deinen Field Data (Search Console oder RUM-Tool), prüfe den längsten Subpart und verkürze genau diesen: weniger JavaScript beim Laden für den Input Delay, weniger Arbeit im Event-Handler für die Processing Duration, weniger Renderaufwand für den Presentation Delay. Die Schritt-für-Schritt-Anleitung für INP führt vom Search-Console-Bericht direkt zur Codezeile.

WordPress

Starte bei einer WordPress-Website mit den Plugin-Skripten, die jede Seite lädt: Jedes einzelne davon kann einen Tap ausbremsen. Der Script Manager von Perfmatters und Asset CleanUp deaktivieren Plugin-Skripte auf Seiten, die sie nicht brauchen – etwa ein Formular-Plugin auf deinen Produktseiten. Ist danach noch etwas langsam, bitte einen Entwickler um einen Trace: eine Aufzeichnung des langsamen Taps bei 4x CPU-Drosselung samt dem Namen des Skripts, das darin läuft.

Die Einstellungen zum Verzögern von JavaScript („Delay JavaScript execution“ in WP Rocket, „Delay JavaScript“ in Perfmatters, „Load JS Deferred“ auf „Delayed“ in LiteSpeed Cache) halten Skripte bis zur ersten Interaktion zurück und führen dann alle auf einmal aus. Das schönt den Lighthouse-Score, weil Lighthouse die Seite nie berührt. Ein echter Besucher tippt auf das Menü und wartet, während der Browser alles herunterlädt und ausführt – und INP erfasst den langsamsten Tap des Besuchs. Lass diese Einstellungen für den INP deaktiviert.

Mein eigenes Plugin WP Core Web Vitals lädt Skripte verzögert in ihrer Originalreihenfolge und führt Analytics, Pixel und Chat-Widgets erst nach dem Laden der Seite aus, ohne auf einen Tap zu warten.

Shopify

Jede Shopify-App verlangsamt jeden Klick ein Stück: Du installierst sie für ein einzelnes Feature, und ihr Skript lädt auf Seiten und bei Klicks, die mit diesem Feature gar nichts zu tun haben. Schalte im Theme-Editor unter App embeds eine App nach der anderen aus und miss den langsamen Tap jedes Mal neu. App-Blöcke in einer Section bleiben aktiv, wenn du das App-Embed abschaltest: Entferne sie direkt in dieser Section. Eine entfernte App kann Code in den Snippets des Themes hinterlassen – durchsuche das Theme daher nach ihrem Namen.

App-Einstellungen ändern selten, was bei einem Klick abläuft. Das entscheidet der Theme-Code: was Add to Cart tut, wann der Cart-Drawer rendert, welche App-Skripte laden. Dieser Teil ist Entwicklerarbeit: Der Add-to-Cart-Handler aktualisiert zuerst den Bildschirm und erledigt den Rest danach. Und der Cart-Drawer rendert nur das, was sich geändert hat.

Input Delay: Weniger JavaScript beim Laden

Ein Tap beim Laden wartet auf jedes Skript, das in diesem Moment läuft. Das Coverage-Panel in den DevTools zeigt, welcher Code bisher ausgeführt wurde: Ein Skript, das nach dem Durchklicken der Seite noch weitgehend ungenutzt ist, kann weg. Und vieles von dem, was bleibt, kann warten, bis die Seite geladen ist. Brauchst du in den ersten 500 ms des Ladevorgangs wirklich ein Chat-Widget? Starte es erst nach dem Load-Event, wenn der Browser idle ist:

window.addEventListener('load', () => {
  const whenIdle = window.requestIdleCallback || ((cb) => setTimeout(cb, 1));
  whenIdle(() => {
    const script = document.createElement('script');
    script.src = '/js/chat-widget.js';
    document.head.appendChild(script);
  });
});

async und defer verhindern, dass ein Skript den HTML-Parser blockiert. Das Skript läuft aber trotzdem während des Ladens – deshalb helfen sie eher dem LCP als dem INP. Weitere Wege, Skripte später auszuführen, findest du in 16 Methoden, um JavaScript zu verzögern oder einzuplanen.

Unterteile eigene Long Tasks (alles über 50 ms auf dem Main Thread), damit der Browser einen wartenden Tap dazwischen verarbeiten kann. Gib den Main Thread nach etwa 50 ms Arbeit wieder frei (yield), egal wie lange ein einzelnes Item dauert:

function yieldToMain() {
  if (globalThis.scheduler?.yield) {
    return scheduler.yield();
  }
  return new Promise((resolve) => setTimeout(resolve, 0));
}

async function processItems(items) {
  let lastYield = performance.now();
  for (const item of items) {
    processItem(item);
    if (performance.now() - lastYield > 50) {
      await yieldToMain();
      lastYield = performance.now();
    }
  }
}

scheduler.yield() läuft in Chrome und Firefox; Safari nutzt den setTimeout-Fallback. Mehr dazu unter yield to the main thread.

Processing Duration: Zuerst den Bildschirm aktualisieren

Ein schneller Event-Handler erledigt zuerst das, was der Besucher sieht, und verschiebt alles andere auf die Zeit nach dem nächsten Paint. Ein Tag im Klick-Handler läuft, bevor sich der Bildschirm ändern kann. Verschiebst du es hinter das Update, sieht der Besucher das Ergebnis zuerst – und das Tag läuft trotzdem:

button.addEventListener('click', () => {
  showConfirmation(); // what the visitor sees
  requestAnimationFrame(() => {
    setTimeout(() => {
      // runs after the next frame is painted
      dataLayer.push({ event: 'cta_click' });
    }, 0);
  });
});

Ein requestIdleCallback() an dieser Stelle scheitert auf jedem iPhone: Safari unterstützt es nicht. Der Handler wirft nach showConfirmation() einen Fehler; der Klick wirkt optisch normal, aber das Event geht verloren. Die Tag-Manager-Variante findest du in scheduling dataLayer events; bei einer Kunden-Website hat das Verschieben von dataLayer.push() hinter den Paint den INP um 100 ms gesenkt.

Wartet ein Formular oder ein Add-to-Cart auf den Server, zeige sofort auf dem Bildschirm, dass der Tap ankam („Wird hinzugefügt...“). Lass den Request danach im Hintergrund abschließen.

Der langsame Klick, den ich am häufigsten sehe, ist ein Produktfilter: Der Handler aktualisiert die Liste, liest die neue Höhe aus, ändert daraufhin etwas und liest die Höhe noch einmal aus. Jeder Lesezugriff nach einer Änderung zwingt den Browser, das Layout noch im Handler neu zu berechnen. Auf einer Testseite für Ferienwohnungen unter WordPress dauerte ein Tap auf den Filter „Alle“ 320 ms – davon 298 ms reines Layout, das durch das Theme-Skript erzwungen wurde. Liest das Skript alle Höhen zuerst aus oder übernimmt CSS die Aufgabe, dauert derselbe Tap nur noch 16 ms: ein einziger Frame. Beides gemessen in Chrome auf Smartphone-Breite mit 4x gedrosselter CPU. Forced reflow liefert den Fix für Themes, Plugins, Apps und deinen eigenen Code.

Presentation Delay: Kleineres DOM, weniger Re-Renders

Je größer das DOM, desto länger braucht der Browser nach den Handlern für das Rendern des nächsten Frames. Lighthouse führt ein großes DOM unter „Optimize DOM size“ auf: wie du das DOM verkleinerst.

Auf langen Seiten überspringt der Browser dank content-visibility: auto das Rendern von Abschnitten außerhalb des Viewports, bis der Besucher in deren Nähe scrollt:

.product-reviews,
.site-footer {
  content-visibility: auto;
  contain-intrinsic-size: auto 600px;
}

Gib jedem dieser Abschnitte ein contain-intrinsic-size nahe an seiner echten Höhe. Ohne diese Angabe ist ein übersprungener Bereich null Pixel hoch – und die Scrollbar springt beim Rendern der Abschnitte.

Manche Single-Page-Applications rendern nach jeder Interaktion viel zu viel Inhalt neu: Ein Klick ändert einen Zähler, und die halbe Seite rendert noch einmal. In React DevTools zeigt „Highlight updates when components render“, welche Komponenten ein Klick neu rendert.

INP debuggen mit der Long Animation Frames (LoAF) API

Die Long Animation Frames (LoAF) API meldet jeden Frame, der länger als 50 ms gedauert hat, samt den darin gelaufenen Skripten: Datei, Funktion und die jeweilige Ausführungsdauer. Damit bekommt eine langsame Interaktion in deinen Field Data einen konkreten Skriptnamen. LoAF funktioniert in Chromium-Browsern (ab Chrome 123).

new PerformanceObserver((list) => {
  for (const frame of list.getEntries()) {
    if (frame.duration < 100) continue; // only the slowest frames
    for (const script of frame.scripts) {
      console.log(script.sourceURL, script.sourceFunctionName,
        Math.round(script.duration) + ' ms');
    }
  }
}).observe({ type: 'long-animation-frame', buffered: true });

Ein RUM-Tool sammelt diese Einträge bei jedem Besuch. Öffne in CoreDash INP, dann Breakdown und gruppiere nach LOAF: Jede Zeile zeigt ein Skript samt dem INP der Interaktionen, in denen es lief, aufgeschlüsselt nach den drei Subparts. Starte mit dem Skript, dessen Balken auf Smartphones am längsten ist. Der Leitfaden zur Long Animation Frames API erklärt jedes einzelne Feld eines Eintrags.

CoreDash, gruppiert nach LOAF (Desktop): Grün ist Input Delay, Lila Processing Duration, Blau Presentation Delay.

Liegt der langsame Tap in einem Skript, das du nicht selbst geschrieben hast – wie einer App, einem Tag oder einem Consent-Banner – und du weißt nicht, welches du entfernen sollst? In einer Core Web Vitals Power Hour gehen wir deine Field Data und den Trace dieses Taps gemeinsam durch – und du bekommst den Fix schriftlich.