Operating system and version (e.g., Ubuntu 24.04):
Ubuntu 24.04
Web server and version (e.g, Apache 2.4.25):
AIO
Reverse proxy and version _(e.g. nginx 1.27.2)
AIO
PHP version (e.g, 8.3):
AIO
Is this the first time you’ve seen this error? (Yes / No):
yes
When did this problem seem to first start?
replace me
Installation method (e.g. AlO, NCP, Bare Metal/Archive, etc.)
AIO
Are you using CloudfIare, mod_security, or similar? (Yes / No)
no
The instance has been wiped already, as it proved unsuitable, so I haven’t got access to logs anymore. However, before we give up totally on NextCloud I wanted ask for other users’ experiences.
I used the latest AIO image (March 2026), on an Ubuntu 2024.04 server.
Summary of the issue you are facing:
I just used the AIO image to setup a NextCloud instance. The server is located in Europe, but I am in Asia at the moment. This test here solely concerns the office application.
Unfortunately, Collabora was unusable. The typing lag made it totally useless for any kind of work. The server load was minimal all the time, so the server seems to have enough resources. The local internet connection is fine, using Google Docs in another browser tab worked extremely well. Also in Collabora it was impossible to insert any images from NextCloud into a documents. Insert → images just didn’t find any files.
OnlyOffice was much better. Still not quite like Google Docs, but the typing lag was OK. However, loading any document took ages.
I am happy to hear other users’ experiences.
well all I can tell you here is that even on my small little nas ncoffice works pretty smoothly. It just takes a moment to load but usually there’s no lag while typing.
The only time when It comes to lags it’s due to network problems (like bad wifi or such).
well that’s what I meant by quoting “network problems”.
of course you can setup your instances like you want, eg your databases in Australia, your webserver in chile, your storage somewhere in rural Canada and your collabora in Europe, all that coming from somewhere in Asia. It’s up to you and your choice.
But you alone need to face the consequences of your decisions.
Unfortunately that is the normal situation. Users from round the globe and I have no influence over their location. Regardless where I put the server, it will always be far from somebody. OnlyOffice seems to cope with that much better, Collabora (at leat here) was unusable. Colleagues used Google Docs while connected to a slow wifi on a remote site and according to them it still felt OK.
i still think that having the collabora-server closer to your server would minimize the delay.
Think about this:
user — (wifi) — nc ———— collabora (in europe) ———– nc —- (wifi) — user
vs
user — (wifi) — nc - collabora (close-by, maybe even same server) – nc —- (wifi) — user
the user connection to your NC - you have no control over that. it might be slow, it might be good. but you do have control about where to have your collabora.
For example, I had a client with an old Java applications as checkout/register, connected to a local server.
That application was written with the intend of being used with a 100MBit/s Lan connection and 1ms latency.
Later on, the client had multiple remote places. We made site to site VPNs. This worked fine for your fiber places. Then we got a new remote place that only had copper. Software was unusable. Every click took a second to load. So we used RDP instead.
Why was RDP faster? Turns out the copper site had a 30ms latency to our main branch. For a single RDP stream using UDP this is fine. For an application where every click is hundreds back and forths, each waiting ack? That adds up to 1s latency pretty fast.
So one being faster during edit or one being faster for the initial load, is to be expected. According to your report, both don’t handle latency well. Probably not much that can be done other than making sure the server has an ISP with good worldwide peering.
the big difference is Google Docs doesn’t run on one server - their system is distributed over the world using CDN and each user connects to geographically close “server”. I think it would be possible to setup multiple instances of Collabora behind a CDN to allow people to use a local one but I think it’s far behind budget and possibilities of a SoHo user.
I can confirm this behavior. I have local instance ncoffice and this work a lot worse compared to gdocs or ms365. Work via 100mbit+ internet is almost impossible. But i have problem even with edit easy .md file on phone. This is not internet problem but nextcloud internally. Work unreliable at all. Only file sharing work well with full connection speed. I maked a lot instances on different hardware, bare metal and VM’s, NC work the same.
So, please not looking problem on internet speed, this is nextcloud problem. But still authors add new functions, not looking for making core to work well.
If anything, this is more of a Collabora Online “problem”, since that’s what Nextcloud uses for its office solution.
Performance can also vary depending on how it’s deployed, for example, whether you’re running a separate Collabora Online container, using a dedicated server, or relying on the “built-in server” provided via the Nextcloud App Store. The built-in option tends to perform somewhat worse than a properly separated deployment.
I’m not an expert, but I’d say, this mainly has to do with the architecture of Collabora Online. The entire LibreOffice codebase runs on the server, and only certain UI rendering tasks are handled by the the client/browser.
I’m not entirely sure how Google Docs and the other Google Workspace apps work internally. As far as I know, they use a combination of server-side and client-side components as well. However, their approach seems more efficient. They likely use various optimizations and some trickery, so not everything is processed in real time in the same way.
Also, Google is a hyperscaler with massive resources and extremely fast global infrastructure, and their applications were designed from the ground up for this exact use case, with performance and real-time collaboration in mind.
This makes it difficult to compare with a home or SMB internet connection and self-hosted server setup. It is also difficult to compare with a product that effectively uses the code of a complex desktop application (namely LibreOffice), and most of the heavy processing happens on the server, which then essentially streams a rendered view of the document to the browser.
most of the heavy processing happens on the server, which then essentially streams a rendered view of the document to the browser
This is it. With Collabora you need a server roundtrip for a keystroke to appear because everything is streamed. One day we may see LibreOffice running in WebAssembly in your browser or something but Collabora isn’t there yet
Nextcloud Office (both Collabora and OnlyOffice) is very sensitive to latency, because it’s constantly syncing every keystroke between your browser and the server. So if your server is in Europe and you’re in Asia, even a “fast” internet connection will still feel laggy. Collabora is usually the worst in high-latency setups, which is why typing felt unusable. OnlyOffice handles it a bit better, but loading and syncing large documents will still feel slow. In short, your server isn’t underpowered, the distance is the real problem here. For smooth experience, the office server really needs to be geographically close to the user, or you need something like local caching/proxy or just using Google Docs-style cloud apps that are more optimized for latency.
OnlyOffice seems to cope with that much better, Collabora (at leat here) was unusable. Colleagues used Google Docs while connected to a slow wifi on a remote site and according to them it still felt OK.