Blazor Server vs WebAssembly vs Auto: was passt zu Ihrer Geschäftsanwendung?

Jedes Blazor-Projekt beginnt mit derselben Entscheidung, und sie geht leicht schief: Soll die Anwendung auf dem Server oder im Browser laufen? Wer falsch wählt, kauft ein Jahr später größere Server, weil jeder Nutzer Speicher belegt, oder erklärt den Nutzern, warum das erste Laden so lange dauert.

Die kurze Antwort: Seit .NET 8 wählen Sie nicht mehr einen Modus für die ganze Anwendung, sondern pro Seite. Für die meisten Geschäftsanwendungen ist die richtige Mischung einfach: einfaches serverseitiges Rendern für öffentliche Seiten, Interactive Server für interne Bildschirme und WebAssembly nur dort, wo es sich klar lohnt.

Die vier Modi in einfachen Worten

Modus	Wo der Code läuft	Was der Nutzer bekommt
Statisches serverseitiges Rendern	Auf dem Server, einmal pro Anfrage	Eine gewöhnliche schnelle HTML-Seite, Formulare funktionieren, aber ohne Live-Interaktivität
Interactive Server	Auf dem Server, über eine ständige Verbindung	Sofortiger Start, jeder Klick geht zum Server und zurück
Interactive WebAssembly	Im Browser des Nutzers	Größerer erster Download, danach läuft alles lokal, sogar offline
Interactive Auto	Erst auf dem Server, dann im Browser	Startet wie Server und wechselt bei späteren Besuchen, wenn die Dateien geladen sind, zu WebAssembly

Verglichen nach dem, was fürs Geschäft zählt

	Interactive Server	WebAssembly
Erstes Laden	Schnell	Beim ersten Mal langsamer, danach aus dem Cache
Hunderte Nutzer gleichzeitig	Kein Problem	Kein Problem
Zehntausende gleichzeitig	Braucht Planung: Speicher pro Nutzer, mehr Server oder Azure SignalR Service	Belastet den Server kaum
Schwache oder instabile Verbindung	Jeder Klick wartet aufs Netz, ein Abbruch heißt neu verbinden	Läuft lokal, nur Datenabrufe warten
Offline arbeiten	Nicht möglich	Möglich
Code und Geschäftsregeln	Bleiben auf dem Server	Werden in den Browser geladen, also darf nichts Geheimes darin stehen
Zugriff auf Datenbank und Services	Direkt	Nur über eine API
Serverkosten	Steigen mit der Zahl gleichzeitig arbeitender Nutzer	Vor allem die Kosten der API

Der entscheidende Unterschied ist nicht die Geschwindigkeit, sondern wo der Code lebt. Bei Interactive Server ruft der Bildschirm Ihre Services und die Datenbank direkt auf, und nichts verlässt den Server. Bei WebAssembly ist die Anwendung im Browser praktisch ein öffentlicher Client: Alles, was sie weiß, kann ein neugieriger Nutzer sehen, und jedes Datum muss über eine API kommen, die Berechtigungen prüft.

Die eigentliche Antwort: pro Seite

In einer Blazor Web App legt jede Seite oder Komponente ihren Modus selbst fest. Die Anwendung wird einmal, in Program.cs, für beide interaktiven Modi vorbereitet:

builder.Services.AddRazorComponents()
    .AddInteractiveServerComponents()
    .AddInteractiveWebAssemblyComponents();

app.MapRazorComponents<App>()
    .AddInteractiveServerRenderMode()
    .AddInteractiveWebAssemblyRenderMode()
    .AddAdditionalAssemblies(typeof(Client._Imports).Assembly);

Danach entscheidet eine Zeile auf der Seite:

@page "/orders"
@rendermode InteractiveServer

@page "/field/inspection"
@rendermode InteractiveWebAssembly

Eine Seite ohne @rendermode wird statisch auf dem Server gerendert, genau das, was eine öffentliche Seite oder ein einfaches Formular braucht. Komponenten, die in WebAssembly laufen, liegen in einem eigenen Client-Projekt, das die Vorlage Blazor Web App für Sie anlegt.

