Understanding Render Modes in Blazor

With the release of .NET 8, Blazor has undergone a fundamental shift in how it handles rendering. In previous versions like .NET 7, developers were forced into a binary choice at the application's inception: commit to Blazor Server or Blazor WebAssembly. .NET 8 eliminates this constraint, introducing a unified hosting model that allows developers to mix and match render modes within the same application—even down to the component level.

This flexibility allows for significant performance optimization. For example, pages that do not require rich interactivity can now utilize Static Server-Side Rendering (SSR), functioning similarly to traditional MVC or WebForms pages, while interactive components can be selectively hydrated.

The New Interactive Render Modes

When configuring a .NET 8 Blazor project, developers can now select specific interactive render modes. These modes determine how the application handles interactivity and where the rendering logic executes.

1. None (Static SSR)

This is the default state if no interactivity is specified. The server renders the HTML and sends it to the client.

1. Behavior: No SignalR connection and no WebAssembly download.
2. Use Case: Ideal for static content, read-only dashboards, or landing pages.
3. Capabilities: Supports both static SSR and streaming rendering.

2. Interactive Server

This mode provides interactivity via a SignalR connection, similar to the traditional Blazor Server model.

1. Behavior: The component is rendered on the server, and UI updates are pushed over a WebSocket connection.
2. Pros: Fast initial load time, access to server resources.
3. Cons: Requires a constant network connection.

3. Interactive WebAssembly

This mode runs the component entirely in the browser using the .NET runtime on WebAssembly.

1. Behavior: Resources are downloaded to the client, and execution happens locally.
2. Pros: Offline capabilities, reduces server load.
3. Cons: Slower initial load time due to download size.

4. Interactive Auto (The Hybrid Approach)

Perhaps the most powerful addition in .NET 8, the Auto mode combines the best of both worlds.

1. Behavior: The component initially renders using the Server mode (ensuring instant load times) while the WebAssembly resources download in the background. On subsequent visits, it automatically switches to WebAssembly.
2. Result: Instant interactivity with the eventual benefits of client-side execution.

Configuring Interactivity: Global vs. Per-Page

NET 8 introduces the concept of Interactivity Location, allowing granular control over where these modes are applied.

Per Page/Component

By setting the location to "Per page/component," the application defaults to static behavior. You must explicitly opt-in to interactivity on specific components. This approach is highly efficient, as it keeps the "heavy lifting" of SignalR or WebAssembly strictly where it is needed.

To apply a render mode to a specific component, use the directive:

Global Interactivity

Alternatively, you can enforce a render mode globally by applying it to the root Routes component in your App.razor:

Mastering Pre-rendering

By default, interactive components in .NET 8 use Server Pre-rendering.

1. Phase 1: The server renders the component immediately as static HTML and sends it to the browser.
2. Phase 2: The interactive runtime (SignalR or WASM) spins up and "hydrates" the page.

The Pitfall: During Phase 2, the component initializes again. This often results in "double rendering," where database calls might execute twice—once for the static HTML and once for the interactive hydration.

For developers who prefer to avoid this double-execution or who want to rely solely on streaming rendering (sending data as it becomes ready), pre-rendering can be disabled. This is done by instantiating the render mode with prerender: false: