You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
NextCloud is unacceptably slow without asset pipelining #2272
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:
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.
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.
Reacted by Itay Grudev, Mathieu Tarral, Romain DEP., Arthur Darcet, karloluiten, Nicolas K., Christian Reiner, Aykut Çevik, Paulo Moura, nachoparker and 1 more
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.
Reacted by Itay Grudev, zcater, 9662, Aykut Çevik, rubenwardy and Nicolas Turlais
@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.
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
Native 12 does not include the defer mechanism, this is scheduled for 13.
You can patch your 11 or 12 instance by downloading pull 4854 as a patch: cd <base directory of nextcloud> wget https://patch-diff.githubusercontent.com/raw/nextcloud/server/pull/4854.patch
Then apply the downloaded patch file to your instance: patch -p1 < 4854.patch
Reacted by btk999, Benedikt Geißler, aronovgj, rrrnld and Stefan Brenner
Thank you very much for this work. I'm still on NC11 and this makes a big difference. FYI 4854 doesn't apply cleanly on NC11 as a few lines in the layout.{base,guest,user}.php are in a different order. Easy to fix by hand though.
I guess the best option, for who can, is to hop and upgrade to NC12 ASAP. If I understand correctly NC12 includes JS combine work. If this is applied on top of it the benefit should be even bigger.
Everyone, thanks for working on this. It is indeed needed to improve loading times.
Maybe many of you are on powerful computers or VPS, but just imagine being on lower end hardware, such as a Raspberry Pi. Think NextCloudPi/Nextcloudbox
From NextCloudPi, we are going steady for 1000~2000 downloads a day, which means at least hundreds of people trying Nextcloud everyday on SBCs. I get many complaints on how slow it is and I can tell that really puts people off. Many decide to stay with Dropbox for this reason.
This screenshot was taken from a NextCloudPi instance on a Raspberry Pi 2 after logging out and logging in again, so browser cache, PHP7, PHP cache, HTTP2 pipelining... and all the stuff
I am glad to see movement on the right direction. This is just to make you guys aware of this user base that you might not be aware you have.
Good work, and please, don't forget users on low end devices!
edit: I know its a 35$ board, but as someone mentions before, it is quite capable of serving dynamic pages, and I've seen it load faster on PHP5 + owncloud than it does now, so the design can be improved (it is being improved already it seems)
Hey nachoparker. I didn't know the existence of your project (Nextcloudpi). I installed first owncloud and now nextcloud in my pi2 first and now in my pi3. I suppose that are a lot of people that install nextcloud in this machines for a single use. The server is cheap and the power consuption is very low.
For a perfect personal pi server i think that the project need a mail server. I installed iredmail to make the pi a full server, but i love the simplicity of mail-in-a-box. Please, consider this in future relases.
And yes... when the assets were enabled in previous versions, owncloud was very much faster that now in this machines. I think that this might be solved as soon as possible (is a know error and very evident to forget it).
i applied 4854.patch to my nextcloud 12.0.0, but this makes updating to 12.0.1 impossible.
How can i remove the patch or is there an updated version that works with 12.0.1?
i applied 4854.patch to my nextcloud 12.0.0, but this makes updating to 12.0.1 impossible.
How can i remove the patch or is there an updated version that works with 12.0.1?
I removed the patch file in the NC directory and the update went well. I guess you'll have to reapply the patch after update though.
Sorry to resume this old thread. This is also not a direct issue of Nextcloud, but it's related. Just want to point out I think HTTP/2 is not really an option at the moment. I've tried with nginx and found it's not ready. HTTP/2 large downloads will simply deadlock. This is not a fault of nextcloud, it's the same with static files if they are big enough (>10 MB can be enough, but it's easier to see with > 100 MB or more).
Apache httpd works, but connection multiplexing doesn't work as I expected. When downloading a large file it's not possible to navigate nextcloud pages. I think (but am not sure at all) this is due to connection multiplexing in HTTP/2, which is done kind of incorrectly in this case. The new requested seems to wait for the big download to finish, but it's supposed to happen concurrently.
Could you please move this discussion to the forum or (if there's a bug) to a new issue? Everyone in this thread will be notified by your comments although it's been fixed. Thanks.
Activity
nickvergessen commentedon Nov 23, 2016
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 commentedon Nov 23, 2016
The problem is really just the latency. Downloading a file works fine with 5–10 MBit/s.
Guillaume99 commentedon Nov 23, 2016
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 commentedon Nov 23, 2016
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 commentedon Nov 23, 2016
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 commentedon Nov 23, 2016
@MorrisJobke Indeed, we could combine all the css easily.
The #2050 pr implement css compression by default.
rullzer commentedon Nov 23, 2016
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 commentedon Nov 23, 2016
@cdauth Maybe not right now, but... Browser support: http://caniuse.com/#feat=http2 Server adoption: http://isthewebhttp2yet.com/measurements/adoption.html
cdauth commentedon Nov 24, 2016
@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 commentedon Nov 24, 2016
@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 commentedon Nov 27, 2016
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 commentedon Nov 27, 2016
@cdauth Lucky you, don't have that option, right now.
Totally agree 👍
You could do it yourself 😉
eppfel commentedon Dec 1, 2016
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 commentedon Dec 7, 2016
Fresh install on a new server, open Files -> it's 208 requests (!) and 6 sec to load the page ... Just crazy ...
95 remaining items
HolgerHees commentedon May 23, 2017
just update to nextcloud 12 and everything works fine.
michaelletzgus commentedon May 23, 2017
Native 12 does not include the
defermechanism, this is scheduled for 13.You can patch your 11 or 12 instance by downloading pull 4854 as a patch:
cd <base directory of nextcloud>wget https://patch-diff.githubusercontent.com/raw/nextcloud/server/pull/4854.patchThen apply the downloaded patch file to your instance:
patch -p1 < 4854.patchenricotagliavini commentedon May 31, 2017
Thank you very much for this work. I'm still on NC11 and this makes a big difference. FYI 4854 doesn't apply cleanly on NC11 as a few lines in the layout.{base,guest,user}.php are in a different order. Easy to fix by hand though.
I guess the best option, for who can, is to hop and upgrade to NC12 ASAP. If I understand correctly NC12 includes JS combine work. If this is applied on top of it the benefit should be even bigger.
benediktg commentedon May 31, 2017
nachoparker commentedon Jul 26, 2017
Everyone, thanks for working on this. It is indeed needed to improve loading times.
Maybe many of you are on powerful computers or VPS, but just imagine being on lower end hardware, such as a Raspberry Pi. Think NextCloudPi/Nextcloudbox
From NextCloudPi, we are going steady for 1000~2000 downloads a day, which means at least hundreds of people trying Nextcloud everyday on SBCs. I get many complaints on how slow it is and I can tell that really puts people off. Many decide to stay with Dropbox for this reason.
This screenshot was taken from a NextCloudPi instance on a Raspberry Pi 2 after logging out and logging in again, so browser cache, PHP7, PHP cache, HTTP2 pipelining... and all the stuff
I develop and test on a QEMU ARM virtualized system... just imagine the pain x_x
I am glad to see movement on the right direction. This is just to make you guys aware of this user base that you might not be aware you have.
Good work, and please, don't forget users on low end devices!
edit: I know its a 35$ board, but as someone mentions before, it is quite capable of serving dynamic pages, and I've seen it load faster on PHP5 + owncloud than it does now, so the design can be improved (it is being improved already it seems)
marcosmatas commentedon Aug 9, 2017
Hey nachoparker. I didn't know the existence of your project (Nextcloudpi). I installed first owncloud and now nextcloud in my pi2 first and now in my pi3. I suppose that are a lot of people that install nextcloud in this machines for a single use. The server is cheap and the power consuption is very low.
For a perfect personal pi server i think that the project need a mail server. I installed iredmail to make the pi a full server, but i love the simplicity of mail-in-a-box. Please, consider this in future relases.
And yes... when the assets were enabled in previous versions, owncloud was very much faster that now in this machines. I think that this might be solved as soon as possible (is a know error and very evident to forget it).
nachoparker commentedon Aug 9, 2017
Nice suggestions! I also want to add email self hosting to the whole thing, but haven't even started investigating.
Would you like to open a feature request / discussion here?
btk999 commentedon Aug 12, 2017
Hi guys,
i applied 4854.patch to my nextcloud 12.0.0, but this makes updating to 12.0.1 impossible.
How can i remove the patch or is there an updated version that works with 12.0.1?
aronovgj commentedon Aug 12, 2017
I removed the patch file in the NC directory and the update went well. I guess you'll have to reapply the patch after update though.
enricotagliavini commentedon Oct 23, 2017
Sorry to resume this old thread. This is also not a direct issue of Nextcloud, but it's related. Just want to point out I think HTTP/2 is not really an option at the moment. I've tried with nginx and found it's not ready. HTTP/2 large downloads will simply deadlock. This is not a fault of nextcloud, it's the same with static files if they are big enough (>10 MB can be enough, but it's easier to see with > 100 MB or more).
Apache httpd works, but connection multiplexing doesn't work as I expected. When downloading a large file it's not possible to navigate nextcloud pages. I think (but am not sure at all) this is due to connection multiplexing in HTTP/2, which is done kind of incorrectly in this case. The new requested seems to wait for the big download to finish, but it's supposed to happen concurrently.
benediktg commentedon Oct 23, 2017
@enricotagliavini Downloading a 112 MB file worked pretty fine here (with nginx 1.13 and HTTP/2).
nachoparker commentedon Oct 23, 2017
I have been using HTTP2 apache for many months, and it seems very much ready from here :P
enricotagliavini commentedon Oct 23, 2017
@nachoparker so you can download a 10 GB file while surfing to other nextcloud pages at the same time? Which version of apache httpd if I may ask?
ChristophWurst commentedon Oct 23, 2017
Could you please move this discussion to the forum or (if there's a bug) to a new issue? Everyone in this thread will be notified by your comments although it's been fixed. Thanks.