Web Workers: Definition, Einsatzfälle, Beispiele

Was ist ein Web Worker?

Ein Web Worker ist eine JavaScript-Datei, die der Browser in einem Hintergrund-Thread ausführt, getrennt vom Haupt-Thread, der Rendering und Nutzereingaben übernimmt. MDN beschreibt ihn als Möglichkeit, Skripte in Hintergrund-Threads laufen zu lassen, ohne die Benutzeroberfläche zu stören. Wer schwere Arbeit dorthin verlagert, hält die Seite reaktionsfähig, was Kennzahlen wie Interaction to Next Paint (INP) zugutekommt.

Wie Web Workers funktionieren

Die Seite erzeugt einen Worker mit new Worker("worker.js"). Beide Seiten teilen keine Variablen: Sie kommunizieren über postMessage und empfangen Nachrichten im message-Event. Ein Worker hat keinen Zugriff auf das DOM oder die Objekte der Seite und kann daher nicht verändern, was der Nutzer sieht. Er schickt Ergebnisse zurück, und der Haupt-Thread aktualisiert die Seite.

// main.js
const worker = new Worker('worker.js');
worker.postMessage({ rows: largeArray });
worker.addEventListener('message', (event) => {
  console.log('Result:', event.data);
});

// worker.js
self.addEventListener('message', (event) => {
  const result = expensiveCompute(event.data.rows);
  self.postMessage(result);
});

Arten von Workern

Was ein Worker kann und was nicht

Worker können fetch, WebSockets, IndexedDB und Timer nutzen und Skripte mit importScripts() laden. Sie können das DOM nicht manipulieren und Teile von window nicht verwenden; nutzen Sie stattdessen self. localStorage ist eine Window-Funktion und steht in Workern nicht zur Verfügung, speichern Sie dort mit IndexedDB. Prüfen Sie den MDN-Leitfaden zu Web Workers und die Liste der verfügbaren Funktionen, bevor Sie sich auf eine API verlassen.

Wann sich ein Web Worker lohnt

• Lange Tasks. Ein Task, der länger als 50 ms auf dem Haupt-Thread läuft, gilt laut web.dev als Long Task. Arbeit, die diese Grenze regelmäßig überschreitet, ist ein Kandidat.
• Parsen und Umwandeln großer Daten, etwa großer JSON-, CSV- oder XML-Dateien.
• Kryptografie und Hashing, die sonst die Oberfläche einfrieren würden.
• Bild-, Audio- und Dokumentverarbeitung, etwa Skalieren, Komprimieren oder OCR.
• Hintergrund-Abrufe und -Synchronisierung, während der Nutzer weiterarbeitet.

Daten effizient übergeben

Nachrichten werden standardmäßig per Structured Clone kopiert. Bei großen Datenmengen ist diese Kopie der eigentliche Aufwand. Übertragbare Objekte wie ein ArrayBuffer wechseln per Zero-Copy-Transfer die Seite, das Original ist danach unbrauchbar:

const bytes = new Uint8Array(1024 * 1024 * 32);
worker.postMessage(bytes.buffer, [bytes.buffer]);

Ein SharedArrayBuffer lässt Threads denselben Speicher nutzen, doch MDN verweist auf Bedenken bei Determinismus, Sicherheit und Leistung. Greifen Sie nur dazu, wenn Sie es brauchen. Ist ein Worker fertig, stoppt worker.terminate() vom Haupt-Thread aus ihn sofort.

Beispiel: ein ruckelnder CSV-Import

Ein Dashboard parst eine große CSV, sobald der Nutzer sie auf die Seite zieht. Auf dem Haupt-Thread friert die Seite sekundenlang ein, Klicks stauen sich und der INP-Wert ist schlecht. Verlagern Sie den Parser in einen Worker und schicken geparste Blöcke zurück, bleibt die Oberfläche beweglich und Sie können eine Fortschrittsanzeige zeigen. Das Parsen dauert gleich lang, aber der Nutzer kann währenddessen weiter arbeiten.

Häufige Fehler

• Riesige Objekte wiederholt senden. Das Klonen kostet Zeit und Speicher. Übertragen Sie Buffer oder senden Sie kleinere Blöcke.
• Vom Worker aus das DOM anfassen. Das wirft einen Fehler. Senden Sie Daten zurück und aktualisieren Sie die Seite im Haupt-Thread.
• Pro Klick einen Worker erzeugen. Der Start kostet. Verwenden Sie einen Worker oder einen kleinen Pool wieder.
• Das Beenden vergessen. Ungenutzte Worker halten Speicher. Rufen Sie terminate() auf oder lassen Sie den Worker sich selbst schließen.
• Einen Worker für winzige Tasks einbauen. Unterhalb der Long-Task-Schwelle übersteigt der Nachrichtenaufwand meist den Nutzen.
• Fehler ignorieren. Lauschen Sie auf das error-Event des Workers, sonst bleiben Ausfälle unbemerkt.

Web Workers, Performance-Tests und Monitoring

Worker helfen der Reaktionsfähigkeit im Frontend, also messen Sie sie. web.dev beschreibt Total Blocking Time (TBT) als Labormetrik, die oft mit einem niedrigen INP einhergeht, und empfiehlt unter 200 ms auf durchschnittlicher Mobilhardware. INP selbst ist eine Feldmetrik: web.dev bewertet 200 ms oder weniger am 75. Perzentil als gut. Das Page-Speed-Monitoring von LoadFocus führt Lighthouse von mehreren Standorten aus, sodass Sie Laborwerte im Zeitverlauf beobachten, und der kostenlose Core-Web-Vitals-Checker zeigt den INP echter Nutzer aus Chrome-UX-Report-Daten, ohne Anmeldung. Mehr Kontext bieten Core Web Vitals und Mastering JavaScript for Performance (auf Englisch). Lasttests dagegen belasten Ihre Server; Blockaden des Haupt-Threads im Browser zeigen sie nicht.

Häufige Fragen zu Web Workern

Was ist der Unterschied zwischen Web Worker und Service Worker?

Ein Web Worker führt allgemeines JavaScript im Hintergrund für eine Seite aus. Ein Service Worker sitzt zwischen Seite und Netzwerk und übernimmt Caching, Offline-Nutzung, Push und Hintergrundsynchronisierung.

Kann ein Web Worker auf das DOM zugreifen?

Nein. Worker laufen in einem eigenen Kontext ohne DOM. Sie senden Ergebnisse mit postMessage, und der Haupt-Thread aktualisiert die Seite.

Macht ein Web Worker Code schneller?

Nicht von selbst. Die Berechnung dauert etwa gleich lang, blockiert aber die Oberfläche nicht mehr. Wird die Arbeit auf mehrere Worker verteilt, kann sie auf Mehrkerngeräten auch früher fertig sein.

Wie teilen Worker Daten?

Per Nachrichtenaustausch, der Daten kopiert, durch Übertragen von Objekten wie einem ArrayBuffer oder mit einem SharedArrayBuffer, wenn dessen Sicherheitsanforderungen erfüllt sind.

Brauche ich einen Web Worker für meine App?

Nur wenn rechenintensive Arbeit den Haupt-Thread blockiert. Die meisten Seiten brauchen keinen; wer einen braucht, gewinnt spürbar an Reaktionsfähigkeit.