Main Thread und Event Loop: Warum die Seite hängt

1. Warum das Single-Thread-Modell jede Performance-Entscheidung bestimmt

Jeder Klick, jedes Scroll-Event und jeder Tastendruck in einem Magento-Frontend wird von genau einem Thread verarbeitet: dem Main Thread des Browsers. Auf diesem einen Thread laufen JavaScript-Ausführung, Style-Berechnung, Layout, die meisten Painting-Schritte und die Verarbeitung von Nutzereingaben strikt nacheinander ab, niemals parallel. Diese Architekturentscheidung der Browserhersteller ist kein Implementierungsdetail, sondern die Grundlage, auf der jede Frontend-Performance-Optimierung aufbaut: Wer versteht, wie der Main Thread Arbeit einplant, versteht auch, warum eine Seite bei intensiver JavaScript-Ausführung einfriert, obwohl die CPU technisch noch Kapazität hätte.

Für ein flüssiges Nutzererlebnis muss der Browser bei 60 Bildern pro Sekunde alle 16,67 Millisekunden ein neues Frame zeichnen und dabei gleichzeitig auf Eingaben reagieren können. Jede Aufgabe, die diesen engen Zeitrahmen sprengt, verzögert entweder das nächste Frame oder die Antwort auf einen Klick, meist beides gleichzeitig. Genau dieses Zusammenspiel aus Call Stack, Task Queue und Microtask Queue entscheidet, ob sich ein Hyvä-Shop reaktionsschnell anfühlt oder ob Warenkorb-Klicks scheinbar wirkungslos verpuffen.

2. Der Call Stack: Synchrones, single-threaded Ausführungsmodell

Der Call Stack ist eine einfache Last-In-First-Out-Struktur, auf der die JavaScript-Engine jeden Funktionsaufruf als neuen Frame ablegt. Ruft eine Funktion eine weitere auf, wird ein neuer Frame oben auf den Stack gelegt; erst wenn dieser Frame durch ein return oder das Ende der Funktion entfernt wird, kann die darunterliegende Funktion fortfahren. Dieses Prinzip heißt Run-to-Completion: Eine einmal gestartete synchrone Funktion läuft immer vollständig durch, bevor die Engine eine andere Aufgabe vom Stack nimmt.

Run-to-Completion ist gleichzeitig Segen und Fluch. Es garantiert, dass zwei Funktionen niemals gleichzeitig denselben DOM-Knoten verändern und dadurch Race Conditions verursachen, wie sie in echten Multithread-Umgebungen mit Locks bekämpft werden müssen. Der Preis dafür: Solange der Call Stack nicht leer ist, kann der Browser weder rendern noch auf Eingaben reagieren, unabhängig davon, wie dringend diese sind. Ein einzelner, tief verschachtelter Funktionsaufruf mit einer Schleife über zehntausend Elemente blockiert exakt so lange, wie er zur vollständigen Abarbeitung braucht.

3. Die Task Queue: Makrotasks aus setTimeout, Events und I/O

Sobald der Call Stack leer ist, entnimmt der Event Loop die nächste anstehende Aufgabe aus der Task Queue, auch Makrotask-Queue genannt. Typische Quellen für Makrotasks sind setTimeout- und setInterval-Callbacks, DOM-Events wie Klicks oder Tastatureingaben, das Parsen von neu empfangenem HTML sowie abgeschlossene I/O-Operationen wie XHR-Callbacks. Der Event Loop verarbeitet pro Durchlauf genau einen Makrotask vollständig, bevor er erneut prüft, ob Rendering-Arbeit oder ein weiterer Makrotask ansteht.

Wichtig ist die Reihenfolge innerhalb eines Loop-Ticks: Nach jedem Makrotask hat der Browser die Gelegenheit, ein neues Frame zu rendern, sofern die Zeit reicht und sich sichtbare Änderungen ergeben haben. Werden viele kleine Makrotasks hintereinander eingereiht, etwa durch verschachtelte setTimeout-Aufrufe, entstehen dadurch mehrere potenzielle Rendering-Gelegenheiten. Ein einzelner, riesiger Makrotask dagegen blockiert diese Gelegenheit komplett, bis er fertig ist, denn der Event Loop kann eine laufende Aufgabe nicht unterbrechen, um zwischendurch zu rendern.

4. Die Microtask Queue: Promises, queueMicrotask und Priorität

