Wie man dem Main Thread den Vortritt lässt, um den INP zu verbessern

Dem Main Thread den Vortritt lassen (Yielding)

Stellen Sie sich einen romantischen Film vor. Der Schauplatz ist ein kleiner französischer Marktplatz im Zentrum eines kleinen Dorfes. Die Straßen sind voller Paare, die Kaffee trinken, Croissants essen und Blumen kaufen. Stellen Sie sich nun vor, was passiert, wenn nur ein Käufer gleichzeitig etwas von einem Verkäufer erwerben kann, während alle anderen warten müssen, bis sie an der Reihe sind. Der Bäcker wird mit Anfragen überhäuft, beim Floristen bricht Streit aus und der romantische Spaziergang verwandelt sich in frustrierendes Warten.

Nun ... genau das passiert auf einer Website, wenn es zu geschäftig zugeht.

Zuletzt geprüft von Arjen Karel im März 2026

Warum Yielding für den INP wichtig ist

Der main thread eines Browsers verarbeitet alle wichtigen Prozesse: das Parsen von HTML und CSS, das Ausführen von JavaScript, das Verarbeiten von Input-Events wie Klicks und Scrolls sowie das visuelle Rendering. Er arbeitet nach einem Single-Thread-Modell, was bedeutet, dass er nur eine Aufgabe gleichzeitig ausführen kann. Wenn eine Aufgabe gestartet wird, führt der Browser sie bis zum Ende aus und stoppt nicht, bis sie fertig ist. Keine andere Aufgabe wird geplant, bis die aktuelle abgeschlossen ist. Dies wird als Blockieren des main thread bezeichnet.

Das Blockieren des main thread ist die Hauptursache für schlechte Interaction to Next Paint (INP) Werte. Wenn ein Besucher auf eine Schaltfläche klickt und Ihr JavaScript den main thread für 200 ms blockiert, kann der Browser keine visuelle Antwort zeichnen (paint), bis das Script fertig ist. Die processing time Phase des INP misst genau diese Verzögerung. Laut dem 2025 Web Almanac liegt die mediane mobile Total Blocking Time bei 1.916 ms, was einem Anstieg von 58 % gegenüber dem Vorjahr entspricht. Das sind fast 2 Sekunden, in denen der Browser nicht auf Benutzereingaben reagieren kann.

Eine Möglichkeit, dies zu beheben, ist das Yielding an den main thread. Yielding ist eine Technik, bei der lange Aufgaben in mehrere kleinere Aufgaben unterteilt werden, damit der Browser dazwischen wichtigere Arbeiten (wie das Reagieren auf Benutzereingaben) erledigen kann.

Long tasks und Blocking Period: Wenn eine Aufgabe länger als 50 Millisekunden dauert, wird sie als Long Task eingestuft. Alles, was über diesen Schwellenwert von 50 Millisekunden hinausgeht, wird als "Blocking Period" der Aufgabe bezeichnet. Das Aufteilen dieser Long Tasks in kleinere Segmente ermöglicht es dem Browser, reaktionsfähig zu bleiben, selbst wenn rechenintensive Operationen verarbeitet werden.

Alte Yielding-Strategien

Vor der Prioritized Task Scheduling API gab es vier Möglichkeiten, an den main thread abzugeben. Alle haben Einschränkungen.

• setTimeout(): Die am häufigsten verwendete Strategie. setTimeout() mit einer Verzögerung von 0 fügt die Aufgabe am Ende der Warteschlange hinzu, sodass andere Aufgaben zuerst ausgeführt werden können. Das Problem: Aufgaben können nur an das Ende der Warteschlange geschoben werden, sodass sich andere Scripte vordrängeln können, bevor Ihr Code fortgesetzt wird. Verschachtelte setTimeout()-Aufrufe erzwingen zudem nach fünf Runden eine Mindestverzögerung von 5 ms.
• requestAnimationFrame(): Reiht eine Funktion zur Ausführung vor dem nächsten Repaint des Browsers ein. Wird oft mit setTimeout() kombiniert, um sicherzustellen, dass Callbacks nach dem nächsten Layout-Update geplant werden. Nicht für Yielding konzipiert, sondern für Animationsarbeiten.
• requestIdleCallback(): Bestens geeignet für unkritische Aufgaben mit niedriger Priorität, die während der Leerlaufzeit des Browsers ausgeführt werden können. Die Einschränkung: Es gibt keine Garantie, dass geplante Aufgaben zeitnah (oder überhaupt) auf einem vielbeschäftigten main thread ausgeführt werden.
• isInputPending(): Prüft auf anstehende Benutzereingaben und gibt nur ab, wenn eine Eingabe erkannt wird. Google empfiehlt diesen Ansatz nicht mehr. Er kann falsch-negative Ergebnisse liefern und berücksichtigt keine anderen performance-kritischen Arbeiten wie Animationen und Rendering-Updates.

scheduler.yield()

Die Einschränkungen dieser Methoden waren ein Anliegen für das Chrome-Team, insbesondere da viele Websites den INP nicht bestehen. Um dies zu adressieren, haben sie scheduler.yield() entwickelt: eine neue API, die es Entwicklern ermöglicht, sofort an den main thread abzugeben, ohne die Reihenfolge der Aufgaben zu verändern oder Komplexität hinzuzufügen.

