Long Tasks und INP optimieren: Reaktionsfähigkeit messbar verbessern

1. Warum INP die entscheidende Interaktions-Metrik ist

Interaction to Next Paint, kurz INP, misst die Zeit von einer Nutzerinteraktion, etwa einem Klick oder Tastendruck, bis der Browser das nächste sichtbare visuelle Update darstellt. Anders als der Vorgänger First Input Delay betrachtet INP nicht nur die allererste Interaktion einer Seite, sondern alle Interaktionen während des gesamten Seitenaufenthalts, und meldet den schlechtesten repräsentativen Wert. Das macht INP zu einer deutlich strengeren und ehrlicheren Metrik für die tatsächliche Reaktionsfähigkeit einer Anwendung.

Seit INP als Core Web Vital First Input Delay abgelöst hat, reicht es nicht mehr, nur die erste Interaktion einer Sitzung zu optimieren. Eine Single Page Application, die beim ersten Klick schnell reagiert, aber bei einer Interaktion nach mehreren Minuten Nutzung durch angesammelten Zustand und Speicherverbrauch träge wird, bekommt trotzdem einen schlechten INP Wert. Diese Verschiebung zwingt Teams dazu, Reaktionsfähigkeit als durchgehende Eigenschaft der gesamten Sitzung zu behandeln, nicht als einmaligen Ladezeitpunkt.

Ein guter INP Wert liegt laut Google Richtwerten unter zweihundert Millisekunden, während alles über fünfhundert Millisekunden als schlecht gilt. Diese Schwellen sind bewusst so gewählt, dass sie sich mit der menschlichen Wahrnehmung von unmittelbarer Reaktion decken. Wer INP verbessern will, muss verstehen, wo genau in dieser Zeitspanne die Verzögerung entsteht, denn INP setzt sich aus mehreren Teilphasen zusammen, die jeweils eigene Ursachen und eigene Lösungsansätze haben.

2. Die drei Phasen einer Interaktion und wo INP entsteht

Jede für INP relevante Interaktion durchläuft drei Phasen: Input Delay, Processing Time und Presentation Delay. Der Input Delay beginnt mit dem physischen Klick oder Tastendruck und endet, sobald der Event Handler tatsächlich zu laufen beginnt. Diese Phase wird lang, wenn der Main Thread zum Zeitpunkt der Interaktion bereits mit einer anderen Aufgabe beschäftigt ist, etwa einem laufenden Long Task, der die Interaktion in die Warteschlange zwingt.

Die Processing Time umfasst die eigentliche Ausführung aller Event Handler, die auf die Interaktion reagieren, inklusive synchroner Zustandsänderungen und ausgelöster Re-Renders in Frameworks. Diese Phase ist am direktesten durch Code beeinflussbar, denn sie besteht vollständig aus JavaScript, das der Entwickler kontrolliert. Die Presentation Delay schließlich beschreibt die Zeit vom Ende der Event Handler bis zum nächsten gemalten Frame, inklusive Style Recalculation, Layout und Paint, und wird oft unterschätzt, weil sie nicht direkt im eigenen Code sichtbar ist.

Für INP zählt die Summe aller drei Phasen, nicht nur eine einzelne. Ein Team, das nur die Processing Time optimiert, aber ignoriert, dass der Main Thread durch einen unabhängigen Long Task blockiert ist, wird trotzdem einen schlechten INP Wert messen. Deshalb ist der erste Schritt jeder INP Optimierung immer eine Analyse, welche der drei Phasen im konkreten Fall den größten Anteil an der Gesamtzeit hat.

// Measuring the three INP phases with the Event Timing API
new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    const inputDelay = entry.processingStart - entry.startTime;
    const processingTime = entry.processingEnd - entry.processingStart;
    const presentationDelay = entry.startTime + entry.duration - entry.processingEnd;

    console.log({
      interaction: entry.name,
      inputDelay: inputDelay.toFixed(1),
      processingTime: processingTime.toFixed(1),
      presentationDelay: presentationDelay.toFixed(1),
      total: entry.duration.toFixed(1),
    });
  }
}).observe({ type: "event", buffered: true, durationThreshold: 40 });

3. Long Tasks als Hauptursache für schlechte INP Werte

