Blazor WebAssembly na .NET-u 8, 10 i 11: izmjerili smo veličinu preuzimanja i pokretanje
Izmjerili smo zadanu Blazor WebAssembly aplikaciju na .NET-u 8, 10 i 11 RC2: koliko preglednik preuzima, koliko brzo se pokreće i što se promijenilo u cacheu.
Vlado Pandžić · Osnivač · Senior .NET arhitekt
Objavljeno · 7 min čitanja
Sadržaj
Prvo pitanje o Blazor WebAssemblyju gotovo je uvijek isto: koliko preglednik mora preuzeti prije nego korisnik išta vidi? Brojke koje kruže internetom često su s .NET-a 5 ili 6. Zato smo izmjerili sami, na verzijama koje su danas važne: .NET 8, .NET 10 i kandidatu za izdanje .NET-a 11.
Kratki odgovor: zadana aplikacija pri prvom posjetu prenosi oko 2,5 MB na sve tri verzije i na zaslonu je za manje od pola sekunde na brzom računalu. Veličina se gotovo nije promijenila. Ono što se promijenilo, u .NET-u 10, jest kako se keširaju ponovni posjeti, a to vas tiho može stajati punih 2,5 MB pri svakom posjetu.
Kako smo mjerili
Držali smo se jednostavnog i ponovljivog postupka:
- Ista aplikacija: zadani predložak
dotnet new blazorwasm, napravljen zanet8.0,net10.0inet11.0sa SDK-om .NET 11 RC2. - Uobičajeni release publish:
dotnet publish -c Release, bez opcionalnogwasm-toolsworkloada, kako objavljuje mnogo timova. - Posluženo kao na pravom serveru: lokalni web server koji šalje Brotli komprimirane datoteke koje nastaju pri publishu.
- Mjereno u pregledniku: Chromium, vrijeme od početka navigacije dok se ne prikaže naslov stranice, uz brojanje stvarno prenesenih bajtova.
- Prvi posjet: prazan cache, medijan pet mjerenja. Ponovni posjet: s ispravnim cache zaglavljima, medijan tri mjerenja.
- Računalo: laptop s procesorom Intel Core Ultra 7 255H. Mobitel će biti sporiji, ali nas su zanimale razlike između verzija.
Rezultati
| .NET 8 | .NET 10 | .NET 11 RC2 | |
|---|---|---|---|
| Zahtjevi, prvi posjet | 42 | 44 | 48 |
| Preneseno, prvi posjet (Brotli) | 2,47 MB | 2,50 MB | 2,64 MB |
| Do prikaza, prvi posjet | 445 ms | 445 ms | 453 ms |
| Preneseno, ponovni posjet | 0,17 MB | 0,03 MB | 0,03 MB |
| Do prikaza, ponovni posjet | 327 ms | 423 ms | 419 ms |
Ističu se tri stvari:
- Veličina je stabilna. Od .NET-a 8 do .NET-a 10 prvi posjet narastao je za oko 1 %. Kandidat za izdanje .NET-a 11 u našem je testu oko 7 % veći od .NET-a 10. Microsoft među novostima .NET-a 11 navodi manji WebAssembly publish; izmjerit ćemo ponovno kad finalno izdanje izađe u studenom.
- Pokretanje je jednako, unutar granica šuma. Na brzom računalu sve tri verzije su na zaslonu za oko 0,45 sekundi. Razlike od nekoliko desetaka milisekundi između mjerenja bile su veće od razlika između verzija.
- Ponovni posjeti na .NET-u 10 i 11 ne prenose gotovo ništa, oko 26 KB, naspram 0,17 MB na .NET-u 8, ali samo ako server šalje ispravna cache zaglavlja. Više o tome niže, jer je to najvažniji nalaz testa.
Od čega se sastoji tih 2,5 MB
Pri prvom posjetu na .NET-u 10 najveće datoteke bile su:
| Datoteka | Preneseno | Što je to |
|---|---|---|
dotnet.native.wasm |
954 KB | .NET runtime preveden u WebAssembly |
System.Private.CoreLib.wasm |
567 KB | Osnovna .NET biblioteka |
icudt_EFIGS.dat |
141 KB | Podaci o kulturama za oblikovanje datuma, brojeva i teksta |
System.Text.Json.wasm |
124 KB | JSON |
Microsoft.AspNetCore.Components.wasm |
90 KB | Sam Blazor |
Više od pola preuzimanja čine runtime i osnovna biblioteka, koje treba svaka aplikacija. Vaš vlastiti kod obično je mali dio. Zato se veličina i ne miče puno između verzija: najveći dio je sam .NET.
Što to znači na stvarnoj vezi
Prijenos je ono što osjećaju korisnici na sporijim vezama. Gruba računica za 2,5 MB:
| Veza | Vrijeme prijenosa za 2,5 MB |
|---|---|
| 10 Mbit/s (slab mobilni signal) | oko 2 sekunde |
| 50 Mbit/s (uobičajeni ured ili dom) | oko 0,4 sekunde |
| 200 Mbit/s i više | ispod 0,1 sekunde |
Na to dolazi vrijeme pokretanja runtimea, koje na mobitelu može biti višestruko od 0,45 sekundi koje smo izmjerili na laptopu. Za javnu odredišnu stranicu to je puno. Za internu aplikaciju koju ljudi otvaraju svaki dan to se dogodi jednom, a zatim datoteke dolaze iz cachea. Što nas dovodi do pravog nalaza.
Nalaz koji je važan: keširanje se promijenilo u .NET-u 10
U .NET-u 8 Blazor WebAssembly čuvao je vlastitu kopiju preuzetih datoteka u Cache Storageu preglednika. Čak i ako je server pregledniku rekao da ništa ne kešira, sljedeći posjet učitavao je datoteke iz Blazorova vlastitog cachea.
U .NET-u 10 Microsoft je taj prilagođeni cache uklonio. Sve datoteke sada imaju otisak (fingerprint), hash u nazivu datoteke, a Blazor se oslanja na uobičajeni HTTP cache preglednika. To je čišće rješenje, ali znači da sada o svemu odlučuju cache zaglavlja servera.
To smo vidjeli izravno. Sa serverom koji šalje no-store, kao što rade neki korporativni proxyji, stare IIS konfiguracije ili prilagođena hosting rješenja:
Ponovni posjet, server šalje no-store |
.NET 8 | .NET 10 |
|---|---|---|
| Zahtjevi | 8 | 44 |
| Preneseno | 0,29 MB | 2,50 MB |
Aplikacija na .NET-u 8 skrivala je problem vlastitim cacheom. Aplikacija na .NET-u 10 preuzimala je sve iznova, pri svakom posjetu. Nakon nadogradnje s .NET-a 8 na .NET 10 ništa ne izgleda pokvareno, ali korisnici na sporim vezama odjednom svaki put čekaju dvije sekunde dulje.
Što provjeriti nakon nadogradnje: datoteke pod /_framework/ trebaju se posluživati s dugim trajanjem cachea, a index.html ne.
Ako aplikaciju poslužuje ASP.NET Core s MapStaticAssets, to je riješeno za vas: datoteke s otiskom dobivaju cache zaglavlje immutable. Na drugom hostingu postavite ga sami. Na nginxu:
location /_framework/ {
add_header Cache-Control "public, max-age=31536000, immutable";
}
Na Azure Static Web Apps, u staticwebapp.config.json:
{
"routes": [
{
"route": "/_framework/*",
"headers": { "cache-control": "public, max-age=31536000, immutable" }
}
]
}
Budući da se nazivi datoteka mijenjaju sa svakim buildom, dugo trajanje cachea je sigurno: nova verzija jednostavno ima nove nazive.
Kako je smanjiti
Ako je prvi posjet važan vašim korisnicima, ovo su poluge, otprilike redom po uloženom trudu:
- Poslužujte komprimirane datoteke. Brotli od 7 MB datoteka napravi 2,5 MB koji putuju mrežom. Provjerite šalje li vaš server zaista
.brdatoteke. - Instalirajte
wasm-toolsworkload prije publisha. Sam publish ga preporučuje; uključuje native relinking, koji može dodatno smanjiti runtime. Mi smo mjerili bez njega, kao i mnogi timovi. - Rijetko korištene dijelove učitajte kasnije. Velike funkcionalnosti koje koristi malo korisnika mogu se učitati tek kad ih netko otvori.
- Prvi zaslon renderirajte na serveru. U Blazor Web Appu prva stranica može doći sa servera kao gotov HTML dok se WebAssembly učitava u pozadini. Kako kombinirati render modove objašnjavamo u članku Blazor Server ili WebAssembly.
- Podatke o kulturama izbacite samo ako vam ne trebaju. Tih 141 KB može se ukloniti invariant globalizacijom, ali tada datumi, brojevi i sortiranje više ne prate jezik korisnika. Za većinu europskih poslovnih aplikacija zadržite ih.
Pitanja koja najčešće čujemo
Je li 2,5 MB previše?
Za javnu stranicu koja se na mobitelu mora otvoriti za sekundu često jest, i tada je bolji izbor renderiranje na serveru ili lakši frontend. Za internu ili korisničku aplikaciju iza prijave, koja se otvara svaki dan, to je jednokratni trošak od sekunde-dvije, nakon čega se aplikacija učitava iz cachea.
Je li WebAssembly sporiji od Blazor Servera?
Prvi posjet je sporiji, jer se runtime mora preuzeti. Nakon toga WebAssembly radi potpuno u pregledniku, bez odlaska na server za svaki klik. Što je bolje ovisi o vašim korisnicima i njihovim vezama.
Hoće li .NET 11 biti manji?
Microsoft tako tvrdi za finalno izdanje. U našem testu kandidata za izdanje, bez wasm-tools workloada, bio je nešto veći. Ovaj članak ažurirat ćemo mjerenjima finalnog izdanja.
Zašto je moja Blazor WebAssembly aplikacija i dalje spora nakon preuzimanja?
Obično zbog onoga što se događa nakon pokretanja: učitavanja previše podataka odjednom, velikih tablica renderiranih u jednom potezu ili previše poziva prema serveru. Ti uzroci opisani su u našem članku o tome zašto Blazor aplikacije postanu spore.
Kako mi radimo
ProCoding je .NET studio iz Splita i Blazor isporučujemo u produkciju od 2020. Kad se Blazor aplikacija sporo otvara, izmjerimo što preuzima i kako se poslužuje, popravimo hosting i keširanje te za svaku stranicu odaberemo pravi render mod. Više o našem radu s Blazorom. Prvi korak je besplatan razgovor od 30 minuta.
Izvori
- What’s new in ASP.NET Core in .NET 10, Microsoft Learn (uklanjanje prilagođenog Blazor cachea)
- 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
- Naša mjerenja, listopad 2026., opisana gore
Ovaj članak služi općem informiranju i nije pravni, porezni, financijski ni drugi stručni savjet. Scenariji, primjeri i izračuni su ilustrativni. Uvjeti korištenja i odricanje od odgovornosti.