Blazor WebAssembly unter .NET 8, 10 und 11: Downloadgröße und Start gemessen

Die erste Frage zu Blazor WebAssembly ist fast immer dieselbe: Wie viel muss der Browser herunterladen, bevor der Nutzer überhaupt etwas sieht? Die Zahlen, die im Netz kursieren, stammen oft noch aus .NET 5 oder 6. Also haben wir selbst gemessen, und zwar mit den Versionen, die heute zählen: .NET 8, .NET 10 und dem Release Candidate von .NET 11.

Die kurze Antwort: Die Standardanwendung überträgt beim ersten Besuch auf allen drei Versionen rund 2,5 MB und steht auf einem schnellen Rechner in weniger als einer halben Sekunde auf dem Bildschirm. An der Größe hat sich kaum etwas geändert. Geändert hat sich mit .NET 10 aber, wie wiederholte Besuche zwischengespeichert werden, und das kann Sie still und leise bei jedem Besuch die vollen 2,5 MB kosten.

Wie wir gemessen haben

Wir haben den Ablauf einfach und wiederholbar gehalten:

• Dieselbe Anwendung: die Standardvorlage dotnet new blazorwasm, erstellt für net8.0, net10.0 und net11.0 mit dem .NET 11 RC2 SDK.
• Ein normaler Release-Publish: dotnet publish -c Release, ohne den optionalen wasm-tools-Workload, so wie viele Teams veröffentlichen.
• Ausgeliefert wie von einem echten Server: ein lokaler Webserver, der die Brotli-komprimierten Dateien sendet, die der Publish-Schritt erzeugt.
• Gemessen im Browser: Chromium, Zeit vom Beginn der Navigation bis zur Darstellung der Seitenüberschrift, dazu die tatsächlich übertragenen Bytes.
• Erster Besuch: leerer Cache, Median aus fünf Durchläufen. Wiederholter Besuch: mit korrekten Cache-Headern, Median aus drei Durchläufen.
• Der Rechner: ein Laptop mit Intel Core Ultra 7 255H. Ein Smartphone ist langsamer, uns ging es aber um die Unterschiede zwischen den Versionen.

Die Ergebnisse

	.NET 8	.NET 10	.NET 11 RC2
Anfragen, erster Besuch	42	44	48
Übertragen, erster Besuch (Brotli)	2,47 MB	2,50 MB	2,64 MB
Bis zur Darstellung, erster Besuch	445 ms	445 ms	453 ms
Übertragen, wiederholter Besuch	0,17 MB	0,03 MB	0,03 MB
Bis zur Darstellung, wiederholter Besuch	327 ms	423 ms	419 ms

Drei Dinge fallen auf:

1. Die Größe ist stabil. Von .NET 8 auf .NET 10 ist der erste Besuch um etwa 1 % gewachsen. Der Release Candidate von .NET 11 ist in unserem Test etwa 7 % größer als .NET 10. Microsoft nennt eine kleinere WebAssembly-Publish-Ausgabe unter den Neuerungen von .NET 11; wir messen mit dem finalen Release im November erneut.
2. Der Start ist im Rahmen der Messschwankung gleich. Auf einem schnellen Rechner stehen alle drei nach etwa 0,45 Sekunden auf dem Bildschirm. Die Unterschiede von einigen Dutzend Millisekunden zwischen einzelnen Durchläufen waren größer als die zwischen den Versionen.
3. Wiederholte Besuche übertragen unter .NET 10 und 11 fast nichts, rund 26 KB gegenüber 0,17 MB unter .NET 8, aber nur, wenn der Server die richtigen Cache-Header sendet. Mehr dazu weiter unten, denn das ist das wichtigste Ergebnis des Tests.

Woraus die 2,5 MB bestehen

Beim ersten Besuch unter .NET 10 waren das die größten Dateien:

Datei	Übertragen	Was es ist
dotnet.native.wasm	954 KB	Die .NET-Runtime, kompiliert zu WebAssembly
System.Private.CoreLib.wasm	567 KB	Die .NET-Kernbibliothek
icudt_EFIGS.dat	141 KB	Kulturdaten zur Formatierung von Datum, Zahlen und Text
System.Text.Json.wasm	124 KB	JSON
Microsoft.AspNetCore.Components.wasm	90 KB	Blazor selbst

Mehr als die Hälfte des Downloads entfällt auf die Runtime und die Kernbibliothek, die jede Anwendung braucht. Ihr eigener Code ist meist nur ein kleiner Teil. Deshalb bewegt sich die Größe zwischen den Versionen auch kaum: Den Großteil macht .NET selbst aus.

Was das auf einer echten Verbindung bedeutet

Die Übertragung ist das, was Nutzer mit langsameren Verbindungen spüren. Eine grobe Rechnung für 2,5 MB:

Verbindung	Übertragungszeit für 2,5 MB
10 Mbit/s (schwaches Mobilfunknetz)	etwa 2 Sekunden
50 Mbit/s (typisches Büro oder Zuhause)	etwa 0,4 Sekunden
200 Mbit/s und mehr	unter 0,1 Sekunden

Hinzu kommt die Zeit zum Starten der Runtime, die auf einem Smartphone ein Vielfaches der 0,45 Sekunden betragen kann, die wir auf dem Laptop gemessen haben. Für eine öffentliche Landingpage ist das viel. Bei einer internen Anwendung, die Mitarbeitende täglich öffnen, passiert es einmal, danach kommen die Dateien aus dem Cache. Und damit sind wir beim eigentlichen Ergebnis.

Das Ergebnis, auf das es ankommt: Das Caching hat sich in .NET 10 geändert

