perf(platform): ~6.4s Convex sync WebSocket + auth round-trips before interactive (every load)

[Israeltheminer]

Problem

Even on a fully cached load (all static assets served from the browser cache after #2843), the dashboard takes several seconds to become interactive because of backend round-trips at startup — unrelated to asset caching. From a warm-cache HAR of the deployment (2026-07-22, captured after the caching fix deployed):

• /ws_api/api/1.35.1/sync (Convex realtime sync WebSocket) — 6.37 s time-to-first-byte.
• /api/auth/get-session called 3× — 1.62 s, 1.05 s, 0.41 s.
• /api/auth/convex/token — 1.05 s.

This is now the single largest cost on a warm load (the ~150 static chunks come from cache at ~0.1 s each).

Current behaviour

Routing (services/proxy/Caddyfile): /ws_api/* and /api/*/sync → convex:3210 (the sync WebSocket); /api/auth/* → convex:3211. The client opens the Convex sync WS and runs auth/session fetches on every app mount; the WS handshake alone is ~6 s TTFB.

Open questions

• Why does the sync WebSocket take ~6.4 s to first byte — Convex self-hosted cold-connect, the TLS/upgrade handshake through Caddy, or backend processing?
• Why is /api/auth/get-session fetched 3× per load? Likely a client-side redundancy (dedupe/cache opportunity).
• Is /api/auth/convex/token on the WS critical path, serializing ~1 s in front of the ~6.4 s?
• Is any of this specific to the self-hosted single-node deployment vs. expected everywhere?

Suggested first steps

Reproduce with a warm-cache load + HAR; instrument the Convex client connect + auth flow; check whether the triple get-session is a client effect that can be deduplicated.

Acceptance criteria

• Root cause of the ~6.4 s sync-WS TTFB identified.
• Redundant auth round-trips (the 3× get-session) removed or explained.
• Time-to-interactive on a warm load down to low single digits or better.

Evidence / links

Warm-cache HAR (2026-07-22). Related: #2842 (cold-load static-asset delivery), #2843 (caching fix, merged), #2847 (skip CSP middleware on assets).

[Israeltheminer]

Closing — consistent with #2842. The "~6.4s Convex sync WebSocket" headline was a HAR misread: the entry is a healthy persistent WebSocket (101 Switching Protocols, ~60 messages spanning the capture window), not a 6.4s block before interactivity. The remaining items (auth/session round-trips ~1s each, a triple get-session) are minor and most likely reflect the same host memory over-subscription behind #2842 (a 4 GiB box swapping under the full stack), not a code defect at this scale. Reopen if it reproduces on an adequately-provisioned host.