Blazor in .NET 8: new render modes

Blazor, part of .NET 8, offers several rendering options that clearly affect performance and user experience. These modes determine how HTML content is generated and delivered to the user's browser. In this post, we look at the different render modes in Blazor and how they work.

First: what is rendering in Blazor? It refers to generating HTML content from Blazor components, which is then displayed in the user's browser. This process interprets Razor syntax and C# code to produce the final HTML output, together with CSS and JavaScript files.

There are several ways to render content in Blazor. Each approach fits different scenarios.

Important Blazor render modes

Prerendering

With prerendering, the HTML is fully generated on the server and sent to the user's browser. This mode improves the initial load time by providing a static snapshot of the content. It is later enhanced with interactivity once the Blazor app runs on the client via WebAssembly, or reconnects to the server via SignalR.

WebAssembly allows code to run efficiently in web browsers. It gives developers a way to execute compiled code, so performance-intensive tasks can happen directly in the browser. With Blazor, WebAssembly lets Blazor applications run fully in the browser, allowing .NET code to execute on the client side without requiring a server for every interaction.

Server-Side Rendering (Blazor Server)

HTML is rendered on the server. User interaction with the interface is sent back to the server, after which newly rendered HTML is returned to the client. The real-time connection between client and server uses SignalR.

Social media platforms rely on real-time updates and interactions, such as likes, comments and live feeds. Blazor Server's real-time communication model, supported by SignalR, can therefore fit applications that need immediate user feedback and updates without page refreshes.

Client-Side Rendering (Blazor WebAssembly)

The Blazor application and components are downloaded into the user's browser. The component logic and HTML are processed directly in the browser with WebAssembly. Client-side interactivity does not require a permanent server connection.

• Benefits: full interactivity with offline possibilities.
• Uses the computing power of the client, reducing server load.
• When to use: rich, interactive user experiences that require immediate feedback.
• When offline functionality is needed.

Interactive Server-Side Rendering Mode

This is about real-time interactivity, where the full component lifecycle, from rendering to user interaction, is managed by the server. This mode is usually used in Blazor Server applications where interactivity is crucial.

• Benefits: real-time interactivity.
• Reduces client-side requirements.
• Makes it easier to manage state and logic on the server side.
• When to use: interactive applications where keeping state on the server is useful.
• To limit resources and complexity on the client side.
• When real-time updates are essential, using the server's computing power.
• Considerations: latency on poor network connections.
• Deployment: Azure SignalR Service.

Automatic Rendering

This mode starts by rendering the page on the server for a fast load time, then switches in the background to client-side rendering via WebAssembly.

• Benefits: combines the fast initial load time of server rendering with the rich interactivity and offline possibilities of client-side rendering.
• Flexibility: automatically adapts the rendering mode to optimize performance and user experience.
• Provides a smooth transition from server to client rendering without noticeable server changes.
• When to use: a balance between server and client processing, with optimized load times and interactivity.

Interactivity type: none

Static server rendering, without a websocket connection and without a WebAssembly download. HTML is built on the server and the client receives the finished HTML. Button clicks or events are not handled.

Interactivity type: Server

Interactivity via SignalR, with a websocket connection. There is no interactivity when offline.

Interactivity type: WebAssembly

Interactivity via WebAssembly. Handlers in the code are downloaded to the user's browser. Interactivity remains possible offline.

WebAssembly Standalone App

Interactivity via WebAssembly. Handlers in the code are downloaded to the user's browser. Interactivity remains possible offline.

Interactivity type: Auto

Interactivity starts via websockets, while the wasm files are downloaded in the background. When the page is visited again, the wasm files are detected and used instead of websockets.

Deployment

Blazor Server:

• Azure App Service can require more resources because of server-side memory usage per user, roughly 50 KB to 500 KB per user.
• Example: a server with 16 GB and an average memory usage of 100 KB per user. If 5 GB is reserved for the OS and other services, 11 GB remains. Calculation: 11 GB / 100 KB per user = 110,000 supported users.
• Azure SignalR Service takes over hosting SignalR connections from the server, making the application easier to scale.
• Provides serverless connections for cost-efficient, on-demand scaling.
• Handles session stickiness automatically.
• Provides connection management and auto-reconnect features.

Conclusion

The new render modes in Blazor in .NET 8 provide flexibility and performance optimization for a wide range of applications. Whether you care about fast load times, SEO or rich interactivity, there is a rendering mode that fits the need.

Choosing the right mode can improve user experience, increase application performance and reduce server load. For static content, SSR is the right option. For highly interactive applications, client-side rendering with WebAssembly is ideal. And if you need the best of both worlds, automatic rendering offers a good balance.