[BUG] Interactive/Auto - Users Experience Long Delays Logging Into Oqtane With Interactive/Auto Versus Interactive/Server Site UI Component Settings.

[thabaum]

Issue

Description

Logging into and out of Oqtane seems to come with longer delays I don't think where experienced before.

Steps to reproduce

1. Set to Interactive/Auto UI Component Mode as shown in screenshot below using the 5.1.0 latest dev branch to experience this issue while logging in.
2. Log out.
3. Login and wait for the page to load to notice the different behaviors while changing between Interactive/Server and Interactive/Auto and repeating these steps with the two UI component modes in Site Settings.

Note:
Log out and wait for next page to load. (long period to logout is with all render modes and can be logged as an enhancement to potentially review down the road)

Additional Context

• Interactive/Server seems faster at logon. Logging in using Interactive/Auto should be as fast as it is for Interactive/Server mode.
• The logout takes time for all modes. So logging out has the expected behavior for now as maybe this experience can be improved all around.
• Interactive Static has the best experience for logging into the app. It has the quickest feeling response time.

I noticed below are my settings in screenshot. Interactive/Auto

I switched to Interactive/Server and Static/Server and Login was quick, but logout same experience.

Maybe a spinner/loading feature can be added here?

Maybe 2 issues here to review:

1. Interactive/Auto should be as snappy as logging in with other the UI component modes.
2. Logging out should be just as quick as logging in.

This could be an IDE issue as well, not sure but Static/Server seems to be working very well.

Screenshots

[sbwalker]

If you have interactivity set to Auto it essentially means you are using WebAssembly. This means that the browser needs to download the DLLs to the browser to run the app. When you login or logout it initiates a server-side web request to set the auth cookies - which means that the browser initiates the download of the DLLs again. This is the reason for the delay.

[thabaum]

Just wondering if maybe there should be a spinner if it is expected. I figured in Auto mode the components would be set to auto mode and give a server load first and load the web assembly in the background. So you should not really see much of a performance loss.

[thabaum]

#4064 may produce a bit different behavior here. It seems to log out now takes less than a blink of an eye or better, but logging in takes time still. It should run server then web assembly, so everything should be as fast as server as well.

[thabaum]

With #4064 now included the issue is now limited to only logging in. it is a background color screen waiting for something to happen for a few seconds. This should run as fast as Interactive Server, not slower. And once loaded as a dll this is even faster feeling experience as the UI for the app and things like page assets that do not change can maintain this information in the client browser. Blazor then just updates what elements on the page change or something to that degree... plus a lot more... Forgive me for my own layman terms and ways to visualize what is going on here. I am sure I can use some clarification in areas related.

To close this issue we need to find out why we are not getting the Interactive/Server type of login user experience. It should not load web assembly, it should load from the server now and then load web assembly in the background. The experience should be better, not worse. At worst should only take a blink of an eye with no load on the server (IDE).

I am still reviewing things as I go through different testing situations and hopefully along the way one of us can discover the solution second half of this issue, logging into Oqtane Interactive/Auto UI Component Mode.

[sbwalker]

@thabaum note that #4059 is related to the behavior of Auto mode as well

[thabaum]

@sbwalker thanks I will review.

[sbwalker]

@thabaum note that I am not going to hold up the release of 5.1 for this item as it only affects 1 very specific configuration

[thabaum]

@sbwalker from what I can tell switching through pages in interactive/auto mode runs GREAT when not clicking logon or logout UI controls.

[thabaum]

@sbwalker A few more notes:

• Interactive/Server seems faster at logon. Logging in using Interactive/Auto should be as fast as it is for Interactive/Server mode.
• The logout takes time for all modes. So logging out has the expected behavior for now as maybe this experience can be improved all around.
• Interactive Static has the best experience for logging into the app. It has the quickest feeling response time.

[sbwalker]

@thabaum with the StreamRendering removed can you test to determine if this issue is still valid?

[thabaum]

@sbwalker I did test and it is still an issue.