Ein Long Task, jede Aufgabe auf dem Main Thread über fünfzig Millisekunden, ist die häufigste Ursache für einen hohen Input Delay im Rahmen von INP. Wenn eine Interaktion mitten in einem laufenden Long Task eintrifft, muss sie warten, bis dieser Long Task vollständig abgeschlossen ist, bevor der Browser überhaupt beginnt, den zugehörigen Event Handler auszuführen. Ein einzelner dreihundert Millisekunden langer Long Task kann so allein durch schlechtes Timing die gesamte INP Messung dominieren.

Typische Quellen für Long Tasks, die INP verschlechtern, sind große Initialisierungsroutinen nach dem Laden, umfangreiche Datenverarbeitung als Reaktion auf eine vorherige Interaktion, und Third Party Skripte wie Analytics oder Werbe Tags, die synchron und ohne Rücksicht auf den Main Thread arbeiten. Besonders tückisch sind Long Tasks, die durch Framework interne Reconciliation entstehen, wenn eine Zustandsänderung eine große Anzahl an Komponenten gleichzeitig neu rendert, ohne dass der Entwickler dies bewusst so vorgesehen hat.

Die Strategie gegen Long Tasks im Kontext von INP ist nicht, sie vollständig zu vermeiden, das ist bei komplexer Anwendungslogik oft unrealistisch, sondern sie so aufzuteilen, dass zwischen den Teilen genug Raum für den Browser bleibt, auf wartende Interaktionen zu reagieren. Dieses Prinzip nennt sich Yielding und ist der zentrale Hebel, um Long Tasks INP freundlich zu gestalten, ohne die Gesamtmenge an Arbeit zu reduzieren.

4. Yielding: dem Main Thread bewusst Pausen geben

Yielding bedeutet, eine lange synchrone Operation an vorher festgelegten Stellen bewusst zu unterbrechen und die Kontrolle kurz an den Browser zurückzugeben, damit dieser wartende Interaktionen, Layout Updates oder andere höher priorisierte Aufgaben verarbeiten kann. Die einfachste, wenn auch technisch unelegante Methode ist setTimeout mit null Millisekunden, das eine Aufgabe in die Makrotask Warteschlange einreiht und dem Browser damit die Chance gibt, dazwischen zu rendern.

Effektiver für INP Optimierung ist die Aufteilung einer großen Schleife in Chunks fester Größe, mit einem Yield Punkt zwischen jedem Chunk. Entscheidend ist, wie oft und wie granular geyielded wird: zu selten, und Long Tasks bleiben lang genug, um INP zu verschlechtern, zu häufig, und der Overhead der ständigen Rückkehr zum Event Loop verlangsamt die Gesamtverarbeitung spürbar. Die richtige Balance liegt meist bei Chunks, die selbst deutlich unter der fünfzig Millisekunden Long Task Schwelle bleiben, etwa bei zehn bis zwanzig Millisekunden pro Chunk.

Ein oft übersehener Aspekt: Yielding hilft nur dann tatsächlich der INP Messung, wenn der Yield Punkt so gewählt ist, dass der Browser danach tatsächlich Gelegenheit hat, eine wartende Interaktion zu verarbeiten, bevor die nächste Chunk beginnt. Ein Yield mitten in einer Berechnung, die sofort danach mit noch mehr synchroner Arbeit weitergeht, ohne dem Event Loop echte Priorität zu geben, bringt für INP kaum Verbesserung.

// Yielding a long operation into chunks the main thread can interrupt
async function renderLargeTable(rows) {
  const CHUNK_SIZE = 50;

  for (let i = 0; i < rows.length; i += CHUNK_SIZE) {
    const chunk = rows.slice(i, i + CHUNK_SIZE);
    appendRowsToDOM(chunk);

    // Yield after each chunk so pending interactions get a chance to run
    await yieldToMain();
  }
}

function yieldToMain() {
  if ("scheduler" in window && "yield" in window.scheduler) {
    return window.scheduler.yield();
  }
  // Fallback: MessageChannel yields faster than setTimeout(0)
  return new Promise((resolve) => {
    const channel = new MessageChannel();
    channel.port1.onmessage = () => resolve();
    channel.port2.postMessage(null);
  });
}

5. Die Scheduler API und Priorisierung von Aufgaben