Neben der Task Queue führt die JavaScript-Engine eine zweite, höher priorisierte Warteschlange: die Microtask Queue. Sie enthält Promise-Callbacks aus .then(), .catch() und .finally(), explizit über queueMicrotask() eingereihte Funktionen sowie interne Reaktionen wie MutationObserver-Callbacks. Der entscheidende Unterschied zur Task Queue: Nach jedem einzelnen ausgeführten Task, egal ob synchroner Skriptblock oder Makrotask, leert der Event Loop die komplette Microtask Queue, bevor er zum nächsten Makrotask oder zu Rendering-Arbeit übergeht.

Diese vollständige Leerung hat eine unangenehme Konsequenz: Wenn ein Microtask beim Ausführen einen weiteren Microtask erzeugt, etwa eine verkettete Promise-Chain, verlängert sich die Leerungsphase entsprechend, ohne dass zwischendurch gerendert wird. Rekursive Promise-Ketten oder ein queueMicrotask, das sich selbst erneut einreiht, können den Main Thread genauso blockieren wie ein klassischer Long Task, obwohl technisch nie ein einzelner Makrotask lange läuft. Diese Form der Microtask-Starvation ist in der Praxis schwerer zu erkennen, weil das Performance-Panel sie standardmäßig nicht als einzelnen Long Task ausweist.

5. Long Tasks: Die 50-Millisekunden-Schwelle und ihre Folgen

Die Long Tasks API definiert einen klaren Schwellenwert: Jede Aufgabe auf dem Main Thread, die länger als 50 Millisekunden ohne Unterbrechung läuft, gilt als Long Task. Dieser Wert ist nicht willkürlich gewählt, sondern leitet sich aus der RAIL-Heuristik ab, nach der Nutzereingaben innerhalb von 100 Millisekunden beantwortet werden sollten. Zieht man die Zeit für Browser-interne Verarbeitung ab, bleiben rund 50 Millisekunden als praktikables Budget für eine einzelne Aufgabe, bevor sie als spürbar blockierend wahrgenommen wird.

Long Tasks lassen sich programmatisch über einen PerformanceObserver mit dem Entry-Type "longtask" beobachten, der Startzeit, Dauer und die beteiligten Skript-Attribution-Daten liefert. Praktisch bedeutet ein Long Task von beispielsweise 180 Millisekunden: Jeder Klick, der in diesem Zeitfenster erfolgt, wird erst nach Abschluss des Tasks verarbeitet, und jedes fällige Rendering-Update wartet ebenfalls. In Magento-Shops entstehen Long Tasks typischerweise durch große Produktlisten-Renderings, ungefilterte JSON-Verarbeitung großer API-Antworten oder teure Layout-Berechnungen in Event-Handlern.

6. Lange Tasks aufteilen: Yielding-Patterns in der Praxis

Die zuverlässigste Gegenmaßnahme gegen Long Tasks heißt Chunking: Eine große Arbeitsmenge wird in kleinere Batches zerlegt, und zwischen den Batches gibt der Code die Kontrolle bewusst an den Event Loop zurück, damit dieser rendern und Eingaben verarbeiten kann. Klassisch geschieht dieses Yielding über setTimeout(fn, 0), das die Fortsetzung als neuen Makrotask einreiht statt sie im selben Call-Stack-Frame weiterlaufen zu lassen. Wichtig zu wissen: Ab dem fünften verschachtelten setTimeout-Aufruf erzwingen die meisten Browser eine Mindestverzögerung von 4 Millisekunden, was das Yielding messbar verlangsamt.

Für Aufgaben, die zusätzlich visuelle Updates enthalten, eignet sich requestAnimationFrame als Yield-Punkt, da der Callback exakt vor dem nächsten Rendering-Schritt ausgeführt wird. Die Batch-Größe selbst ist eine Abwägung: Zu kleine Chunks erzeugen Overhead durch häufiges Queueing, zu große Chunks nähern sich wieder der 50-Millisekunden-Schwelle an. In der Praxis hat sich ein Zeitbudget pro Chunk von 5 bis 10 Millisekunden bewährt, gemessen per performance.now() innerhalb der Schleife, statt einer festen Elementanzahl.

