By curiosity I checked my nextcloud instance on Google PageSpeed Insights and was a bit sad when I realized it didnt even score above 10/100 (actually got 2/100), Dropbox scores 52/100. Now I realize its hard to optimize a system like nextcloud since the data stored there should never be touched, or changed. However there are assets which could be tweaked, compressed and what not. At least thats what I think. So I want us to discuss what can be done and what cant be done here and plan a roadmap for delivering blazing fast UI.
Beat dropbox's score of course and develop ideas for how to improve speed and responsivness on the web ui.
Also related: https://github.com/nextcloud/server/pull/3385
Dealing with enabling compression – special for nginx and nextcloud documentation but maybe worth noting here: https://github.com/nextcloud/documentation/issues/325
I've updated the post to reflect the comments so far.
@benediktg I am gonna checkout that and do some benchmarks, since im running nginx aswell.
@rullzer is also working on combining vendor scripts: https://github.com/nextcloud/server/pull/3795
I added checkboxes to the ongoing items and added some more of them. 😉
Deferred script loading #4854 (13)
Will come with 13: #4854
Hi,
To complement my message on the other post I would like to suggest that some sort of HTTP2 server push is implemented on the server side.
This will allow HTTP2 enabled servers to push assets to the browser even before it fully computes index.php and requests them. Note that assets can be _preloaded_ or _prefetched_, and we can even _preconnect_ to the server to save TCP connection time.
Also, it should be quite simple to implement. In the case of the NextCloudPi web interface (quite a simple example), it amounts to one line
header("Link: </minified.js>; rel=preload; as=script;,</ncp.js>; rel=preload; as=script;,</ncp.css>; rel=preload; as=style;,</ncp-logo.png>; rel=preload; as=image;, </loading-small.gif>; rel=preload; as=image;, rel=preconnect href=ncp-launcher.php;");
, and the result on a very slow QEMU ARM instance ( gray ball means pushed )

There's some informative links at the bottom of the blog post.
Should I open a new issue for this "feature request"?