I use the built in Nextcloud Office sometimes to edit calc files in the browser. The server load is very low (1-2 concurrent users…).
Unfortunately it takes quite long to open documents in the browser in Nextcloud Office, min. 2-3 seconds for an almost empty file, in the local network, no load on the server.
Is there a way to optimize that by tweaking the build in Nextcloud office? E.g. by having Nextcloud office always running in the background, so that it loads immediately if a file is opened?
I found that collabora could be configured by some coolwsd.xml file - but it seems that this configuration file is not present when the built in Nextcloud Office is used. Is there a different configuration file, or another workaround?
I really like how Nextcloud Office is integrated and updated with Nextcloud, just the startup performance is not ideal.
Maybe it is a loading and caching problem of clientside JavaScript. Can you use your browser dev tools (F12) and post some details e.g. network analysis?
I assume there is no big difference if the file is almost empty or quite big… I’m not sure there is much to optimize. Depending on your system placing both Nextcloud and Collabora binaries on an SSD might help a little… Collabora is quite huge application integrated with pretty complex protocol (see Collabora integration guide for details). I think 2-3 seconds are good already for the first document. If you open multiple docs in fast sequence latter will open faster due to OS caching I bet.
The 2-3 sec were on almost empty files, in the local LAN (PC at the same Network switch as the server).
I just tried with regular files, via the internet, there I have about 7-8 sec per file. It did not improve for following files (so I open one file, close it, open the next one - all in the same browser tab).
My Ubuntu 22.04 system and the www root are on a SSD, the Nextcloud data files are on a HDD (but that shouldn’t be the issue, opening a pdf for example is much faster).
My technical understanding of how Collabora is integrated with Nextcloud is quite basic. But my idea was that opening documents should be much faster if Collabora just runs in the background, and doesn’t not have to start from scratch with every document I want to load.
For me Nextcloud Office is still an experimental thing, unfortunately it is (in my setup) not useable as well as e.g. Google Docs was usable 5+ years ago. So for work me and my employee mostly use Libreoffice locally, and we communicate via chat who uses a shared file at the moment so that the other one closes it.
It would be “nice to have” to just open the shared file in Nextcloud office and, well, collaborate. But unfortunately Nextcloud office is still far from production use (compared to local Libreoffice or Google Docs in a browser).
I tested my installation. It runs both NC and separate CODE server as own Docker containers on old Core i7-6700 desktop PC, application and data on magnetic disk. Opening first odt file over internet took ~5 sec… next ods file was 2-3 sec. following less than 2 sec. all files are quite small so might be not the best measure.
Our .odt loading time over mobile internet within the same city:
first time: 2-3 s
second time: 1.5 s
consecutive: 1 s
Cheap Gen9 Server for 1 k€ with 100Mbit Upload.
Network through Wireguard.
Debian 12 and some custom made router/switches.
Rest installed like that: https://www.youtube.com/watch?v=r--pQtwQMv0 with a few .php changes that I deem irrelevant and a ton of RAM (8GB per user) which really does not get used as well as I would like.
I thought we were slow. I mean… less than 1s is what we always had as a deadline for customer websites. I really hope it will get faster. 1s is a lot of time, at least 60 frames of delay.
Slowness outside the internet can come through a lot of things on the hardware too. Faulty C-States, unnecessary loops running in the background (only install the bare necessities on the OS), motherboard issues, network card or cables, slow router/switch. I prefer CPUs with a high turbo rate and lower core count so that those lightweight single requests are put through faster. Always prefer newer generations of CPUs, GHz count does not really matter. Parallel SAS SSDs for {OS; System; Data} are useful to gain milliseconds.
I had it similar before “Nextcloud Office” got integrated.
But I find it now MUCH easier to maintain, when it is integrated with Nextcloud.
The only pity is that there seems to be no way to configure /finetune Collabora, you can just take it as it is.
I expected some possibility to set a “always run 2 instances in the background” in a config file, to use the installed RAM and start faster.
Well, your setup is much faster
But I think that the technology Collabora uses (run basically Libreoffice on the Server, and transmit images of the screen to the client) is a dead end.
The other approach which is used by Google Docs or Onlyoffice (server only sends data to the client, rendering happens js based in the browser) seems to be the winner.
I still like Collabora because it uses Libreoffice/open document formats, and it is well integrated with Nextcloud file sharing. But unfortunately it serves us mainly as a better preview-tool, but not as main tool to really work with data.
this might be true for a simple website. don’t forget an Office application is much more complex. I have no experience with Google Docs but I see M365 web applications daily loading slower…
I’m not sure if there are any drawbacks with native install but with my Docker setup I don’t see any issues. yes both remain two separate applications I have to maintain separately (one them - CODE is very easy - as it doesn’t host any data, doesn’t require backup etc…). but on the other side I have full control about upgrades and I know which component caused the fault after an upgrade…
separated CODE is far easier to maintain and troubleshoot. even fine-tuning the coolwsd.xml is possible e.g. to pre-load worker processes… in my case the possibility to get rid of “modern” tab UI in favor of “classic” menu is more than enough reason to use the separated CODE instance.
I didn’t dig such deep into all this applications but sending a full docs for “local” edit on the client sounds problematic for collaborative editing… I heard Google handles it well - maybe their format is easier, maybe just because they have more engineering power to address it in a good way.
…and finally for me initial load time of 2-3 sec while opening a doc is definitely not a UX killer as long the subsequent experience is good - and this is the case IMHO. in my instance multiple users can simultaneously edit the document and I see updates very fast - depending on the way of working I would even say real-time (update are visible for other user after 1-2 secs)…
well they just need to send the data to the client, a few kb maybe, if there are no big images or so in the sheet. and clients are typically powerful enough to render complex data in the browser window.
We used Google sheets 5+years ago, we preferred it to local editing, it was a really good collaborative editing experience. But we left Google apps completely for data protection reasons.
When switching to Collabora at that time it was really just a better preview tool, e.g. most of the menus/buttons etc. where missing. So there were much much less features compared to a local Libreoffice (out of the box at least).
Now with the current version of Nextcloud office that is much better, now I see menus and buttons similar to Libreoffice, so I guess features are there.
What I still don’t like are the grid lines, which are much thicker compared to my local Libreoffice (can that be changed in the docker version/config file?):
and the less-smooth scrolling compared to the local Libreoffice (in a big sheet).
I did some general optimizations at my Nextcloud server (php-fpm, http/2, double RAM, faster system SSD, Redis, high memory limits in php etc.), and I have the feeling that Nextcloud office also profited a bit from all of that, it feels a bit better now than what I remember from before.
I wouldn’t even care about a few secs if it weren’t for the end user. Some internal statistics revealed that 1-2 seconds extra in an ERP environment resulted in a significantly (>15%) less productive employee. Because the employee got used to working slower in general without the snappy flow of the software. The brain seems to seek distraction within those 1-2 secs.
Around 200ms (0.2s) seems to be the human reaction time. So from click to visual that should be a goal. When writing a document live this is still laggy (= 5Hz). Considering the current state which already is phenomenal I believe at least a constant 1s access to be very possible within the foreseeable future of Nextcloud + Collabora. I mean the offline desktop editability with LibreOffice at 60Hz and 100ms access is already reality.
Yeah, Microsoft… it’s practically my job to replace them.
but this is totally different thing. if I get you right you are talking about the continous editing which is fast IMHO. at least I don’t see significant delays once the document is ready for editing. previous discussion was about initial load of the document which happens once. in my experience editing is fast as long you have good internet connectivity (only remember issues while traveling in Marokko over very slow mobile internet).
