Blazor WebAssembly på .NET 8, 10 och 11: vi mätte nedladdningsstorlek och uppstartstid

Den första frågan om Blazor WebAssembly är nästan alltid densamma: hur mycket måste webbläsaren ladda ner innan användaren ser något? Siffrorna som cirkulerar på nätet kommer ofta från .NET 5 eller 6. Så vi mätte själva, på de versioner som spelar roll i dag: .NET 8, .NET 10 och release candidate för .NET 11.

Det korta svaret: standardapplikationen överför ungefär 2,5 MB vid första besöket på alla tre versionerna och syns på skärmen på under en halv sekund på en snabb dator. Storleken har knappt ändrats. Det som däremot ändrades i .NET 10 är hur upprepade besök cachas, och det kan i det tysta kosta dig hela 2,5 MB vid varje besök.

Så mätte vi

Vi höll det enkelt och upprepningsbart:

• Samma applikation: standardmallen dotnet new blazorwasm, skapad för net8.0, net10.0 och net11.0 med .NET 11 RC2 SDK.
• En vanlig release-publicering: dotnet publish -c Release, utan den valfria wasm-tools-workloaden, vilket är så många team publicerar.
• Levererad som en riktig server gör: en lokal webbserver som skickar de Brotli-komprimerade filer som publiceringssteget skapar.
• Mätt i webbläsaren: Chromium, med tiden från att navigeringen startar tills sidans rubrik har renderats, och antalet byte som faktiskt överfördes.
• Första besöket: tom cache, medianen av fem körningar. Upprepat besök: med korrekta cache-headers, medianen av tre körningar.
• Datorn: en bärbar dator med Intel Core Ultra 7 255H. En telefon är långsammare, men det var skillnaderna mellan versionerna vi var ute efter.

Resultaten

	.NET 8	.NET 10	.NET 11 RC2
Anrop, första besöket	42	44	48
Överfört, första besöket (Brotli)	2,47 MB	2,50 MB	2,64 MB
Till rendering, första besöket	445 ms	445 ms	453 ms
Överfört, upprepat besök	0,17 MB	0,03 MB	0,03 MB
Till rendering, upprepat besök	327 ms	423 ms	419 ms

Tre saker sticker ut:

1. Storleken är stabil. Från .NET 8 till .NET 10 växte första besöket med ungefär 1 %. Release candidate för .NET 11 är i vårt test ungefär 7 % större än .NET 10. Microsoft listar en mindre WebAssembly-publiceringsutdata bland ändringarna i .NET 11; vi mäter igen med den slutliga versionen i november.
2. Uppstarten är densamma inom bruset. På en snabb dator syns alla tre på skärmen på ungefär 0,45 sekunder. Skillnader på några tiotal millisekunder mellan körningar var större än skillnaderna mellan versionerna.
3. Upprepade besök på .NET 10 och 11 överför nästan ingenting, ungefär 26 KB mot 0,17 MB på .NET 8, men bara om servern skickar rätt cache-headers. Mer om det nedan, eftersom det är testets viktigaste upptäckt.

Vad de 2,5 MB består av

Vid första besöket på .NET 10 var de största filerna:

Fil	Överfört	Vad det är
dotnet.native.wasm	954 KB	.NET-runtime kompilerad till WebAssembly
System.Private.CoreLib.wasm	567 KB	.NET:s kärnbibliotek
icudt_EFIGS.dat	141 KB	Kulturdata för formatering av datum, tal och text
System.Text.Json.wasm	124 KB	JSON
Microsoft.AspNetCore.Components.wasm	90 KB	Blazor självt

Mer än hälften av nedladdningen är runtime och kärnbiblioteket, som varje applikation behöver. Din egen kod är oftast en liten del. Det är också därför storleken knappt rör sig mellan versionerna: det mesta är .NET självt.

Vad det betyder på en riktig uppkoppling

Överföringen är det som användare med långsammare uppkoppling märker. En grov beräkning för 2,5 MB:

Uppkoppling	Överföringstid för 2,5 MB
10 Mbit/s (svag mobiltäckning)	ungefär 2 sekunder
50 Mbit/s (vanligt på kontoret eller hemma)	ungefär 0,4 sekunder
200 Mbit/s och mer	under 0,1 sekunder

Till det kommer tiden att starta runtime, som på en telefon kan vara flera gånger de 0,45 sekunder vi mätte på en bärbar dator. För en publik landningssida är det mycket. För en intern applikation som folk öppnar varje dag händer det en gång, och sedan kommer filerna från cachen. Vilket för oss till den verkliga upptäckten.

Upptäckten som spelar roll: cachningen ändrades i .NET 10

