Setting User Preferences is called synchronously on page load multiple times and causes page load delays

[ghost]

Setup 2.7.0

Describe the bug We spend nearly 500ms on every page load and route change synchronously setting the "setLastVisited" user preference and in fact every time we mutate user preferences which is often multiple times per page load. Here's a network timeline filtered to just calls to "userpreferences". Part of the problem is that there's no watcher to subscribe to for userpreferences so we've got to make a full GET request to get the latest preferences for the user prior to any mutation to make sure we're not backing out any change made in another browser or another tab (average looks like 250ms) but then we still have to make our PUT call which average 250ms as well (the two calls you see that stretch into the +500ms range are actually 250ish but they've stalled out waiting for other requests to finish).

To Reproduce Open developer tools, select the network tab and filter to userpreferences. Login and navigate to any page, notice that userpreferences is called multiple times per page at a time cost of nearly 250ms every time. There's unfortunately no way to know that these calls are blocking other parts of the UI from loading without examining code because we also make several other blocking API calls.

Result

Expected Result When fixed, there should be anywhere from 0.5 seconds to 1.5 seconds average page load reduction depending on which page, which other requests are being fired simultaneously, network conditions, and machine specs but there should be a measurable if slight (potentially more than slight) reduction in page load times.

Screenshots

[richard-cox]

Neil has reduce the frequency we need to save preferences. We should also try to optimise the save process. For example can we avoid fetching preferences and instead handle conflict errors on save?

[gaktive]

We should have something asynchronous so that when a change is made, it can save when it can (like a write-through cache).

[gaktive]

However, this may have been addressed via other performance work so we should do an assessment first to see what the current timing is like, then figure out what else to do.

[richard-cox]

Low priority, can be bumped.

Possible solution, local cache that wouldn't block and is synced independently.

Accessed via ui new api, some could be preferences in local storage, some rancher userpreferences