[thabaum]

@sbwalker The difference in modes can be seen when you use F12 developer tools in the browser and look at the network requests total on the network tab. It is over 53 when in Interactive/Auto vs about 19 in Interactive/Server. It really looks like maybe duplicate requests possibly. Log out and back in to see the differences in the different render modes. You can also notice the page requests to the HTML modules on the page. Issue is page should load on the first request and seems like it is held up until the final double request takes place.

This could all be expected with one being for server and the other webassembly but something worth a review.

[sbwalker]

@thabaum note that when you are running Interactive/Server the Html/Text module is loading the module content directly from the server (because it is running on the server) - whereas on Interactive/Auto the Html/Text module is first loading the module content on the server (ie. pre-rendering) and then reloading the content on the client using HttpClient API calls.

[thabaum]

@sbwalker When stream rendering attribute is commented out of the app and components I have experienced the site going blank (black) while testing this (switching between the three interactive modes Server/Client/Auto). I have had this happen more than once so I wanted to make a note of it see if anyone else experiences it. This could just be a Visual Studio issue with Oqtane switching modes frequently.

On another note: In Static/Auto mode it is handling 24 requests on a login, blink of an eye fast UI experience. Interactive/Client was over 70+.. Static/Server is the least at 17 logging into Oqtane with the home page as the return url.

[sbwalker]

@thabaum is this still an issue with .NET SDK 8.0.4 - it seems like a lot of .NET 8 bugs have now been resolved in the recent SDK patch releases

[thabaum]

@sbwalker Yes, the Interactive/Server vs Interactive/Auto Login UI control button/action differences in redirected page lag time issue still exists in the latest dev branch Oqtane Framework along with the latest .NET and Visual Studio updates.

System Info:

The Logout button action is the only place I notice this redirected page load time delay. Fast in Server mode, very very slow in Auto mode, similar to logging in which has almost the same delay.

Keeping on the Home page, fresh installation, using host account page results:

---

Interactive/Auto Logout:

Interactive/Auto Login:

---

Interactive/Server Login:

Interactive/Server Logout:

These screenshots of results should show there is a difference in Login/Logout actions from Home page load times.

[thabaum]

@sbwalker While switching between the default site template pages there is also an awful HTML content load time noticed between the time you see the Title of the HTML module and the HTML module Content while in Interactive/Auto. The title and content for the HTML module should be blink of an eye same time you would think without any noticeable delays. Seems like it requests a lot of the same authentication information for each piece of the HTML module component resulting in a lot of repeated requests.

I was wondering if it had a different ID instead of 1, 2, 3 in order of loading, something more unique it would remove this effect? Maybe authmoduleId=1ModuleTitle would work so that the DOM knows this is something unique and if it does not exist anymore on a page render then don't put any information there updating its content if/when this information is available. Module Title can be shortened but long enough to ensure it will most likely be unique. Something of this nature that gives each module a more unique way to identify each module and if the content will be the same or not.

Maybe this issue is expected behavior, or should another issue be logged? Just thought I would mention it since it relates to Interactive/Auto and maybe a clue to the issue here to the extra delay.

[sbwalker]

@thabaum I think the problems with Auto mode are not related to Oqtane, but rather with how it was implemented in Blazor. Based on all of the issues I have seen logged in the Blazor repo, it does not appear to work as described in the marketing propaganda from Microsoft. I think it was most likely tested on the default Blazor app template which has no services or data access and therefore does not represent a real world app scenario. At this point I would recommend using Server or Client for Interactivity, as both of these hosting models have been proven over many years of usage. When using Client it is important to note that HttpClient is used for all interaction with the server - therefore there will be higher latency than when you are running Server (which performs data access directly on the server). In addition, when running in Interactive render mode, prerendering is enabled by default which means that data access is usually occurring twice (once during prerendering and again during component rendering). You can turn off Prerendering in Site Settings and it will eliminate 50% of the data access (but also means that your content would not be indexable by search engines).