Blazor i .NET

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ć

Vlado Pandžić · Osnivač · Senior .NET arhitekt
Objavljeno · 7 min čitanja

Sadržaj
  1. Kako smo mjerili
  2. Rezultati
  3. Od čega se sastoji tih 2,5 MB
  4. Što to znači na stvarnoj vezi
  5. Nalaz koji je važan: keširanje se promijenilo u .NET-u 10
  6. Kako je smanjiti
  7. Pitanja koja najčešće čujemo
  8. Kako mi radimo

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 za net8.0, net10.0 i net11.0 sa SDK-om .NET 11 RC2.
  • Uobičajeni release publish: dotnet publish -c Release, bez opcionalnog wasm-tools workloada, 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

Preneseni podaci i vrijeme do prikaza pri prvom posjetu, za .NET 8, .NET 10 i .NET 11 RC2

.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:

  1. 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.
  2. 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.
  3. 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 .br datoteke.
  • Instalirajte wasm-tools workload 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

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.

Povezani članci

© 2026 ProCoding — Sva prava pridržana.Impresum i privatnostUvjeti korištenjaSplit, Hrvatska