Web Workers: Definition, Use Cases, Performance-Beispiele

Web Workers laufen JavaScript auf Background-Threads, hält Main-Thread responsive. Für heavy Compute, Parsing, Encryption, WebAssembly.

Was ist ein Web Worker?

Ein Web Worker ist ein JavaScript-Script, das auf einem separaten Thread vom Main-UI-Thread läuft, im Background. Indem Sie expensive Work (Image-Processing, Parsing, Cryptography, complex Computations) zu einem Web Worker offloaden, halten Sie den Main-Thread frei für User-Input, Animations und Rendering, was Responsiveness preserved und Core Web Vitals wie INP verbessert.

Web Workers wurden 2009 mit HTML5 eingeführt.

Typen von Web Workers

TypUse Case
Dedicated WorkerEin Worker pro Page; häufigste
Shared WorkerGeteilt über mehrere Tabs same Origin
Service WorkerNetwork-Proxy für Offline/Caching/Push
WorkletSpecialized Workers für Low-Level-Features

Basic Web-Worker-Beispiel

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

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

Was Web Workers können

  • Heavy Computation
  • Parsing large JSON/XML/CSV
  • Background-Sync
  • WebAssembly-Modules laufen lassen
  • IndexedDB, fetch, WebSocket nutzen
  • Die meisten JS-APIs außer DOM

Was Web Workers NICHT können

  • DOM zugreifen
  • window, document nutzen
  • Sync XHR nutzen
  • localStorage zugreifen

Wann Web Worker nutzen

  • Long-running Computation.
  • Real-time Data-Processing.
  • Cryptography.
  • Image/PDF-Processing.
  • Background-Fetching/Syncing.
  • WebAssembly-Modules.

Service Worker

Service Workers wirken als Proxy zwischen Browser und Network.

navigator.serviceWorker.register('/sw.js');

self.addEventListener('install', (event) => {
  event.waitUntil(
    caches.open('v1').then((cache) => cache.addAll(['/', '/styles.css']))
  );
});

Web Worker Performance-Impact

Ohne Workers blocked heavy JS-Work den Main-Thread und verursacht bad INP, janky Scrolling, frozen UI.

Web Worker Best Practices

  • Für long Tasks nutzen.
  • Message-Passing-Overhead minimieren.
  • Transferable Objects nutzen.
  • Worker-Pool für Parallelism.
  • Wenn done, terminieren.
  • Errors handeln.
  • Worker-Code bundlen.

Häufige Fallstricke

  • Huge Data in Messages senden.
  • Versuchen DOM zu zugreifen.
  • Vergessen zu terminieren.
  • Over-Engineering.
  • Worker-Startup-Cost.
  • Worker-Errors nicht handeln.
  • Sync APIs nutzen.

Web Worker Libraries

LibraryZweck
ComlinkRPC-style API über postMessage
WorkerizeWebpack-Loader
Threads.jsWorker-Pool
Vite Worker-ImportBuilt-in in Vite
WorkboxGoogle-Library für Service-Worker-Patterns

FAQ: Web Workers

Web Worker vs Service Worker?

Web Worker: General Background-JS. Service Worker: Network-Proxy.

Können Web Workers DOM zugreifen?

Nein.

Sind Web Workers langsam beim Starten?

~10-50ms zum Spawnen.

Wie share ich State zwischen Workers?

SharedArrayBuffer.

Kann ich npm-Packages im Worker nutzen?

Ja, über Bundler.

Was ist ein Worklet?

Ein specialized lightweight Worker für Low-Level-APIs.

Sind Web Workers necessary für meine App?

Nur wenn CPU-bound Work den Main-Thread blocked.

Web Worker Performance mit LoadFocus testen

LoadFocus läuft Lighthouse-Audits aus 25+ Regionen. Registrieren bei loadfocus.com/signup.

Wie schnell ist Ihre Website?

Steigern Sie ihre Geschwindigkeit und SEO nahtlos mit unserem kostenlosen Geschwindigkeitstest.

Kostenloser Websitespeed-Test

Analysieren Sie die Ladegeschwindigkeit Ihrer Website und verbessern Sie ihre Leistung mit unserem kostenlosen Seitengeschwindigkeits-Checker.

×