Why Nextcloud feels slow to use

Two things:

1. Did you open back port request with these basic patches? If you have orders of magnitude speed improvements it would be aswesome to share!

2. You definitively don't need an entire sysadmin team to run nextcloud, in my work (large organisation) there's three instances running (for different parts/purposes of which only one is run by more than one person, and I run myself both my personal instance and for a nonprofit with ~100 persons, it's really not much work after setup (and other systems are plenty of a lot more complicated systems to set up, trust me)

The article mentions Vikunja as an alternative to Nextcloud Tasks, and I can give it a solid recommendation as well. I wanted a self-hosted task management app with some lightweight features for organizing tasks into projects, ideally with a kanban view, but without a full-blown PM feature set. I tried just about every task management app out there, and Vikunja was the only one that ticked all the boxes for me.

Some specific things I like about it:

  * Basic todo app features are compatible with CalDAV clients like tasks.org
  * Several ways of organizing tasks: subtasks, tags, projects, subprojects, and custom filters
  * list, table, and kanban views
  * A reasonably clean and performant frontend that isn't cluttered with stuff I don't need (i.e., not Jira)

And some other things that weren't hard requirements, but have been useful for me:

  * A REST API, which I use to export task summaries and comments to markdown files (to make them searchable along with my other plaintext notes)
  * A 3rd party CLI tool: https://gitlab.com/ce72/vja
  * OIDC integration (currently using it with Keycloak)
  * Easily deployable with docker compose

Javascript making PHP look bad.

Yes and no: There's still a rather large latency improvement even when you're using plain HTTP (not that you should go without encryption).

I was very curious so I asked AI to explain why websockets would have such lower latency than regular HTTP and it gave some (uncited, but logical) reasons:

Once a WebSocket is open, each message avoids several sources of delay that an HTTP request can hit—especially on mobile. The big wins are skipping connection setup and radio wakeups, not shaving a few header bytes.

Why WebSocket “ping/pong” often beats HTTP GET /ping on mobile

    No connection setup on the hot path
        HTTP (worst case): DNS + TCP 3‑way handshake + TLS handshake (HTTPS) before you can send the request. On mobile RTTs (60–200+ ms), that’s 1–3 extra RTTs, i.e., 100–500+ ms just to get started.
        HTTP with keep‑alive/H2/H3: Better (no new TCP/TLS), but pools can be empty or closed by OS/radios/idle timers, so you still pay setup sometimes.
        WebSocket: You pay the TCP+TLS+Upgrade once. After that, a ping is just one round trip on an already‑open connection.


    Mobile radio state promotions
        Cellular modems drop to low‑power states when idle. A fresh HTTP request can force an RRC “promotion” from idle to connected, adding tens to hundreds of ms.
        A long‑lived WebSocket with periodic keepalives tends to keep the radio in a faster state or makes promotion more likely to already be done, so your message departs immediately.
        Trade‑off: keeping the radio “warm” costs battery; most realtime apps tune keepalive intervals to balance latency vs power.


    Fewer app/stack layers per message
        HTTP request path: request line + headers (often cookies, auth), routing/middleware, logging, etc. Even with HTTP/2 header compression, the server still parses and runs more machinery.
        WebSocket after upgrade: tiny frame parsing (client→server frames are 2‑byte header + 4‑byte mask + payload), often handled in a lightweight event loop. Much less per‑message work.
         

    No extra round trips from CORS preflight
        A simple GET usually avoids preflight, but if you add non‑safelisted headers (e.g., Authorization) the browser will first send an OPTIONS request. That’s an extra RTT before your GET.
        WebSocket doesn’t use CORS preflights; the Upgrade carries an Origin header that servers can validate.


    Warm path effects
        Persistent connections retain congestion window and NAT/firewall state, reducing first‑packet delays and occasional SYN drops that new HTTP connections can encounter on mobile networks.

What about encryption (HTTPS/WSS)?

    Handshake cost: TLS adds 1–2 RTTs (TLS 1.3 is 1‑RTT; 0‑RTT is possible but niche). If you open and close HTTP connections frequently, you keep paying this. A WebSocket pays it once, then amortizes it over many messages.
    After the connection is up, the per‑message crypto cost is small compared to network RTT; the latency advantage mainly comes from avoiding repeated handshakes.
     

How much do headers/bytes matter?

    For tiny messages, both HTTP and WS fit in one MTU. The few hundred extra bytes of HTTP headers rarely change latency meaningfully on mobile; the dominant factor is extra round trips (connection setup, preflight) and radio state.
     

When the gap narrows

    If your HTTP requests reuse an existing HTTP/2 or HTTP/3 connection, have no preflight, and the radio is already in a connected state, a minimal GET /ping and a WS ping/pong both take roughly one network RTT. In that best case, latencies can be similar.
    In real mobile conditions, the chances of hitting at least one of the slow paths above are high, so WebSocket usually looks faster and more consistent.

Copyparty can't (and doesn't want to) replace Nextcloud for many use cases because it supports one-way sync only. The readme is pretty clear about that. I'm toying with the idea of combining it with Syncthing (for all those devices where I don't want to do a full sync), does anybody have experience with that? I've seen some posts that it can lead to extreme CPU usage when combined with other tools that read/write/index the same folders, but nothing specifically about Syncthing.