What is the value of using RenderMode.InteractiveServer?

Question

Hi;

I don't understand the value of this. And the Blazor team is smart which means this is something worth the effort. So I'd like to understand the value in it so I use it when appropriate. At present I am using (code first created in .NET 6, now using .NET 8):

<component type="typeof(HeadOutlet)" render-mode="Server" />

But now the recommended approach in .NET 8 is:

<Routes @rendermode="@RenderMode.InteractiveServer"/> 

Which I assume can be done as:

<component type="typeof(HeadOutlet)" render-mode="ServerPrerendered" />

So here's my question. When I switch to ServerPrerendered, it then calls OnInitializedAsync() twice. For a lot of my pages the performance hit is reading the appropriate data from the database. Reading the DB twice means it will take twice as long to load the page. Where's the win in this? I could see a win if there was a new OnFastInitialized() (no Async version), followed by OnInitializedAsync(). But we don't have that. So as best as I can tell, all ServerPrerendered delivers is slower page initialization. And an additional negative for ServerPrerendered - on the second call to OnInitializedAsync() all the cascading parameters are null. This is a giant problem for my code. So significant, that even if ServerPrerendered had some major advantages, I still probably could not use it. So... what is the advantage of ServerPrerendered that makes it worth the slower page load and loss of cascading parameters?

---Some more thoughts on this. Lets take my three main use cases, which I think hold for the vast majority of business apps:

1. The user's dashboard displays items relevant to them. Every user will have a different list.
2. A list of search results. This list is different for every search.
3. A page to Create, Read, or Update a complex record. The data is unique to the record requested.

For each of the above, the page is a useless empty skeleton until the data is read in. Getting that empty skeleton up quicker is of no utility. All that matters is how quickly the populated page is displayed. And as best as I can tell pre-rendering is of no help there. Am I missing something about this? In addition, for each of the above, the data is unique to the user and what parameters they selected. So there is no way to cache the data, because each page is displaying data that has likely never been selected in the previous couple of hours (or ever). Or do you mean read in pre-rendering and cache it for the final rendering? If so, how is pre-rendering of any value here? Persisting the pre-rendered state to the final rendering makes sense. I can see how that saves some time. But that doesn't answer why have a pre-render step. It merely says if you have the two steps, here's how to reduce the delay the double steps cause. But if I don't set to InteractiveServer, this issue goes away. So I'm back at my original question - if the page is worthless without the data, what is the advantage, if any, of InteractiveServer? I want to stress, I'm not trying to be difficult. A number of smart people put in a lot of time to provide this render mode. I want to understand why/when it makes sense to use it. So that I will use it when appropriate. thanks - dave

Answer 1

blazor has two main modes.

• server mode, which runs a javascript client that communicated over a signal/r to receive browser events and render the dome.
• WASM mode. the client loads a javascript app which loads a WASM blazor and then handles events and dom render of the WASM Blazor app.

as both there modes require a startup javascript app, there are an issues if you want a search engine to crawl the site. to fix this a new server pre-render mode was added to generate static pages a crawler could use. the pre-render creates the static html, but does not handle any browser events. once the javascript is rendered, the razor tree is re-created.

WASM startup can be slow, so if host is a blazor enabled host (rather than a site just hosting the WASM), then pre-render can be used to create the static html before the blazor is loaded. actually in net 8, if the WASM load is really slow, it can open a single/r connection and run in server mode until the WASM app is loaded.

to make all this as efficient as possible, a component can define itself as supporting static only, interactive WASM only, interactive Server only, or any mode (auto).

Answer 2

Hi @David Thielen ,

Advantage of ServerPrerendered：

Prerendering is the process of initially rendering page content on the server without enabling event handlers for rendered controls. The server outputs the HTML UI of the page as soon as possible in response to the initial request, which makes the app feel more responsive to users.

Besides, in Blazor server app, ServerPrerendered : Statically prerender the component along with a marker to indicate the component should later be rendered interactively by the Blazor Server app. It is a trade-off: Blazor pre-renders page and sends it as a static page, then later the page becomes an interactive Blazor server app. This behavior is intended to serve pages quickly to search engines with time-based positioning.

Calls OnInitializedAsync() twice:

In Blazor Web App 8.0 : Prerendering is enabled by default for interactive components.

You can disable prerendering for a component instance, pass the prerender flag with a value of false to the render mode: <... @rendermode="new InteractiveServerRenderMode(prerender: false)" />

Or avoid reading the DB twice, reading appropriate data from the database once during prerendering. Restore the data when the component is rerendered.

Advantage of InteractiveServer:

Blazor Web App 8.0 project template: we’ll get a Blazor app which is wired to render components statically on the server by default. If we need our components to be more interactive, we run the component in Interactive Server mode. Interactive Server mode is an easy way to enable interactivity for our app.

It’s easy to take an existing component (that is being rendered statically) and switch it to use Interactive Server. In most cases it’s simply a case of setting the rendermode attribute for the component.

Because the component is still running on the server, we don’t need to introduce a Web API for handling requests (our components can call business logic and/or connect to data directly).

As of .NET 8, Blazor server circuits are disconnected automatically when no longer needed. In this case, if we navigated to different page with no interactive server components the underlying socket connection would be disconnected after a short time, thereby reducing the load on the server. Interactive server-side rendering (interactive SSR) renders the component interactively from the server using Blazor Server. User interactions are handled over a real-time connection with the browser. The circuit connection is established when the Server component is rendered.

You can have a look at Prerender ASP.NET Core Razor components and ASP.NET Core Blazor render modes to know more.

---

If the answer is the right solution, please click "Accept Answer" and kindly upvote it. If you have extra questions about this answer, please click "Comment". Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

Best regards,

Qing Guo