// Blocking main thread with a heavy synchronous loop (BAD)
function renderAllProductRows(products) {
  // This single call stack frame can run for hundreds of milliseconds
  for (let i = 0; i < products.length; i++) {
    const row = document.createElement('tr');
    row.innerHTML = buildRowMarkup(products[i]);
    productTableBody.appendChild(row);
  }
  // Nothing else can run on the main thread until this loop returns,
  // including click handlers, scroll, or the next paint
}

renderAllProductRows(largeProductList); // 20,000 rows, ~180ms Long Task

// Chunked rendering that yields the main thread between batches (GOOD)
async function renderAllProductRowsChunked(products) {
  const chunkSize = 100;
  let index = 0;

  while (index < products.length) {
    const end = Math.min(index + chunkSize, products.length);
    for (; index < end; index++) {
      const row = document.createElement('tr');
      row.innerHTML = buildRowMarkup(products[index]);
      productTableBody.appendChild(row);
    }

    // Yield back to the browser so it can paint and handle input
    if ('scheduler' in window && 'yield' in scheduler) {
      await scheduler.yield(); // modern, no 4ms clamp
    } else {
      await new Promise((resolve) => setTimeout(resolve, 0));
    }
  }
}

7. requestIdleCallback, scheduler.yield und isInputPending

requestIdleCallback plant Arbeit gezielt für Zeiträume ein, in denen der Main Thread nichts anderes zu tun hat. Der Callback erhält ein deadline-Objekt mit timeRemaining(), das die verbleibende Leerlaufzeit im aktuellen Frame angibt, typischerweise wenige Millisekunden. Die API eignet sich hervorragend für nicht-dringende Arbeit wie Prefetching oder Analytics, hat aber einen Nachteil: Bei dauerhaft ausgelastetem Main Thread kann der Callback über lange Zeit gar nicht ausgeführt werden, weshalb immer eine timeout-Option gesetzt werden sollte.

Die neuere Scheduler API mit scheduler.yield() löst das 4-Millisekunden-Throttling von verschachtelten Timern, indem sie die Fortsetzung mit hoher Priorität und ohne künstliche Verzögerung wieder einplant. Ergänzend liefert navigator.scheduling.isInputPending() eine synchrone Prüfung, ob bereits eine Nutzereingabe in der Warteschlange wartet. Innerhalb einer Chunking-Schleife lässt sich damit die Verarbeitung sofort abbrechen, sobald ein Klick ansteht, statt stur bis zum Ende des aktuellen Batches weiterzuarbeiten und die Reaktion unnötig zu verzögern.

// Demonstrates microtask queue draining before the next macrotask
console.log('1: synchronous');

setTimeout(() => console.log('4: macrotask (setTimeout)'), 0);

Promise.resolve().then(() => console.log('3: microtask (Promise.then)'));

queueMicrotask(() => console.log('3b: microtask (queueMicrotask)'));

console.log('2: synchronous');

// Actual output order:
// 1: synchronous
// 2: synchronous
// 3: microtask (Promise.then)
// 3b: microtask (queueMicrotask)
// 4: macrotask (setTimeout)

// Defer non-critical work to browser idle time
function prefetchRelatedProducts(productIds) {
  function idleStep(deadline) {
    while (deadline.timeRemaining() > 0 && productIds.length > 0) {
      const id = productIds.shift();
      fetch(`/rest/V1/products/${id}`, { priority: 'low' });
    }
    if (productIds.length > 0) {
      // Not finished in this idle period, schedule the remainder
      requestIdleCallback(idleStep, { timeout: 2000 });
    }
  }
  requestIdleCallback(idleStep, { timeout: 2000 });
}

8. Die Verbindung zu INP: Main Thread als Scheduling-Kennzahl

Interaction to Next Paint (INP) ist rein technisch betrachtet keine eigenständige Größe, sondern die Summe dreier Main-Thread-gebundener Phasen: Input Delay (Zeit bis der Event-Handler überhaupt startet), Processing Time (Laufzeit des Handlers selbst) und Presentation Delay (Zeit bis das aktualisierte Frame gemalt wird). Jede dieser drei Phasen hängt direkt davon ab, was der Main Thread zum Zeitpunkt der Interaktion gerade abarbeitet. Liegt vor dem Event-Handler bereits ein Long Task in der Task Queue, wartet die Eingabe zwangsläufig, bis dieser Task fertig ist, unabhängig davon, wie schnell der eigentliche Handler-Code wäre.