Eine typische Mischung für eine Geschäftsanwendung

• Öffentliche Seiten, Anmeldung, einfache Formulare: statisches serverseitiges Rendern. Schnell, gut für Google, ohne ständige Verbindung.
• Interne Bildschirme, Verwaltung, Berichte: Interactive Server. Direkter Zugriff auf Services, nichts verlässt den Server, und für einige hundert Mitarbeitende ist die Serverlast überschaubar.
• Bildschirme für die Arbeit im Außendienst oder bei schwacher Verbindung: WebAssembly. Die zusätzliche API lohnt sich nur dort, wo die Verbindung wirklich ein Problem ist.

Für eine typische interne Anwendung heißt das: Die meisten Bildschirme nutzen Interactive Server, und WebAssembly ist die Ausnahme, nicht der Standard.

Die Fallen

• Auto wirkt wie das Beste aus beiden Welten, kostet aber am meisten. Dieselbe Komponente muss auf dem Server und im Browser funktionieren, kann Services also nicht direkt aufrufen und braucht für alles eine API. Wählen Sie Auto, wenn Sie wirklich beides brauchen, nicht als sichere Voreinstellung.
• Interactive Server hält Zustand pro Nutzer. Jeder offene Tab belegt Speicher auf dem Server, bis der Nutzer geht. Komponenten, die riesige Listen in den Speicher laden, multiplizieren das mit jedem Nutzer. Wie Sie das im Griff behalten, zeigt der Artikel über langsame Blazor-Anwendungen.
• Bei WebAssembly gehört der Browser nicht Ihnen. Connection Strings, API-Schlüssel und Preisregeln dürfen nicht im Client-Projekt stehen, und jeder API-Aufruf muss die Berechtigungen auf dem Server erneut prüfen. Die vollständige Liste steht in der Blazor-Sicherheits-Checkliste.
• Prerendering lädt Daten doppelt, wenn Sie es nicht behandeln: einmal auf dem Server für das erste HTML und noch einmal, wenn die Seite interaktiv wird. In .NET 10 löst das das Attribut [PersistentState].

Fünf Fragen vor der Entscheidung

1. Wie viele Nutzer arbeiten gleichzeitig, und wo sind sie: im Büro oder im Außendienst?
2. Wie gut ist ihre Verbindung, und müssen sie offline arbeiten?
3. Braucht der Bildschirm direkten Zugriff auf Services und Datenbank, oder haben Sie schon eine API?
4. Steckt in der Logik des Bildschirms etwas, das Nutzer nicht sehen dürfen?
5. Muss die Seite bei Google gefunden werden?

Für die meisten internen Bildschirme führen die Antworten zu Interactive Server, für öffentliche Seiten zum statischen Rendern. WebAssembly gewinnt dort, wo Verbindung oder Offline-Arbeit entscheiden.

Wenn Sie noch entscheiden, ob Sie überhaupt mit Blazor bauen, lesen Sie Hat Blazor 2026 noch Zukunft? und Blazor oder React für Geschäftsanwendungen. Eine kurze Übersicht, welcher Modus zu welchem Bildschirm passt, steht auch auf der Seite Blazor.

Wie wir arbeiten

ProCoding ist ein .NET-Studio aus Split, Kroatien, und wir bringen Blazor seit 2020 in Produktion. Wir helfen Ihnen, den Modus pro Bildschirm zu wählen, bevor die erste Zeile Code entsteht, und reparieren Anwendungen, bei denen sich die Wahl als falsch erwiesen hat. Der erste Schritt ist ein kostenloses 30-minütiges Gespräch.

Quellen

• ASP.NET Core Blazor render modes, Microsoft Learn
• ASP.NET Core Blazor hosting models, Microsoft Learn
• Prerendered state persistence, Microsoft Learn
• Azure SignalR Service, Microsoft Learn