First page load or any subsequent refreshes always utilize Blazor Server, while booting WebAssembly in the background

[zubairkhakwani]

Is there an existing issue for this?

• I have searched the existing issues

Is your feature request related to a problem? Please describe the problem.

Currently, when using Blazor in InteractiveAuto render mode, the application starts with Blazor Server on the initial load and transitions to WebAssembly once all DLLs are loaded and cached. However, on subsequent requests, it waits for WebAssembly to start, neglecting the benefits of Blazor Server.

Describe the solution you'd like

To enhance performance and user experience, I suggest implementing a mechanism where the first page load or any subsequent refreshes always utilize Blazor Server, while booting WebAssembly in the background. This approach can mitigate concerns about WebAssembly startup performance, as we can improve it up to a certain extent.

Making this behavior configurable would provide flexibility. Users could choose to wait for WebAssembly to load when the cache is available or opt for Blazor Server on every initial request, even if WebAssembly is downloaded.

By implementing this approach, we can optimize the application's performance and provide users with a smoother transition to WebAssembly while still leveraging the benefits of Blazor Server where applicable.

Would love to hear thoughts and feedback on this proposal.

Additional context

No response

[mkArtakMSFT]

Are you expecting the execution to switch from server to WebAssembly while the component is running, or do you expect it to happen when the user navigates? Currently we don't switch from server to web assembly, because the components' state will be lost.

[zubairkhakwani]

Are you expecting the execution to switch from server to WebAssembly while the component is running, or do you expect it to happen when the user navigates? Currently we don't switch from server to web assembly, because the components' state will be lost.

Thank you for your response, @mkArtakMSFT . If the current behavior entails switching from the server to WebAssembly upon navigation, that aligns with expectations. However, I propose that this behavior should occur not only during the initial visit to the website but also for subsequent loads. Additionally, if this behavior could be made configurable, it would offer greater flexibility in managing.

[MackinnonBuck]

Additionally, if this behavior could be made configurable, it would offer greater flexibility in managing.

Could you please clarify what configuration options you're wanting? If you're asking for the ability to enable the live transition from server interactivity to WebAssembly interactivity (preserving component state), that's not something we plan to do for the time being.

[zubairkhakwani]

@MackinnonBuck

Certainly, I appreciate the opportunity to clarify.

Current behavior:
Blazor Server is utilized only for the initial page load. Subsequent visits or refreshes result in the application starts in WebAssembly, which may lead to a delay as it loads, despite being cached.

Proposal
We should be able to utilize blazor server for Subsequent visits or refreshes as well.

About Configuration
Developers should have the ability to configure the behavior I proposed. So, if someone wants to wait for WebAssembly to load when the cache is available, they should be able to. Alternatively, if they want to utilize Blazor Server for page loads, they should have that option as well.

Note
I am not proposing the ability to enable the live transition from server interactivity to WebAssembly interactivity (preserving component state).

[zubairkhakwani]

@MackinnonBuck @mkArtakMSFT Is this change going to be implemented? It is very important and will eliminate any reason to not use Blazor.

[mkArtakMSFT]

We think that the InteractiveServer render mode is what you want. The Blazor WebAssembly does have some small startup delay. We are going to optimize it as part of #54353, but there is still going to be some tiny delay remaining.

[zubairkhakwani]

@SteveSandersonMS Can you please take a look at this feature request. I am not talking about InteractiveServer render mode. I am asking about an enhancement in InteractiveServer mode. I think @SteveSandersonMS would get what I was trying to say.

[SteveSandersonMS]

@zubairkhakwani The team talked about this issue several times and I'm afraid neither I nor the others get what you're trying to say.

Developers should have the ability to configure the behavior I proposed. So, if someone wants to wait for WebAssembly to load when the cache is available, they should be able to. Alternatively, if they want to utilize Blazor Server for page loads, they should have that option as well.

You can configure this by choosing a rendermode:

• "if someone wants to wait for WebAssembly to load when the cache is available" -> Use rendermode InteractiveAuto
• "if they want to utilize Blazor Server for page loads" - Use rendermode InteractiveServer

Perhaps you mean something different from us by "page loads" but we don't know.

[zubairkhakwani]

@SteveSandersonMS Thank you for your response. I really appreciate it. let me explain it again.

in rendermode InteractiveAuto Blazor Server is used only for the first page load once WebAssembly files are downloaded. and user navigates to another page the next page will now use WebAssembly that is perfect. now when the same user is revisiting the website next day, and he opens the website webassembly cache is already there now user have to wait until webassembly is started. In this second case i am suggesting that even if WebAssembly is cached we should use blazor server for the first load to give fast interactivity and when user navigates to another page, that page should now use WASM.

I am attaching a GIF and i hope it helps in understanding my point in a better way.

I hope i am able to explain it better this time.

[lokitech]

@zubairkhakwani I've made a similiar point in this #53799 issue. I think @MackinnonBuck's reply explains the situation nicely:

....
You're definitely right that there are cases where terminating the circuit and switching to WebAssembly interactivity is worthwhile, even if it means interactive state is lost. However, that's not always going to be the right choice, because the circuit might contain additional state that isn't strictly component state (DI services, etc.) that the app author wants to persist between navigations. You do bring up a good point that navigating to a non-interactive page terminates the circuit and loses interactive state anyway. We felt that it was worth it to dispose the circuit and its state if there aren't any interactive components around to immediately utilize that state, although I can appreciate that it's somewhat subjective to draw the line there.

Perhaps #48756 would allow the configuration of some of this behavior, or we could consider another way to allow explicit configuration of what happens when:

1. The WebAssembly runtime has been completely downloaded,

2. All interactive components on the current page use Server interactivity,

3. An enhanced page update includes only `InteractiveAuto` components, and

4. It can be determined by the client that each new `InteractiveAuto` component _definitely does not_ correlate with an existing interactive component

If all these conditions are met, then we could consider terminating the circuit and allowing the InteractiveAuto render mode to resolve to WebAssembly.

[zubairkhakwani]

@lokitech Thank you for your comment. and yes I read your comment and it is what I was trying to say. Hopefully It'll get implemented. lets see