Die native Scheduler API mit scheduler.postTask und scheduler.yield wurde speziell entwickelt, um Yielding und Priorisierung ohne die Umwege über setTimeout oder MessageChannel zu ermöglichen. Mit scheduler.postTask lässt sich eine Aufgabe mit einer von drei Prioritätsstufen einreihen: user-blocking für Aufgaben, die eine direkte Nutzerinteraktion abschließen, user-visible als Standard für sichtbare, aber nicht kritische Arbeit, und background für Aufgaben, die warten können, bis der Main Thread frei ist.

Diese Priorisierung ist für INP besonders wertvoll, weil der Browser intern entscheiden kann, eine background priorisierte Aufgabe zu unterbrechen, sobald eine user-blocking Aufgabe durch eine Interaktion eintrifft. Ohne die Scheduler API muss ein Entwickler dieses Verhalten manuell mit Timern und Zustandsvariablen nachbauen, mit der Scheduler API übernimmt der Browser die Entscheidung basierend auf tatsächlicher Systemauslastung und wartenden Interaktionen.

Der Fallback für Browser ohne Scheduler API Unterstützung bleibt wichtig, da die API noch nicht überall verfügbar ist. Ein robustes Pattern prüft die Verfügbarkeit zur Laufzeit und fällt bei fehlender Unterstützung auf MessageChannel zurück, das im Vergleich zu setTimeout mit null Millisekunden eine spürbar geringere Verzögerung beim Zurückkehren zum Event Loop bietet und damit selbst als Fallback eine solide Basis für INP Optimierung darstellt.

// Using scheduler.postTask to prioritize interaction-critical work
async function handleSearchInput(query) {
  // User-blocking: update the input value immediately
  await scheduler.postTask(() => updateInputValue(query), {
    priority: "user-blocking",
  });

  // Background: fetch and render suggestions, can be preempted
  await scheduler.postTask(
    async () => {
      const suggestions = await fetchSuggestions(query);
      renderSuggestionList(suggestions);
    },
    { priority: "background" }
  );
}

6. Event Handler entschlacken: Debounce ist nicht genug

Ein weit verbreiteter, aber unvollständiger Ansatz zur INP Verbesserung ist Debouncing von Event Handlern, etwa bei Eingabefeldern. Debounce reduziert zwar die Anzahl der Ausführungen, verändert aber nichts an der Dauer einer einzelnen Ausführung. Wenn ein einzelner Handler Aufruf bereits einen Long Task auslöst, bleibt dieser Long Task auch nach Debouncing gleich lang, nur seltener. Für INP zählt aber jede einzelne gemessene Interaktion, nicht der Durchschnitt, also hilft Debouncing nur bedingt.

Effektiver ist es, den Event Handler selbst zu entschlacken: teure Berechnungen aus dem synchronen Pfad des Handlers entfernen und stattdessen per Yielding oder Scheduler API in kleinere, unterbrechbare Einheiten verlagern. Häufig hilft auch, die unmittelbare visuelle Reaktion, etwa das Highlighten eines Buttons, strikt vom Rest der Geschäftslogik zu trennen, sodass die visuelle Reaktion in der ersten, schnellen Phase des Handlers passiert und die teure Logik danach asynchron folgt.

In Frameworks mit virtuellem DOM lohnt sich zusätzlich die Prüfung, ob eine Interaktion unnötig viele Komponenten gleichzeitig neu rendert. Selektives Memoization, engere Zustandsgrenzen und die Vermeidung globaler Zustandsänderungen für lokale Interaktionen reduzieren die Menge an Arbeit, die pro Interaktion tatsächlich anfällt, und verkürzen damit direkt die Processing Time innerhalb von INP.

7. Presentation Delay: warum Rendering selbst INP beeinflusst

Die dritte Phase von INP, die Presentation Delay, wird häufig übersehen, weil sie nicht direkt im Event Handler Code sichtbar ist. Sie umfasst Style Recalculation, Layout und Paint nach Abschluss aller Event Handler, und kann durch komplexe CSS Selektoren, große DOM Bäume oder erzwungene Synchronous Layouts erheblich verlängert werden. Ein Handler, der selbst nur zehn Millisekunden braucht, aber danach ein Layout mit tausenden Elementen neu berechnen lässt, kann trotzdem eine INP Messung von mehreren hundert Millisekunden verursachen.