In .NET 8 hat Blazor WebAssembly eine eigene Kopie der heruntergeladenen Dateien im Cache Storage des Browsers abgelegt. Selbst wenn der Server dem Browser untersagte, etwas zwischenzuspeichern, lud der nächste Besuch die Dateien aus dem eigenen Cache von Blazor.

In .NET 10 hat Microsoft diesen eigenen Cache entfernt. Alle Dateien tragen jetzt einen Fingerprint, also einen Hash im Dateinamen, und Blazor verlässt sich auf den normalen HTTP-Cache des Browsers. Das ist sauberer, bedeutet aber, dass jetzt allein die Cache-Header des Servers entscheiden.

Das haben wir direkt gesehen. Mit einem Server, der no-store sendet, wie es manche Firmen-Proxys, ältere IIS-Konfigurationen oder individuelle Hosting-Setups tun:

Wiederholter Besuch, Server sendet no-store	.NET 8	.NET 10
Anfragen	8	44
Übertragen	0,29 MB	2,50 MB

Die .NET-8-Anwendung hat das Problem mit ihrem eigenen Cache verdeckt. Die .NET-10-Anwendung hat bei jedem Besuch alles neu heruntergeladen. Nach einem Upgrade von .NET 8 auf .NET 10 sieht nichts kaputt aus, aber Nutzer mit langsamen Verbindungen warten plötzlich jedes Mal zwei Sekunden länger.

Was Sie nach einem Upgrade prüfen sollten: Die Dateien unter /_framework/ sollten mit langer Cache-Dauer ausgeliefert werden, index.html dagegen nicht.

Wird die Anwendung von ASP.NET Core mit MapStaticAssets ausgeliefert, ist das bereits erledigt: Dateien mit Fingerprint erhalten einen immutable-Cache-Header. Bei anderem Hosting setzen Sie ihn selbst. Unter nginx:

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

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

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

Da sich die Dateinamen mit jedem Build ändern, ist eine lange Cache-Dauer unbedenklich: Eine neue Version hat einfach neue Namen.

Wie Sie die Anwendung kleiner machen

Wenn der erste Besuch für Ihre Nutzer wichtig ist, sind das die Stellschrauben, grob nach Aufwand sortiert:

• Liefern Sie die komprimierten Dateien aus. Brotli macht aus 7 MB an Dateien 2,5 MB in der Leitung. Prüfen Sie, ob Ihr Server die .br-Dateien tatsächlich sendet.
• Installieren Sie den wasm-tools-Workload vor dem Publish. Der Publish-Schritt empfiehlt ihn selbst; er aktiviert Native Relinking, das die Runtime weiter verkleinern kann. Wir haben ohne ihn gemessen, wie viele Teams.
• Laden Sie selten genutzte Teile später. Große Funktionen, die nur wenige Nutzer brauchen, lassen sich erst beim Öffnen laden.
• Rendern Sie den ersten Bildschirm auf dem Server. In einer Blazor Web App kann die erste Seite als fertiges HTML vom Server kommen, während WebAssembly im Hintergrund lädt. Wie man die Render-Modi kombiniert, zeigt unser Artikel zu Blazor Server vs. WebAssembly.
• Kulturdaten nur weglassen, wo sie nicht gebraucht werden. Die 141 KB Kulturdaten lassen sich mit invarianter Globalisierung entfernen, dann folgen Datum, Zahlen und Sortierung aber nicht mehr der Sprache des Nutzers. Für die meisten europäischen Geschäftsanwendungen sollten Sie sie behalten.

Fragen, die wir oft hören

Sind 2,5 MB zu viel?

Für eine öffentliche Website, die sich auf dem Smartphone in einer Sekunde öffnen muss, oft ja, dann ist Server-Rendering oder ein schlankeres Frontend die bessere Wahl. Für eine interne oder Kundenanwendung hinter einem Login, die täglich geöffnet wird, sind es einmalig ein bis zwei Sekunden, danach lädt die Anwendung aus dem Cache.

Ist WebAssembly langsamer als Blazor Server?

Der erste Besuch ist langsamer, weil die Runtime heruntergeladen werden muss. Danach läuft WebAssembly komplett im Browser, ohne Umweg über den Server bei jedem Klick. Was besser ist, hängt von Ihren Nutzern und deren Verbindungen ab.

Wird .NET 11 kleiner?

Microsoft sagt das für das finale Release. In unserem Test des Release Candidates ohne den wasm-tools-Workload war es etwas größer. Wir aktualisieren diesen Artikel mit Messungen des finalen Release.

Warum ist meine Blazor-WebAssembly-Anwendung nach dem Download immer noch langsam?

Meist wegen dessen, was nach dem Start passiert: zu viele Daten auf einmal laden, große Tabellen in einem Zug rendern oder zu viele Aufrufe an den Server. Diese Ursachen behandelt unser Artikel darüber, warum Blazor-Anwendungen langsam werden.

Wie wir arbeiten

ProCoding ist ein .NET-Studio aus Split in Kroatien und bringt Blazor seit 2020 in Produktion. Wenn sich eine Blazor-Anwendung langsam öffnet, messen wir, was sie herunterlädt und wie sie ausgeliefert wird, korrigieren Hosting und Caching und wählen für jede Seite den passenden Render-Modus. Mehr zu unserer Arbeit mit Blazor. Der erste Schritt ist ein kostenloses 30-minütiges Gespräch.

Quellen

• What’s new in ASP.NET Core in .NET 10, Microsoft Learn (Entfernung des eigenen Blazor-Caches)
• 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
• Eigene Messungen, Oktober 2026, wie oben beschrieben