What is the value of using RenderMode.InteractiveServer"?

[DavidThielen]

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?

thanks - dave

[javiercn]

The difference is that in one case you are prerendering and in the other you aren't. The benefit of prerendering is that the content is available to the user much faster.

• In the prerendered case, the content arrives in the initial response.
• In the non-prerendered case, you first need to send a request, get a response, then start a SignalR connection (a couple of requests), then trigger the render.
  • That's likely between 2 and 4 times slower depending on the bandwidth and can be significant depending on what drives the time to render the UI on the screen.

There are strategies you can follow to avoid hitting the database twice:

• You can add a cache at the server level for the data you are using.
• You can persist the prerendered component state to avoid the double lookup.
• https://learn.microsoft.com/en-us/aspnet/core/blazor/components/prerender?view=aspnetcore-8.0#persist-prerendered-state

[DavidThielen]

@javiercn That's a good point about the low bandwidth user - I can have everything ready in 0.2 seconds, but if it's a lot of content, then they're going to have the page render slowly. Thanks for walking me through this - I know I asked lots of questions. I appreciate your guidance.

thanks - dave

[Tony20221]

@DavidThielen Having a progress bar with a skeleton page with menus and such is better than just a progress bar on a blank page which is better than a blank page with nothing on it. A progress bar that actually displays the status of remaining time is better than a dummy animated gif.

In the prerender page, you can display some text that contains some information to grab the users' attention while the page is waiting for the database data.
It can be the latest news from your department. It could be about the next downtime window for maintenance work. Some kind of announcement. Or just say the database is experiencing heavy load and the page will load in less than x seconds. The goal is to lessen the feeling of waiting.

[DavidThielen]

@Tony20221 My fundamental question was not why have 2 passes. I understood that. My question was why call OnInitializedAsync() twice. Why not instead have OnFirstPassAsync() and OnSecondPassAsync() and the first pass is everything that can be done quickly to render the static skeleton page and the second pass is everything including the DB calls.

Even after all the discussion above, I still don't understand what they didn't break this out into two distinct calls.

[Tony20221]

Is the issue you're encountering not knowing whether you're in the first run or the second run to decide when to retrieve data from the database in the OnInitializedAsync method?

[DavidThielen]

@Tony20221 Yes. So I can then not hit the DB on the first pass. And yes, there are tricks you can pull at present to figure this out (Cascading Parameter == null), but those are not guaranteed to work in future versions.