Blazor in .NET 10 LTS supports four render modes — Server, WebAssembly, Auto, and Static Server-Side Rendering. Choosing between them affects every dimension of your application: page-load time, runtime cost, hosting requirements, offline behavior, and scale ceiling.
Most teams pick wrong the first time. Here's the honest comparison, with hosting implications for each, based on what we deploy daily on Adaptive's Blazor hosting.
The Models, Defined
Blazor Server
Your .NET application runs on the server. The browser holds a thin shim that communicates with the server over a SignalR (WebSocket) connection. Every UI event (click, keystroke, input change) sends a message to the server; the server processes it and sends back UI diffs.
✅ Strengths: small download, fast first paint, full server-side capabilities (file access, secrets, server APIs).
⚠️ Weaknesses: every interaction is a network round-trip; requires constant WebSocket connection; latency-sensitive; server holds per-user state in memory.
Blazor WebAssembly
Your .NET application runs in the browser, compiled to WebAssembly. The browser downloads the .NET runtime (1–3 MB) plus your application DLLs (200 KB–2 MB) and runs everything client-side.
✅ Strengths: works offline; no per-user server load; scales horizontally infinitely.
⚠️ Weaknesses: large initial download; slower first paint; sensitive code can't run client-side (you still need an API for secrets, payments, sensitive queries).
Blazor Auto (.NET 8+)
The framework starts in Server mode for fast first paint, downloads WebAssembly in the background, then switches to WASM for subsequent interactions. You get both modes' strengths if your app is structured to allow it.
Static SSR
The server renders HTML once and ships it; no interactivity unless you add @rendermode InteractiveServer or @rendermode InteractiveWebAssembly to specific components.
Performance Comparison
For a moderately complex app (10–20 routes, dashboards, forms, charts):
| Metric | Blazor Server | Blazor WebAssembly | Auto | Static SSR |
|---|---|---|---|---|
| Initial download | 60 KB | 1–3 MB | 60 KB → 1–3 MB | 30 KB |
| First Contentful Paint (4G) | 0.8 s | 1.5–3 s | 0.8 s | 0.4 s |
| Time to Interactive | 1.0 s | 2.5–4 s | 1.0 s | n/a |
| Per-interaction latency | 30–80 ms | 0–10 ms | 30–80 ms → 0–10 ms | n/a |
| Offline support | No | Yes | Partial | No |
| Server memory per user | 5–20 MB | 0 MB | varies | 0 MB |
| Concurrent users per server | 5K–20K | unlimited | varies | unlimited |
When Blazor Server Wins
- LOB apps inside a corporate network — sub-10 ms latency makes interactions feel instant
- Apps with large server-side data — you don't ship a 50 MB customer database to the browser
- Apps that already have an ASP.NET Core backend — Blazor Server shares the same process
- High SEO requirement with high interactivity — server-rendered HTML for crawlers, instant interactive after JS loads
- Strict data-residency — sensitive data never leaves your server
When Blazor WebAssembly Wins
- Public-facing SaaS — scales horizontally as users add up; no server-side state to manage
- Offline-capable apps — field service, point-of-sale, anything with intermittent connectivity
- Mobile-first apps — works in PWAs, MAUI Blazor Hybrid, Capacitor wrappers
- Latency-sensitive interactions — drawing, gaming, real-time visualization
- Customer-deployed apps — you ship the app to the customer's CDN; they host the static files
When Blazor Auto Wins
- Apps with a hybrid usage pattern — short anonymous sessions (Server) + long authenticated sessions (WASM)
- Apps that need fast LCP for landing pages and rich interactivity for app pages
- Most public SaaS in 2026 — Auto is the new default for greenfield projects
When Static SSR Wins
- Content-heavy sites (docs, marketing, blog)
- E-commerce product pages (rich data, mostly read)
- Anywhere SEO and LCP dominate the metric scorecard
Hosting Requirements: The Big Difference
Blazor Server Hosting
| Requirement | Why It Matters | On Adaptive |
|---|---|---|
| WebSocket support | SignalR is the core protocol | ✅ IIS 10 on Windows Server 2022 |
| RAM for per-user state | 5–20 MB × concurrent users | ✅ 1 GB / 2 GB / 4 GB app pool by plan |
| Higher Priority Resource Scheduling | Smooth UX under load | ✅ Business and Professional plans |
| Low latency to user | Every interaction crosses wire | ✅ AWS Virginia data center |
Our Blazor Server hosting is preconfigured for all of these — IIS 10 with WebSocket modules enabled, AWS Virginia, dedicated app pools with appropriate RAM limits.
Blazor WebAssembly Hosting
| Requirement | Why It Matters | On Adaptive |
|---|---|---|
| Brotli + gzip negotiation | 15–25% smaller payloads | ✅ Yes |
| Long-cache headers on hashed assets | Returning users instant | ✅ Yes |
| HTTP/2 or HTTP/3 | Parallel asset download | ✅ HTTP/3 via Cloudflare |
SPA fallback (/* → index.html) | Deep-link routing | ✅ Yes |
| API backend | Forms, auth, data | ✅ Co-host on same plan |
Our Blazor WebAssembly hosting ships these defaults. If you co-host the API, dedicated app pools isolate the API from static file serving.
Blazor Auto / Static SSR
Both modes need server-side rendering, which means a real .NET process. Same hosting requirements as Blazor Server, plus the static-asset delivery of WASM. Our Blazor hosting plans handle all three transparently.
Scale Ceiling: The Numbers
| Mode | Practical Ceiling | Bottleneck |
|---|---|---|
| Blazor Server | ~5,000 concurrent users per IIS pool (10 MB ea, 32 GB pool) | Server RAM |
| Blazor WebAssembly | Unlimited concurrent users | API throughput for backend calls |
| Blazor Auto | Server ceiling for initial load; WASM ceiling after switch | Depends on usage pattern |
Past the Server-mode ceiling, scale out with Redis-backed SignalR backplane and sticky sessions. Our Professional plan supports this configuration.
Migration: Server → WASM (Or Auto)
If you're on Blazor Server and need to switch:
- Audit server-only dependencies —
IConfiguration, server-only DBContext, etc. These need to move behind API endpoints. - Build API surface — Minimal APIs or controllers in the same project (
@rendermodeaware). - Identify state that needs serialization — components moving from Server to WASM must have serializable parameters.
- Set up Brotli + CDN — Bundle size matters now.
- Switch render modes incrementally — Blazor Auto lets you move component-by-component without a full rewrite.
💡 Most migrations take 1–3 weeks of focused work. Our team helps with planning sessions for paid plans at no extra charge.
Real-World Numbers From Customer Apps
Two customer applications on our Blazor hosting plans, both shipped 2025:
Internal HR Portal (Blazor Server):
- 800 active users, 50 concurrent peak
- Server: Developer plan ($9.49/mo)
- Interaction latency: 45 ms median (in-office), 90 ms median (VPN)
- Uptime: 99.997% (no SLA breaches)
Public SaaS Onboarding Tool (Blazor WebAssembly):
- 50K monthly users, 200 concurrent peak
- Server: Business plan ($17.49/mo) — for the API + static delivery
- LCP: 1.2 s median (4G)
- Uptime: 99.998%
Read the full Blazor case studies for more details on customer architectures.
Frequently Asked Questions
Can I switch from Blazor Server to WebAssembly later?
Yes, but it's not trivial — server-only services need API equivalents, and state has to be serializable. Blazor Auto (added in .NET 8) eases this by letting you migrate component-by-component.
Does Blazor Server work over high-latency connections?
Acceptable up to ~100 ms RTT. Past that, every interaction feels slow. For users in distant regions, prefer WebAssembly or Auto.
How much RAM does each Blazor Server user need?
5–20 MB depending on component count and held state. Conservative estimate: 10 MB. A 4 GB app pool handles ~400 concurrent users.
Is Blazor Auto the right default for new apps?
For most public-facing apps in 2026, yes. You get fast first paint (Server) and low-latency interaction (WASM) without paying for either trade-off alone.
What hosting features does Blazor specifically need?
WebSocket support (for Server), Brotli/gzip compression (for WASM), HTTP/2 minimum, AOT-friendly IIS handlers (for WASM AOT builds), and a backend database for application state. All standard on Adaptive's Blazor plans, which include dedicated IIS application pools (1–4 GB RAM by plan), 2–10 SQL Server databases by plan (2025 or 2022), and Windows Server 2022.
If you're planning a Blazor migration, talk to our specialists about your specific render-mode mix. Or read about Blazor WebAssembly performance optimization if you've already committed to client-side.