scheduler.yield() wurde in Chrome 129 stabil veröffentlicht (September 2024) und wird nun von allen gängigen Browsern außer Safari unterstützt.

Code-Beispiel

Da Safari scheduler.yield() noch nicht unterstützt, verwenden Sie einen Fallback auf setTimeout():

function yieldToMain() {
  if ('scheduler' in window && 'yield' in window.scheduler) {
    return window.scheduler.yield();
  }
  return new Promise((resolve) => {
    setTimeout(resolve, 0);
  });
}

Die Funktion yieldToMain() prüft, ob window.scheduler.yield existiert. Wenn ja, verwendet sie die native API. Wenn nicht, fällt der Code auf setTimeout() zurück. Dies entspricht dem von Google empfohlenen Muster.

Für Projekte, die die vollständige Prioritized Task Scheduling API benötigen (einschließlich scheduler.postTask() und TaskController), unterhält Google Chrome Labs einen offiziellen Polyfill.

Praxisbeispiel: Verbesserung der Suche mit yieldToMain()

Hier sehen Sie, wie yieldToMain() die Sucherfahrung für Ihre Benutzer verbessern kann.

Die Funktion handleSearch() aktualisiert zuerst den Inhalt der Schaltfläche, um sofortiges Feedback zu geben, dass eine Suche läuft, und gibt dann ab, um dem Browser das Zeichnen dieses Updates zu ermöglichen. Als Nächstes ruft fetchData() die Suchdaten ab und updateHTML(data) zeigt die Ergebnisse an. Ein weiteres yieldToMain() sorgt für ein schnelles Layout-Update. Schließlich werden weniger wichtige Aufgaben für die Leerlaufzeit des Browsers geplant. Beachten Sie, dass ich vor requestIdleCallback() nicht abgegeben habe, da es ohnehin nur ausgeführt wird, wenn der main thread im Leerlauf ist.

async function handleSearch() {
  \/* den Inhalt des Buttons nach dem Absenden schnell aktualisieren *\/
  updateButtonToPending();

  \/* Yield to Main *\/
  await yieldToMain();

  \/* Daten abrufen und HTML aktualisieren *\/
  const data = await fetchData();
  updateHTML(data);

  \/* Erneut Yield to Main *\/
  await yieldToMain();

  \/* einige Funktionen sollten nur während der Leerlaufzeit des Browsers laufen *\/
  requestIdleCallback(sendDataToAnalytics);
}

Ein weiteres praktisches Beispiel finden Sie unter Verwendung desselben Yield-Musters bei dataLayer Pushes, um zu verhindern, dass Analyse-Scripte Interaktionen blockieren.

Warum scheduler.yield() besser ist

Im Gegensatz zu setTimeout(), das verzögerte Aufgaben am Ende der Warteschlange hinzufügt, pausiert scheduler.yield() die Ausführung und platziert die Fortsetzung an der Vorderseite der Warteschlange. Ihr Code wird fortgesetzt, sobald Aufgaben mit höherer Priorität (wie die Verarbeitung von Input-Callbacks) abgeschlossen sind. Dies ist der entscheidende Unterschied: Sie können an den main thread abgeben, ohne das Risiko, dass sich andere Scripte vordrängeln, bevor Ihr Code fortgesetzt wird.

scheduler.yield() ist zudem darauf ausgelegt, mit der Prioritized Task Scheduling API zusammenzuarbeiten. Wenn es innerhalb eines scheduler.postTask() Callbacks aufgerufen wird, erbt scheduler.yield() die Prioritätsstufe der Aufgabe. Diese Kombination gibt Ihnen eine feingranulare Kontrolle darüber, wie Ihr JavaScript priorisiert wird und wann es abgibt.

Browser-Unterstützung

scheduler.yield() wird von 71,5 % der Browser weltweit unterstützt:

• Chrome 129+ und Edge 129+: stabil seit September 2024
• Firefox 142+: stabil seit August 2025
• Safari: nicht unterstützt, kein angekündigter Zeitplan

Der setTimeout() Fallback in der oben gezeigten yieldToMain() Funktion stellt sicher, dass Ihr Code in allen Browsern funktioniert. Safari-Benutzer erhalten das ältere Verhalten, bei dem Fortsetzungen ans Ende der Warteschlange gestellt werden, aber die Seite gibt dennoch ab. Mit wachsender Browser-Unterstützung werden automatisch mehr Benutzer von der schnelleren Fortsetzung profitieren.

Wenn das Problem darin besteht, dass Drittanbieter-Scripte den main thread vollständig blockieren, ist das Aufschieben dieser Scripte (Deferring) ein besserer erster Schritt als Yielding. Yielding hilft, wenn Ihr eigener Code viel Arbeit verrichten muss, Sie aber möchten, dass der Browser zwischen den Blöcken reaktionsfähig bleibt.

Um zu überprüfen, ob Yielding Ihren INP im Feld verbessert, überwachen Sie Ihre Seiten mit Real User Monitoring. Lab-Tools wie Lighthouse messen die Total Blocking Time, aber nur Felddaten zeigen Ihnen den tatsächlichen INP, den Ihre Besucher erleben.