Blazor WebAssembly op .NET 8, 10 en 11: we hebben downloadgrootte en opstarttijd gemeten

De eerste vraag over Blazor WebAssembly is bijna altijd dezelfde: hoeveel moet de browser downloaden voordat de gebruiker iets ziet? De cijfers die online rondgaan, stammen vaak nog uit .NET 5 of 6. Daarom hebben we het zelf gemeten, op de versies die er vandaag toe doen: .NET 8, .NET 10 en de release candidate van .NET 11.

Het korte antwoord: de standaardapplicatie haalt bij het eerste bezoek op alle drie de versies ongeveer 2,5 MB binnen en staat op een snelle machine binnen een halve seconde op het scherm. De grootte is nauwelijks veranderd. Wat in .NET 10 wel veranderde, is hoe herhaalde bezoeken worden gecachet, en dat kan u ongemerkt bij elk bezoek opnieuw de volle 2,5 MB kosten.

Hoe we hebben gemeten

We hielden het eenvoudig en herhaalbaar:

• Dezelfde applicatie: de standaardtemplate dotnet new blazorwasm, aangemaakt voor net8.0, net10.0 en net11.0 met de .NET 11 RC2 SDK.
• Een gewone release-publish: dotnet publish -c Release, zonder de optionele wasm-tools-workload, zoals veel teams publiceren.
• Geserveerd zoals een echte server dat doet: een lokale webserver die de Brotli-gecomprimeerde bestanden uit de publish-stap verstuurt.
• Gemeten in de browser: Chromium, met de tijd vanaf het begin van de navigatie tot de kop van de pagina is gerenderd, en het aantal daadwerkelijk overgedragen bytes.
• Eerste bezoek: lege cache, de mediaan van vijf metingen. Herhaald bezoek: met correcte cacheheaders, de mediaan van drie metingen.
• De machine: een laptop met een Intel Core Ultra 7 255H. Een telefoon is trager, maar het ging ons om de verschillen tussen de versies.

De resultaten

	.NET 8	.NET 10	.NET 11 RC2
Verzoeken, eerste bezoek	42	44	48
Overgedragen, eerste bezoek (Brotli)	2,47 MB	2,50 MB	2,64 MB
Tot weergave, eerste bezoek	445 ms	445 ms	453 ms
Overgedragen, herhaald bezoek	0,17 MB	0,03 MB	0,03 MB
Tot weergave, herhaald bezoek	327 ms	423 ms	419 ms

Drie dingen vallen op:

1. De grootte is stabiel. Van .NET 8 naar .NET 10 groeide het eerste bezoek met ongeveer 1 %. De release candidate van .NET 11 is in onze test ongeveer 7 % groter dan .NET 10. Microsoft noemt een kleinere WebAssembly-publish-output als een van de wijzigingen in .NET 11; we meten opnieuw met de definitieve release in november.
2. De opstarttijd is binnen de ruis gelijk. Op een snelle machine staan alle drie in ongeveer 0,45 seconde op het scherm. De verschillen van enkele tientallen milliseconden tussen metingen waren groter dan de verschillen tussen versies.
3. Herhaalde bezoeken op .NET 10 en 11 halen bijna niets binnen, ongeveer 26 KB tegenover 0,17 MB op .NET 8, maar alleen als de server de juiste cacheheaders stuurt. Daarover hieronder meer, want dat is de belangrijkste bevinding van de test.

Waaruit die 2,5 MB bestaat

Bij het eerste bezoek op .NET 10 waren dit de grootste bestanden:

Bestand	Overgedragen	Wat het is
dotnet.native.wasm	954 KB	De .NET-runtime, gecompileerd naar WebAssembly
System.Private.CoreLib.wasm	567 KB	De kernbibliotheek van .NET
icudt_EFIGS.dat	141 KB	Cultuurgegevens voor het opmaken van datums, getallen en tekst
System.Text.Json.wasm	124 KB	JSON
Microsoft.AspNetCore.Components.wasm	90 KB	Blazor zelf

Meer dan de helft van de download is de runtime plus de kernbibliotheek, die elke applicatie nodig heeft. Uw eigen code is meestal maar een klein deel. Daarom verandert de grootte ook nauwelijks tussen versies: het grootste deel is .NET zelf.

Wat het betekent op een echte verbinding

De overdracht is wat gebruikers met een tragere verbinding merken. Een ruwe berekening voor 2,5 MB:

Verbinding	Overdrachtstijd voor 2,5 MB
10 Mbit/s (zwak mobiel signaal)	ongeveer 2 seconden
50 Mbit/s (gebruikelijk op kantoor of thuis)	ongeveer 0,4 seconde
200 Mbit/s en meer	minder dan 0,1 seconde

Daar komt de tijd bij om de runtime te starten, en die kan op een telefoon een veelvoud zijn van de 0,45 seconde die we op een laptop maten. Voor een openbare landingspagina is dat veel. Voor een interne applicatie die mensen elke dag openen, gebeurt het één keer, en daarna komen de bestanden uit de cache. En daarmee zijn we bij de echte bevinding.

De bevinding die ertoe doet: caching is veranderd in .NET 10

In .NET 8 bewaarde Blazor WebAssembly een eigen kopie van de gedownloade bestanden in de Cache Storage van de browser. Zelfs als de server de browser opdroeg niets te cachen, laadde het volgende bezoek de bestanden uit de eigen cache van Blazor.

