Letztes Jahr, Fertigungsunternehmen, 180 Mitarbeitende. Die hatten eine Blazor-WASM-App gebaut – intern, von einem freien Entwickler, der .NET liebte und React hasste. Anwendungsfall: Stücklisten-Kalkulation direkt im Browser, ohne Serverrundtrip für jeden Rechenschritt. Klingt vernünftig. Funktionierte auch, bis die Stücklisten größer wurden. Ab einer gewissen Komplexität fror der Browser einfach ein. Chrome zeigte den Spinning Circle, manchmal den "Diese Seite reagiert nicht"-Dialog. Der Entwickler war zu dem Zeitpunkt längst nicht mehr im Haus.
Ich saß mit dem IT-Leiter zusammen, er fragte mich, ob man das irgendwie fixen könne. Die Antwort war: ja, aber nicht so, wie er hoffte.
Was Andrew Lock beschreibt
Andrew Lock – bekannt für seine tiefen Dives in ASP.NET-Interna – schaut sich in seinem Beitrag das neue Web-Worker-Template in .NET 11 Preview 3 an. Das Problem, das er löst, ist real: Blazor WASM läuft im Browser auf einem einzigen Thread. CPU-intensiver Code – also echte Berechnungen, kein I/O-Warten – blockiert diesen Thread, und damit friert die UI ein. Web Workers sind der Browserstandard, um Arbeit in echte Hintergrundthreads auszulagern. In .NET 8 war das schon technisch möglich, aber aufwändig. Mit .NET 11 gibt es ein eigenes Projekttemplate (dotnet new webworker), das die Boilerplate übernimmt: separates Projekt, [JSExport]-Attribute, AllowUnsafeBlocks, das ganze Setupspiel. Lock zeigt Schritt für Schritt, wie man das in eine bestehende Blazor-WASM-App integriert – sauber erklärt, technisch korrekt, mit nachvollziehbarem Code.
Das ist solides Handwerk von jemandem, der sein Handwerk versteht.
Wie das im Mittelstand wirklich landet
Zurück zur Fertigungsfirma. Was wäre die richtige Antwort gewesen? Web Workers einbauen? Nein. Die richtige Antwort war: Warum läuft das überhaupt als Blazor WASM?
Das ist die Frage, die in Andrews Artikel fehlt – und das ist kein Vorwurf, weil er keinen KMU-Beratungsartikel schreibt. Er schreibt für .NET-Entwickler, die bereits in Blazor WASM stecken und ein konkretes Problem lösen wollen. Aber wenn ich mit einem Mittelstandsbetrieb sitze und die Frage kommt "unsere WASM-App friert beim Rechnen ein" – dann ist die erste Gegenfrage: Warum habt ihr überhaupt WASM gewählt?
Blazor Server läuft auf dem Server. Dort gibt es echte Threads, echten Task-Scheduler, keine Single-Thread-Einschränkung. CPU-intensive Berechnungen sind dort kein Problem. Für 80 Prozent der internen KMU-Anwendungen – Verwaltungstools, Kalkulationen, Dateneingabe, interne Berichte – ist Blazor Server die bessere Wahl. Die typischen Gegenargumente für WASM ("offline-fähig", "kein Server-Load", "niedrigere Latenz") spielen bei Inhouse-Tools in der Praxis kaum eine Rolle. Ich kenne Mittelstandsbetriebe, die WASM gewählt haben, weil der Entwickler es spannend fand. Das ist kein guter Entscheidungsgrund.
Wenn die App schon in WASM ist und du wirklich nicht umbauen kannst oder willst – dann ist der zweite Schritt: Kann ich die CPU-Arbeit in einen API-Endpunkt verlagern? Fast immer ja. Ein HTTP-Aufruf zu einem eigenen Backend, das die Berechnung übernimmt, ist einfacher zu warten, einfacher zu testen und einfacher zu skalieren als Web-Worker-Infrastruktur im Frontend. Und du verlierst dabei nichts Wesentliches, solange du keine echte Offline-Anforderung hast.
Web Workers in Blazor WASM sind erst dann die richtige Antwort, wenn beide Fragen mit "nein" beantwortet sind: Weder Blazor Server noch ein API-Endpunkt kommen in Frage – zum Beispiel weil die App tatsächlich offline laufen muss (Feldtechnik ohne Netz, Außendienst in Funklöchern) und trotzdem CPU-intensive Arbeit lokal erledigen soll. Das ist ein realer Use Case. Aber er ist im Mittelstand selten.
Was mich an .NET 11 Preview konkret beschäftigt
Noch ein praktischer Punkt: Andrews Artikel beschreibt Preview 3. Das ist kein Produktivcode. Bis .NET 11 im November 2026 released, können sich API-Details ändern – der Artikel sagt das selbst. Trotzdem lese ich in Slack-Channels und LinkedIn-Kommentaren, wie Entwickler jetzt anfangen, Preview-Features in neue Projekte einzubauen.
Mein dringlicher Rat: Nicht.
Nicht weil Preview-Code schlecht ist, sondern weil KMU-IT-Shops oft keine Person haben, die solche Migrationen verfolgt und zeitnah anwendet. Preview-Abhängigkeiten in einem Projekt, das sechs Monate liegen bleibt – das wird zum Support-Problem. Ich habe Kunden übernommen, die auf Preview-Packages saßen und nie auf RTM migriert wurden. Das kostet echtes Geld, meistens dann, wenn der ursprüngliche Entwickler schon lange weg ist.
Wenn dich das Thema Web Workers in Blazor interessiert: Lies Andrews Artikel, versteh die Mechanik, bau einen Proof of Concept in einer Sandbox. Aber setz das nicht vor November in Produktion.
Meine konkrete Empfehlung für KMU
Drei Fragen, in dieser Reihenfolge:
1. Brauchst du wirklich Blazor WASM? Wenn nicht: Blazor Server löst das CPU-Problem ohne jede Infrastruktur-Akrobatik, und du hast keine Preview-Abhängigkeiten.
2. Kann die CPU-Arbeit ins Backend? Ein dedizierter API-Endpunkt ist einfacher, testbarer und skaliert besser als Frontend-Threads. Das ist in 90 Prozent der Fälle die richtige Antwort, auch wenn sie unspektakulär klingt.
3. Hast du eine echte Offline-Anforderung mit lokalem CPU-Bedarf? Dann ist das Web-Worker-Template in .NET 11 RTM der richtige Weg – und dann lohnt es sich wirklich, Andrews Artikel sorgfältig durchzuarbeiten.
Was ich der Fertigungsfirma empfohlen habe: Die Kalkulation per API-Endpunkt ins Backend, Blazor WASM für das UI behalten (weil der Umbau auf Server mehr Kosten verursacht hätte als der Nutzen), und einen sauberen Ladeindikator mit Timeout als Sofortmaßnahme. Gesamtaufwand: drei Tage. Das Problem war weg.
Der vollständige Original-Beitrag von Andrew Lock: Running background tasks in Blazor with Web Workers: Exploring the .NET 11 preview - Part 1
Stehst du gerade vor einer ähnlichen Entscheidung – WASM, Server, oder doch API-first? Dann ist ein kurzes Sparring oft mehr wert als ein langer Artikel.
— Bernhard