Diese Kausalkette macht INP zu einem direkten Messwert für Scheduling-Qualität, nicht zu einer isolierten Stellschraube. Ein Shop mit vielen kurzen, gut aufgeteilten Tasks hat strukturell niedrigere Input-Delay-Werte als ein Shop mit wenigen großen Tasks, selbst wenn die Gesamtmenge an JavaScript-Arbeit identisch ist. Genau deshalb wirken Chunking, scheduler.yield() und isInputPending() nicht nur gegen einzelne Long Tasks, sondern verbessern systematisch, wie oft der Main Thread überhaupt in der Lage ist, sofort auf eine Interaktion zu reagieren.

9. Long Tasks im DevTools Performance-Panel aufspüren

Das Chrome DevTools Performance-Panel ist das zuverlässigste Werkzeug, um Long Tasks konkreten Codestellen zuzuordnen. Nach einer Aufzeichnung markiert Chrome jede Aufgabe über 50 Millisekunden im Main-Thread-Track mit einem roten Dreieck in der oberen rechten Ecke des Balkens, der rote Bereich selbst zeigt den Anteil oberhalb der Schwelle. Ein Klick auf den Balken öffnet den Flame Chart darunter, der die verschachtelten Funktionsaufrufe innerhalb des Tasks zeigt, von der äußersten Funktion bis zur tiefsten, tatsächlich zeitfressenden Ebene.

Für die konkrete Ursachenanalyse eignen sich die Tabs Bottom-Up und Call Tree im unteren Panel-Bereich: Bottom-Up gruppiert nach der Funktion, die am meisten Eigenzeit verbraucht hat, unabhängig davon, wo im Stack sie aufgerufen wurde. Zusätzlich zeigt der Interactions-Track pro erfasster Nutzerinteraktion die farbliche Aufteilung in Input Delay, Processing Time und Presentation Delay, sodass sich auf einen Blick erkennen lässt, welche der drei Phasen für eine konkrete langsame Interaktion verantwortlich ist. Die CPU-Drosselung im Panel simuliert zusätzlich Mittelklasse-Mobilgeräte und deckt Long Tasks auf, die auf einem Entwickler-Laptop unsichtbar bleiben.

// Bail out of a long-running chunk early if the user is trying to interact
function processSearchIndex(entries) {
  let index = 0;

  function step() {
    const start = performance.now();
    while (index < entries.length) {
      indexEntry(entries[index]);
      index++;

      // Stop early if input is waiting, or after a 5ms budget
      if (
        (navigator.scheduling && navigator.scheduling.isInputPending()) ||
        performance.now() - start > 5
      ) {
        break;
      }
    }
    if (index < entries.length) {
      setTimeout(step, 0);
    }
  }

  step();
}

Die folgende Übersicht vergleicht typische Scheduling-Muster auf dem Main Thread und zeigt, welches Verhalten in der Praxis Reaktionsfähigkeit kostet und welche Alternative sich durchgesetzt hat.

10. Zusammenfassung

Der Main Thread und der Event Loop lösen ein Kernproblem der Browser-Architektur: JavaScript, Rendering und Nutzereingaben teilen sich einen einzigen Thread und müssen sich dessen Kapazität strikt nacheinander abwechselnd teilen. Der Call Stack führt synchronen Code nach dem Run-to-Completion-Prinzip aus, die Task Queue verwaltet Makrotasks wie setTimeout und Events, und die Microtask Queue mit Promises wird nach jedem Task vollständig geleert, bevor es weitergeht. Long Tasks ab 50 Millisekunden blockieren in dieser Struktur zwangsläufig sowohl das nächste Rendering als auch anstehende Eingaben.

Die wirksamste Gegenmaßnahme ist selten eine einzelne große Optimierung, sondern die konsequente Anwendung von Chunking, modernen Yield-Punkten wie scheduler.yield() und frühen Abbruchbedingungen über isInputPending(). INP ist dabei kein isolierter Wert, sondern die direkte messbare Konsequenz aus Input Delay, Processing Time und Presentation Delay, die alle drei am Main Thread hängen. Wer Long Tasks systematisch im DevTools Performance-Panel aufspürt und auflöst, verbessert automatisch die Reaktionsfähigkeit der gesamten Seite, nicht nur einer einzelnen Metrik.

11. FAQ: Main Thread und Event Loop