I .NET 8 sparade Blazor WebAssembly en egen kopia av de nedladdade filerna i webbläsarens Cache Storage. Även om servern sa åt webbläsaren att inte cacha något, laddade nästa besök filerna från Blazors egen cache.

I .NET 10 tog Microsoft bort den egna cachen. Alla filer får nu ett fingeravtryck, en hash i filnamnet, och Blazor förlitar sig på webbläsarens vanliga HTTP-cache. Det är renare, men det betyder att serverns cache-headers nu avgör allt.

Vi såg det direkt. Med en server som skickar no-store, som vissa företagsproxyer, gamla IIS-konfigurationer eller egna hostinglösningar gör:

Upprepat besök, servern skickar no-store	.NET 8	.NET 10
Anrop	8	44
Överfört	0,29 MB	2,50 MB

.NET 8-applikationen dolde problemet med sin egen cache. .NET 10-applikationen laddade ner allt igen, vid varje besök. Efter en uppgradering från .NET 8 till .NET 10 ser ingenting trasigt ut, men användare med långsam uppkoppling får plötsligt vänta två sekunder längre varje gång.

Vad du ska kontrollera efter en uppgradering: filerna under /_framework/ ska levereras med lång cachetid, och index.html ska inte det.

Om applikationen levereras av ASP.NET Core med MapStaticAssets sköts det åt dig: filer med fingeravtryck får en immutable-cache-header. På annan hosting ställer du in det själv. På nginx:

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

På Azure Static Web Apps, i staticwebapp.config.json:

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

Eftersom filnamnen ändras vid varje build är en lång cachetid säker: en ny version har helt enkelt nya namn.

Så gör du den mindre

Om första besöket spelar roll för dina användare är det här spakarna, ungefär i ordning efter arbetsinsats:

• Leverera de komprimerade filerna. Det är Brotli som gör 7 MB filer till 2,5 MB över nätet. Kontrollera att din server faktiskt skickar .br-filerna.
• Installera wasm-tools-workloaden innan du publicerar. Publiceringssteget rekommenderar det självt; det möjliggör native relinking, som kan krympa runtime ytterligare. Vi mätte utan, som många team gör.
• Ladda sällan använda delar senare. Stora funktioner som bara ett fåtal användare använder kan laddas först när de öppnas.
• Rendera första skärmen på servern. I en Blazor Web App kan första sidan komma från servern som färdig HTML medan WebAssembly laddas i bakgrunden. Vår artikel om Blazor Server vs WebAssembly visar hur du blandar renderingslägena.
• Ta bort kulturdata bara där den inte behövs. De 141 KB kulturdata kan tas bort med invariant globalisering, men då följer datum, tal och sortering inte längre användarens språk. För de flesta europeiska affärsapplikationer bör du behålla den.

Frågor vi ofta får

Är 2,5 MB för mycket?

För en publik webbplats som ska öppnas på en sekund i en telefon, ofta ja, och då är serverrendering eller en lättare frontend ett bättre val. För en intern applikation eller kundapplikation bakom inloggning, som öppnas varje dag, är det en engångskostnad på en sekund eller två, varefter applikationen laddas från cachen.

Är WebAssembly långsammare än Blazor Server?

Första besöket är långsammare, eftersom runtime måste laddas ner. Därefter körs WebAssembly helt i webbläsaren, utan en tur till servern för varje klick. Vad som är bäst beror på dina användare och deras uppkoppling.

Blir det mindre med .NET 11?

Microsoft säger det för den slutliga versionen. I vårt test av release candidate, utan wasm-tools-workloaden, var den något större. Vi uppdaterar artikeln med mätningar av den slutliga versionen.

Varför är min Blazor WebAssembly-app fortfarande långsam efter nedladdningen?

Oftast på grund av vad som händer efter uppstarten: för mycket data som laddas på en gång, stora tabeller som renderas i ett svep eller för många anrop till servern. De orsakerna finns i vår artikel om varför Blazor-appar blir långsamma.

Så arbetar vi

ProCoding är en .NET-studio från Split i Kroatien, och vi har levererat Blazor i produktion sedan 2020. När en Blazor-applikation öppnas långsamt mäter vi vad den laddar ner och hur den levereras, åtgärdar hosting och cachning, och väljer rätt renderingsläge för varje sida. Mer om vårt Blazor-arbete. Första steget: Boka ett kostnadsfritt samtal på 30 minuter.

Källor

• What’s new in ASP.NET Core in .NET 10, Microsoft Learn (borttagningen av Blazors egen 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
• Egna mätningar, oktober 2026, enligt beskrivningen ovan