Startup is very slow

[joaquimrocha]

Describe the bug

The startup of Headlamp is very slow, especially on Windows. We should investigate why it is so slow and try speeding it up.
At the same time, we could add some techniques to make the startup perceived as faster (like a splash screen if necessary).

To Reproduce

Steps to reproduce the bug:

1. Open Headlamp from cold start on Windows -> measure how long it takes till the logo shows up in the top bar

Environment (please provide info about your environment):

• Installation type: all desktop version but especially on Windows
• Headlamp Version: 0.26.0 (but also many more before this one)

Additional Context

Let's use this section to add any sub-items related to this.

[sniok]

I've looked into the generated JS bundles and there's a LOT of code that we don't need on startup but that is loaded

Biggest chunk is the monaco editor, which should be lazy loaded
One big problem with lazy loading it is that we expose monaco editor (and others) in pluginLib so it's loaded on app load, solution here is to remove direct reexports from pluginLib and only provide lazy loaded editor react component. Same thing with recharts.

Another issue is that we're rendering popups even if they're closed.
Here's a Create/Apply popup when it's not opened

Another thing we should do is get rid of circular imports, that will allow us to lazy load our code for different routes. Currently we have a bunch of barrel files that import/export everything so splitting by lazy loading won't work

[illume]

Yeah, agree with that.

In the performance monitor you can see a big DOM node count at the beginning and then a lot that disappears.

In this PR I started to investigate some of these things... and it makes quite a big difference even without unravelling Monaco (which is the main slowdown but requires some code rearrangement gymnastics to untangle things). Splitting all the views is mainly good for seeing the size of the individual parts. There's a codemod script somewhere to automate a bunch of those changes. Didn't try it on vite to see if it has the same benefit compared to webpack... but I guess so.

• WIP: frontend: router: Add lazy loading of routes for code splitting #1961

Additionally we have the plugin performance issues to address:

• code splitting for plugins #1518
• download plugins earlier #1521
• code size for plugins #1520

It's quite easy to include a different version of an existing library and blow up the download size. I know one of the third party plugins is itself 1.5MB or so, and these issues arose from those discussions. Also, for a plugin that only renders on for example a node details page... lazy loading would help a lot. So it would be good to provide examples for those, and an "analyze" command in headlamp-plugin to help folks see what is big.

We should also probably bisect to see if there's something additional to all this because it got quite a lot worse on windows somewhere between 0.23 and 0.26 (I haven't tried more than that).

Maybe we can do some sort of loading spinner/indicator Electron side to help. I do get app-not-responding message, so that won't be sufficient... but it could probably help in the short term?

[joaquimrocha]

Yeah. Also, with the adoption we are getting, looks like we should prioritize this, to not have new users eventually pushed away.