NextCloud is unacceptably slow without asset pipelining

[cdauth]

According to the docs, asset pipelining has been removed in nextCloud 10. While ownCloud/nextCloud has always been very slow, this makes nextCloud extremely slow and practically unusable even on medium-latency connections.

My network connection has ping times of about 250–300 ms to my nextCloud server. This might seem slow compared to a high-speed fiber-glass cable connection in an American metropolis, but it is quite normal for a mobile connection, and in many rural areas in the world the latency is even higher on a cable connection.

I have about 10 non-standard apps installed on my nextCloud instance, and just the front page of the Files app takes anything from 1 minute up to 5 minutes to load (with enabled browser cache)! It tells me that it had to do over 200 requests!

A good web application does 2 or 3 requests to load the page, maybe a bit more for more clever caching, if not all components are needed in all parts of the application.

nextCloud should really:

• enable asset pipelining again. If it breaks some apps, those apps should be fixed.
• use image sprites
• get rid of AJAX requests that load settings and stuff on page load, and instead put that data into the DOM

Here are two screenshots to give a rough idea about what is loading:

[nickvergessen]

I agree that we should try to combine stuff more again, but honestly with a server that takes 6 seconds to deliver a 1kb css file... what are you using it for? downloading a 1MB file will take 6k seconds which is over 1 hour? 😨

And as a sidenote: no one of us has an american-metropol-fiberglas-connection.

[cdauth]

The problem is really just the latency. Downloading a file works fine with 5–10 MBit/s.

[Guillaume99]

hello,

Use of asset pipeline have already been discussed here : https://help.nextcloud.com/t/asset-pipeline-enabled-leads-to-a-blank-calendar-with-error/1122/4 and in some other thread.

The conclusion was (more or less) : "asset pipeline is old and broken and (very likely) nothing will fix that. Don't use it."

I think that for now, your best options are HTTP/2 and maybe gzip compression of .CSS and .js ...

[MorrisJobke]

There was the idea to group JS/CSS based on the app it is loaded from. We maybe look into this once the SCSS PR is in - #1805 - cc @skjnldsv

[cdauth]

I think it is important to make a separation between minification and concatination here. In the discussion you are linking, the main argument seems to be that the JavaScript minifier is old and broken. I agree with disabling it then, as an easy solution can be that apps deploy minified JavaScript code, as mentioned in the discussion.

The issue I am facing is not related to a lack minification or compression. It is related to the fact that the browser has to send more than 200 HTTP requests to the server in order to load a page. This problem can only to a small part be solved on an app level. The HTTP standard recommends not to make more than 2 simultaneous connections to a server, and Chrome for example has a hard-coded limit of 6 (see this discussion). HTTP/2 is obviously not a practical solution right now.

If JavaScript files and CSS files (and image sprites) would simply be served concatenated, this would drastically reduce the number of requests and increase performance.

[skjnldsv]

@MorrisJobke Indeed, we could combine all the css easily.
The #2050 pr implement css compression by default.

[rullzer]

I agree we can improve here. But, havigng said that, the problem should not be that huge. Basically the first page load is painfully slow then. But after that 99% of the assets should be cached anyways.

[eppfel]

HTTP/2 is obviously not a practical solution right now.

@cdauth Maybe not right now, but... Browser support: http://caniuse.com/#feat=http2 Server adoption: http://isthewebhttp2yet.com/measurements/adoption.html

[cdauth]

@eppfel: Oh, I must admit that I thought browser support was far less advanced. I was under the impression that HTTP/2 is so far only supported by Chrome when enabling a certain flag.

Will look into it and see how much it improves things.

[eppfel]

@cdauth It's actually only supported over TLS (https). Here is a great article about it: https://www.troyhunt.com/i-wanna-go-fast-https-massive-speed-advantage/ But using nextcloud over an insecure connection is not a good idea anyway.

[cdauth]

Okay, I enabled HTTP/2 on my server and the speed improvement is tremendous.

I am undecided whether I think asset pipelining is still necessary.

I think some improvements can still be made (such as avoiding AJAX calls on page load, for example to load the config).

HTTP/2 should definitely be mentioned in the Server Tuning docs.

[eppfel]

@cdauth Lucky you, don't have that option, right now.

I think some improvements can still be made (such as avoiding AJAX calls on page load, for example to load the config).

Totally agree 👍

HTTP/2 should definitely be mentioned in the Server Tuning docs.

You could do it yourself 😉

[eppfel]

As HTTP2 is coming, asset pipeline will get obsolete. I don't know if image sprites or CSS compression would still be worth the effort, but I would advise opening dedicated issues and closing this one.
I moved @cdauth's proposal to get rid of some AJAX calls to #2447 and added documentation for HTTP2 in the documentation nextcloud/documentation#242

[ddeenniiss]

Fresh install on a new server, open Files -> it's 208 requests (!) and 6 sec to load the page ... Just crazy ...