Blazor Server vs WebAssembly vs Auto: wat kiest u voor een bedrijfsapplicatie?

Elk Blazor-project begint met dezelfde beslissing, en die gaat makkelijk mis: moet de applicatie op de server draaien of in de browser? Kiest u verkeerd, dan koopt u een jaar later grotere servers omdat elke gebruiker geheugen vasthoudt, of legt u gebruikers uit waarom de eerste keer laden zo lang duurt.

Het korte antwoord: sinds .NET 8 kiest u niet meer één modus voor de hele applicatie, maar per pagina. Voor de meeste bedrijfsapplicaties is de juiste mix eenvoudig: gewone rendering op de server voor openbare pagina’s, Interactive Server voor interne schermen, en WebAssembly alleen waar het zich duidelijk terugverdient.

De vier modi in gewone woorden

Modus	Waar de code draait	Wat de gebruiker krijgt
Statische rendering op de server	Op de server, één keer per verzoek	Een gewone snelle HTML-pagina, formulieren werken, maar zonder live interactiviteit
Interactive Server	Op de server, via een vaste verbinding	Direct van start, elke klik gaat naar de server en terug
Interactive WebAssembly	In de browser van de gebruiker	Een grotere eerste download, daarna draait alles lokaal, zelfs offline
Interactive Auto	Eerst op de server, daarna in de browser	Start als Server en schakelt bij latere bezoeken, als de bestanden zijn gedownload, over op WebAssembly

Vergeleken op wat telt voor het bedrijf

	Interactive Server	WebAssembly
Eerste keer laden	Snel	De eerste keer trager, daarna uit de cache
Honderden gebruikers tegelijk	Geen probleem	Geen probleem
Tienduizenden tegelijk	Vraagt planning: geheugen per gebruiker, meer servers of Azure SignalR Service	Raakt de server nauwelijks
Zwakke of instabiele verbinding	Elke klik wacht op het netwerk, en een onderbreking betekent opnieuw verbinden	Draait lokaal, alleen dataverzoeken wachten
Offline werken	Niet mogelijk	Mogelijk
Code en bedrijfsregels	Blijven op de server	Worden naar de browser gedownload, dus er mag niets geheims in staan
Toegang tot database en services	Rechtstreeks	Alleen via een API
Serverkosten	Groeien met het aantal gebruikers dat tegelijk werkt	Vooral de kosten van de API

Het belangrijkste verschil is niet de snelheid, maar waar de code leeft. Bij Interactive Server roept het scherm uw services en de database rechtstreeks aan, en niets verlaat de server. Bij WebAssembly is de applicatie in de browser in feite een openbare client: alles wat ze weet, kan een nieuwsgierige gebruiker zien, en alle data moet via een API komen die de rechten controleert.

Het echte antwoord: per pagina

In een Blazor Web App bepaalt elke pagina of component zelf de modus. De applicatie wordt één keer, in Program.cs, voorbereid op beide interactieve modi:

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

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

Daarna beslist één regel op de pagina:

@page "/orders"
@rendermode InteractiveServer

@page "/field/inspection"
@rendermode InteractiveWebAssembly

Een pagina zonder @rendermode wordt statisch op de server gerenderd, precies wat een openbare pagina of een eenvoudig formulier nodig heeft. Componenten die in WebAssembly draaien, staan in een apart clientproject, dat de template Blazor Web App voor u aanmaakt.

Een typische mix voor een bedrijfsapplicatie

• Openbare pagina’s, inloggen, eenvoudige formulieren: statische rendering op de server. Snel, goed voor Google, zonder vaste verbinding.
• Interne schermen, beheer, rapporten: Interactive Server. Rechtstreekse toegang tot services, niets verlaat de server, en voor een paar honderd medewerkers is de serverbelasting bescheiden.
• Schermen voor werk onderweg of op zwakke verbindingen: WebAssembly. De extra API is alleen de moeite waard waar de verbinding echt een probleem is.

Voor een typische interne applicatie betekent dat: de meeste schermen gebruiken Interactive Server, en WebAssembly is de uitzondering, niet de standaard.

De valkuilen

• Auto lijkt het beste van twee werelden, maar kost het meest. Hetzelfde component moet op de server en in de browser werken, kan services dus niet rechtstreeks aanroepen en heeft voor alles een API nodig. Kies Auto als u echt beide nodig hebt, niet als veilige standaard.
• Interactive Server houdt status per gebruiker vast. Elk open tabblad houdt geheugen op de server vast tot de gebruiker vertrekt. Componenten die enorme lijsten in het geheugen laden, vermenigvuldigen dat met elke gebruiker. Hoe u dat onder controle houdt, leest u in het artikel over trage Blazor-applicaties.
• Bij WebAssembly is de browser niet van u. Connection strings, API-sleutels en prijsregels horen niet in het clientproject, en elke API-aanroep moet de rechten op de server opnieuw controleren. De volledige lijst staat in de Blazor-beveiligingschecklist.
• Prerendering laadt data twee keer als u het niet afvangt: één keer op de server voor de eerste HTML, en nog eens als de pagina interactief wordt. In .NET 10 lost het attribuut [PersistentState] dat op.

Vijf vragen voordat u beslist

1. Hoeveel gebruikers werken er tegelijk, en waar zijn ze: op kantoor of onderweg?
2. Hoe goed is hun verbinding, en moeten ze offline kunnen werken?
3. Heeft het scherm rechtstreekse toegang tot services en database nodig, of heeft u al een API?
4. Zit er in de logica van het scherm iets dat gebruikers niet mogen zien?
5. Moet de pagina op Google gevonden worden?

Voor de meeste interne schermen leiden de antwoorden naar Interactive Server, voor openbare pagina’s naar statische rendering. WebAssembly wint waar de verbinding of offline werken de doorslag geven.

Twijfelt u nog of u überhaupt in Blazor bouwt, lees dan Heeft Blazor in 2026 nog toekomst? en Blazor vs React voor bedrijfsapplicaties. Een kort overzicht van welke modus bij welk scherm past, staat ook op de pagina Blazor.

Hoe wij werken

ProCoding is een .NET-studio uit Split, Kroatië, en wij brengen Blazor sinds 2020 in productie. Wij helpen u de modus per scherm te kiezen voordat de eerste regel code er is, en repareren applicaties waarbij de keuze verkeerd bleek. De eerste stap is een gratis gesprek van 30 minuten.

Bronnen

• 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