For repeatedly-used elements, cache JSON definitions in the browser

[evnchn]

So, the NiceGUI site felt more sluggish, after the navigation hierarchy was introduced in #4732

To visualize, the yellow region is the data which is served exclusively for rendering the sidebar and the hierarchy:

(Search {"id":" to show this)

By my count, it accounts for 30% of the page's content data. Not a negligible amount.

I wonder if it is possible to cache the below in the browser to avoid retransmission. Point 1 is specific while point 2 is more generic

1. For the nodes list passed into ui.tree, can we cache it? (potentially for other elements which expect one big option, like ui.aggrid, and that remains mostly constant from load to load)
2. For elements, we know there is a JSON representation in the _to_dict. Provided that the element is exactly the same between page visits (or at least you can render a constant element, and then make modifications to it later after the client has connected), can we cache that?

[evnchn]

Wishful API endpoints:

/_nicegui/2.xx.0/cached_data/sidebar_hierarchy would return the nodes data, for which we can simplify the JSON representation of the sidebar ui.tree's nodes data to:

{"tag":"q-tree","class":["w-full"],"props":{"filter":null,"nodes":{"__nicegui_fetch_from_cached_data":"sidebar_hierarchy"}...

/_nicegui/2.xx.0/cached_elements/sidebar would return the element data, for which we can simplify the JSON representation of the entire sidebar to:

{"__nicegui_fetch_from_cached_elements":"sidebar"}

In both cases, the endpoint is not hit for data, if it is found in localStorage. However, in the case of developers changing the definition, we'd still ask the endpoint for the hash of the content after the page has loaded, just so that the next page load can reflect the correct content (similar to Cache-Control stale-while-revalidate behaviour, we can adjust this if needed)

Points to note:

• Event handlers are associated with a unique UUID. We need to attach those later / give up using them for cached elements.
• For cases where we need to serve mostly-the-same but slightly-different element, we need to work from a base element, and then make modifications on top (like hiding or changing the text)

[evnchn]

Actually there is no need to ask the server again.

The browser can include the cached components that it have + the hash of it somewhere in the request (cookies I'd imagine) and the server can act accordingly, serving placeholders if browser have + it is up-to-date, or the actual content if not.

[falkoschindler]

Interesting observation, @evnchn. But I'm not sure how this can work in general.

Anyway, when looking into the network traffic to see what amount of data we're talking about (~30KB), I noticed that search_index.json is around twice as large (66KB) and isn't cached at the moment:

Even though this is not the point of this feature request, there might be lower hanging fruits for reducing traffic.

[evnchn]

Well that sucks. I think it's a good low-hanging fruit to fix. That must have contributed to a lot of wasted bandwidth for the fly.io hosting. I'll see how I can address it in another PR (separate to this one)

But I want to emphasize: The observation of a (perceived, and so may be false) sluggishness is merely an introduction to the possible technique that I am about to pitch, and is not indicative of a genuine effort to squeeze performance.

P.S.: Given my experience in hosting NiceGUI against single-digit-megabit uplink and very high latency, I think that if I do embark on optimizing the NiceGUI documentation, I'd be at there all day, with a risk the codebase becoming very fragile. As the gains may be minor since NiceGUI documentation website have a very good hosting backbone, I'm not embarking at all.

[evnchn]

There we go. #4795

[evnchn]

Also got #4796