Ein häufiger Fehler, der Presentation Delay verlängert, ist das Lesen von Layout Eigenschaften wie offsetHeight direkt nach einer DOM Änderung innerhalb desselben Handlers, was einen erzwungenen synchronen Reflow auslöst. Solche Layout Thrashing Muster addieren sich direkt zur INP Zeit, weil der Browser die Berechnung nicht auf den nächsten natürlichen Frame verschieben kann, sondern sie sofort ausführen muss.

Für die Presentation Delay hilft, Style und Layout Änderungen zu bündeln, statt sie über mehrere Handler verteilt vorzunehmen, und CSS content-visibility für Bereiche außerhalb des sichtbaren Viewports zu nutzen, damit der Browser deren Layout Berechnung überspringen kann. Diese Maßnahmen wirken direkt auf die letzte, oft unterschätzte Phase von INP.

8. INP messen: Feld Daten, Labs Daten und Long Animation Frames

INP lässt sich sowohl mit Feld Daten aus dem Chrome User Experience Report als auch mit Labs Daten aus lokalen Messungen erfassen. Feld Daten zeigen die reale Verteilung über echte Nutzer und Geräte, verraten aber nicht, welche konkrete Interaktion oder welcher Code Pfad verantwortlich ist. Labs Daten aus dem Performance Panel oder aus der Long Animation Frames API liefern dafür die notwendige Detailtiefe, um eine konkrete Long Task einem konkreten Skript zuzuordnen.

Die Long Animation Frames API, kurz LoAF, ist speziell für die INP Diagnose entstanden und liefert im Gegensatz zur älteren Long Tasks API zusätzliche Informationen: welche Skripte innerhalb eines langen Frames liefen, wie lange Style und Layout Arbeit gedauert hat, und ob eine Verzögerung durch Rendering oder durch reines Scripting verursacht wurde. Diese Aufschlüsselung erlaubt eine deutlich präzisere Priorisierung von Optimierungsmaßnahmen als die reine Existenz eines Long Tasks.

// Long Animation Frames API: attributes long frames to specific scripts
new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    for (const script of entry.scripts) {
      if (script.duration > 50) {
        console.warn(
          `Long script: ${script.name} took ${script.duration}ms ` +
          `(source: ${script.sourceURL})`
        );
      }
    }
  }
}).observe({ type: "long-animation-frame", buffered: true });

9. Optimierungsstrategien im Vergleich

Nicht jede Optimierungsstrategie für INP passt zu jeder Problemursache. Die folgende Übersicht ordnet die wichtigsten Ansätze danach ein, welche INP Phase sie primär adressieren und wie hoch ihr Umsetzungsaufwand typischerweise ist.

Die Tabelle zeigt, warum eine reine Debounce Strategie oft enttäuscht: sie adressiert nur die Häufigkeit von Aufrufen, nicht deren Dauer, während INP genau die Dauer der einzelnen, schlechtesten Interaktion misst. Yielding und Scheduler API Priorisierung wirken direkt auf die Ursache und liefern deshalb messbar bessere INP Verbesserungen bei vertretbarem Umsetzungsaufwand.

10. Zusammenfassung

INP zwingt Teams dazu, Reaktionsfähigkeit über die gesamte Sitzung hinweg zu betrachten, nicht nur beim ersten Klick. Long Tasks sind die häufigste Ursache für hohe Input Delay Werte, und Yielding mit fester Chunk Größe ist die zuverlässigste Gegenmaßnahme, um lange Aufgaben INP freundlich zu gestalten. Die Scheduler API ergänzt Yielding um echte Priorisierung, sodass der Browser selbst entscheiden kann, wann eine Aufgabe unterbrochen werden sollte.

Wichtig bleibt, alle drei INP Phasen im Blick zu behalten: Input Delay durch blockierten Main Thread, Processing Time durch schwere Event Handler, und Presentation Delay durch Layout und Paint Aufwand. Debouncing allein löst keines dieser Probleme grundlegend, da es nur die Häufigkeit reduziert. Wer stattdessen mit Yielding, Scheduler API und schlanken Handlern arbeitet und die Ergebnisse mit der Long Animation Frames API überprüft, verbessert INP nachhaltig und messbar.

11. FAQ: Long Tasks und INP