Optimize webpack chunking

[pulsejet]

Supercedes and closes #35432

This takes a much simpler approach for achieving something similar to the linked PR. Instead of lazy loading every component, webpack directly allows only splitting components used in more than n modules. By tweaking this parameter (3 seems to have great results), we can split the chunks efficiently achieving similar performance gains. This is also much less invasive and more semantically meaningful.

Some amount of async loading is still needed since apps greedily attempt to load a lot of things.

Before	After

Files app (no cache):

Before	After
135 requests	138 requests
5.3 MB transferred	3.7 MB transferred
21.0 MB resources	12.2 MB resources
DOMContentLoaded: 4.19 s	DOMContentLoaded: 3.02 s

Files app (with cache):

Before	After
133 requests	133 requests
72.4 kB transferred	72.4 kB transferred
21.0 MB resources	12.2 MB resources
DOMContentLoaded: 2.60 s	DOMContentLoaded: 1.39 s

Memories (no cache):

Before	After
83 requests	83 requests
5.2 MB transferred	3.3 MB transferred
21.8 MB resources	12.3 MB resources
DOMContentLoaded: 3.15 s	DOMContentLoaded: 2.25 s

Video of load performance (before on top, after on bottom)
https://github.com/nextcloud/server/assets/10709794/5ab1144e-c811-4b8d-9798-463982b46cb7

[juliushaertl]

I think this is a great initiative. I'd have one concern which is due to the fact that we currently still require to have the bundles committed in the repository itself. The dynamic naming with numeric identifiers has the risk that we end up having leftover chunks in the dist folder if they are not cleaned up before each production build, so we need to double check that this is the case.

[juliushaertl]

Ok, might actually be the case already with https://github.com/nextcloud/server/blob/pulsejet/patch-webpack/webpack.common.js#L59-L61

[juliushaertl]

Eslint is not happy, otherwise this seems good from my perspective.

[marcelklehr]

Thank you @pulsejet for not giving up on this 💙

[pulsejet]

Ok, might actually be the case already with https://github.com/nextcloud/server/blob/pulsejet/patch-webpack/webpack.common.js#L59-L61

Never knew about this, but seems it'll do the trick: https://webpack.js.org/guides/output-management/#cleaning-up-the-dist-folder.

ESLint should pass now.

[pulsejet]

Just noticed something funny: this is actually also a bug fix at certain points. For instance, we explicitly want to do lazy loading (before this PR) at this line for caniuse-lite. But as is evident from the bundle, the library was present in core-common.js all along, so the lazy loading never really worked.

server/core/src/views/UnsupportedBrowser.vue

Lines 125 to 130 in fa3bbb2

	async beforeMount() {
	// Dynamic load big list of user agents
	// eslint-disable-next-line n/no-extraneous-import
	const { agents } = await import('caniuse-lite')
	this.agents = agents
	},

[pulsejet]

Short before (top) and after (bottom) video for this (warm cache for both):

prtest.mp4

[pulsejet]

Bump? I really don't understand what keeps blocking this...

[artonge]

@nextcloud/server-frontend could you review/approve ?

[kesselb]

@pulsejet rebased, compiled and force-pushed your branch. Used node 18.7 and npm 8.15 to build locally.

[pulsejet]

Thanks @kesselb. Just curious: doesn't the bot do that usually or I should be pushing compiled assets to the PR?

[skjnldsv]

Bump? I really don't understand what keeps blocking this...

27 being released and master being in feature freeze.
This is now branched-off and we can resume

[skjnldsv]

Thanks @kesselb. Just curious: doesn't the bot do that usually or I should be pushing compiled assets to the PR?

the bot needs to be called for it :)
/compile amend /

[pulsejet]

Thanks for pushing this through @skjnldsv 🎉

[major-mayer]

Now that I finally upgraded my instance to 28, I want to say thank you for this PR again @pulsejet
This increases the performance noticeably!