In .NET 10 heeft Microsoft die eigen cache verwijderd. Alle bestanden krijgen nu een fingerprint, een hash in de bestandsnaam, en Blazor vertrouwt op de normale HTTP-cache van de browser. Dat is netter, maar het betekent dat de cacheheaders van de server nu alles bepalen.

We zagen het direct. Met een server die no-store stuurt, zoals sommige bedrijfsproxy’s, oude IIS-configuraties of eigen hostingopstellingen doen:

Herhaald bezoek, server stuurt no-store	.NET 8	.NET 10
Verzoeken	8	44
Overgedragen	0,29 MB	2,50 MB

De .NET 8-applicatie verborg het probleem met haar eigen cache. De .NET 10-applicatie downloadde bij elk bezoek alles opnieuw. Na een upgrade van .NET 8 naar .NET 10 lijkt er niets kapot, maar gebruikers met een trage verbinding wachten opeens elke keer twee seconden langer.

Wat u na een upgrade moet controleren: de bestanden onder /_framework/ moeten met een lange cacheduur worden geserveerd, en index.html juist niet.

Als de applicatie door ASP.NET Core met MapStaticAssets wordt geserveerd, is dit al voor u geregeld: bestanden met een fingerprint krijgen een immutable-cacheheader. Bij andere hosting stelt u het zelf in. Op nginx:

location /_framework/ {
    add_header Cache-Control "public, max-age=31536000, immutable";
}

Op Azure Static Web Apps, in staticwebapp.config.json:

{
  "routes": [
    {
      "route": "/_framework/*",
      "headers": { "cache-control": "public, max-age=31536000, immutable" }
    }
  ]
}

Omdat de bestandsnamen bij elke build veranderen, is een lange cacheduur veilig: een nieuwe versie heeft gewoon nieuwe namen.

Hoe u het kleiner maakt

Als het eerste bezoek voor uw gebruikers telt, zijn dit de knoppen waaraan u kunt draaien, ruwweg op volgorde van inspanning:

• Serveer de gecomprimeerde bestanden. Brotli maakt van 7 MB aan bestanden 2,5 MB over de lijn. Controleer of uw server de .br-bestanden echt verstuurt.
• Installeer de wasm-tools-workload voordat u publiceert. De publish-stap raadt het zelf aan; het maakt native relinking mogelijk, waardoor de runtime nog kleiner kan worden. Wij maten zonder, zoals veel teams doen.
• Laad zelden gebruikte onderdelen later. Grote functies die maar door een paar gebruikers worden gebruikt, kunnen pas worden geladen wanneer ze worden geopend.
• Render het eerste scherm op de server. In een Blazor Web App kan de eerste pagina als kant-en-klare HTML van de server komen terwijl WebAssembly op de achtergrond laadt. In ons artikel over Blazor Server versus WebAssembly leest u hoe u de render modes combineert.
• Cultuurgegevens alleen weglaten waar ze niet nodig zijn. De 141 KB aan cultuurgegevens kan weg met invariant globalisation, maar dan volgen datums, getallen en sortering niet meer de taal van de gebruiker. Voor de meeste Europese bedrijfsapplicaties laat u ze staan.

Vragen die we vaak horen

Is 2,5 MB te veel?

Voor een openbare site die op een telefoon binnen een seconde open moet zijn, vaak wel, en dan is server-rendering of een lichtere frontend de betere keuze. Voor een interne of klantapplicatie achter een login, die elke dag wordt geopend, is het een eenmalige kost van een seconde of twee, waarna de applicatie uit de cache laadt.

Is WebAssembly trager dan Blazor Server?

Het eerste bezoek is trager, omdat de runtime moet worden gedownload. Daarna draait WebAssembly volledig in de browser, zonder retour naar de server bij elke klik. Wat beter is, hangt af van uw gebruikers en hun verbindingen.

Wordt het met .NET 11 kleiner?

Microsoft zegt van wel, voor de definitieve release. In onze test van de release candidate, zonder de wasm-tools-workload, was het iets groter. We werken dit artikel bij met metingen van de definitieve release.

Waarom is mijn Blazor WebAssembly-app na de download nog steeds traag?

Meestal door wat er na het opstarten gebeurt: te veel data in één keer laden, grote tabellen in één keer renderen of te veel aanroepen naar de server. Die oorzaken staan in ons artikel over waarom Blazor-apps traag worden.

Hoe wij werken

ProCoding is een .NET-studio uit Split, Kroatië, en we brengen Blazor sinds 2020 in productie. Als een Blazor-applicatie traag opent, meten we wat ze downloadt en hoe ze wordt geserveerd, repareren we hosting en caching, en kiezen we per pagina de juiste render mode. Meer over ons Blazor-werk. De eerste stap is een gratis gesprek van 30 minuten.

Bronnen

• What’s new in ASP.NET Core in .NET 10, Microsoft Learn (verwijdering van de eigen Blazor-cache)
• What’s new in ASP.NET Core in .NET 11, Microsoft Learn
• Static files and MapStaticAssets in ASP.NET Core, Microsoft Learn
• Blazor WebAssembly caching and integrity check failures, Microsoft Learn
• ASP.NET Core Blazor WebAssembly build tools and AOT compilation, Microsoft Learn
• Eigen metingen, oktober 2026, zoals hierboven beschreven