I’ve had a few thoughts about the future of Nextcloud. In the meantime, the Javascript files are no longer quite so large and with the help of caching and gzip, the download is actually quite fast.
I have now thought about whether it wouldn’t be a nice feature if you could point to a CDN within your Nextcloud, e.g. in config.php (also CDN self-hosted), where large parts of the client-side files are hosted. Of course, you would have to ensure that the files are always up to date (correct Nextcloud version, correct version for apps). But I do think that this might be a nice feature to minimize the download of your own Nextcloud or to set up Nextcloud instances that have fewer files of their own, such as apps.
Examples: The app Nextcloud Text uses 61 MB of Javascript, map, … The app Nextcloud Photos uses 40 MB of Javascript, map, …
Is this an interesting idea or is it just nonsense? Or are there already corresponding approaches?
Perhaps it would help if you run your Nextcloud on a server with extremely low bandwidth. But who runs a server with extremely low bandwidth for a file sharing application?
You expose your users to third party provider, who is using Nextcloud. They could potentially add unwanted stuff to your code, in case you handle sensitive data.
The whole setup increases in complexity, if the link with the CDN is not working, the files are not updated, … just more points of failure.
And in the end, most of the files are cached anyway.
I’m not sure about the potential to have smaller js code… If possible, I’d prefer that.
There is e.g. the https://tinyfilemanager.github.io a php file manager in one file because all e.g. jQuery JavaScript is load from CDN. And yes there are advantages and disadvantages.
I see different approaches with different aims here:
External CDN as source of auxiliary files
The idea is to upload the compressed js files of the various apps on a public hosted Server. This would allow to link the apps with these public servers and reduce the load on the actual NC server.
Pro: less files to load and cages can be used efficiently.
Contra: public servers might alter the files and tracking of private NC users might be possible.
Using of a CDN to deliver content as proxy
The idea is to use services like cloudflare to proxy the actual requests. That way, they provide something like a caching proxy service. The initialization is loaded from the original NC server over time.
Pro: faster access to static resources and few versioning issues
Contra: complicated to setup, dynamic content is not affected, NC apps need to provide correct caching information
using a private reverse caving proxy
The point by @ tflidd that there should be no low power NC instances or there, I want at least to question. At least in Germany it is rather hard to get fast upload rates with reasonable costs for private persons for residential Internet connections. However, there are quite some private users or there that use their NAS or similar to make different features available because they keep full control of the data (not trusting e.g. a hosting provider). Other reasons are that the cloud mainly provides e.g. groupware (rather small files to transmit) for global access while the files are served for internal use mainly. Different people, different reasons.
The main point: the network connection might be a bottleneck. Having a way to speed up the time until the NC main page is loaded (static files, not the XHR/Ajax based loading of the actual data) might enhance the user experience. One could think of a way to outsource these static files to a self controlled reverse proxy. That might reduce the impact of the bottleneck. This is more a question of documentation, maybe some templates, and eventually support by the apps (cache setting must be correct).
Pro: can be handled according to own need, no data is possibly leaked
Contra: specific use case, needs more configuration