The fastest remote access: how LynxTrac delivers low latency
Remote access usually feels like a compromise. LynxTrac keeps round-trips tight so terminal sessions feel local instead of sluggish, with work happening at every layer.
Remote access usually feels like a compromise, just slow enough to remind you it’s not local. Getting it to feel fast requires attention at every layer, and the rest of this post is how LynxTrac does that.
Where the latency actually hides
For a terminal session, the user-visible latency comes from:
- Keystroke → local event → browser event loop. ~2ms, nothing to do.
- Browser → relay over TLS. Network-bound. Can be 5-200ms.
- Relay → agent over an already-established tunnel. 5-50ms, depending on path.
- Agent → pty write. <1ms.
- Shell response → reverse path back. Same as 2-4.
So: two full round-trips per keystroke, approximately 2 × (RTT_browser_to_relay + RTT_relay_to_agent).
What LynxTrac does about each
RTT browser → relay. We run relays in 14 regions and route browser connections to the nearest one, validated by TLS SNI. Median browser → relay RTT: 18ms.
RTT relay → agent. The agent keeps a persistent multiplexed tunnel to the relay, so there’s no reconnection cost. We keep the tunnel alive with HTTP/2 pings, a new session opens a new logical stream, not a new TCP connection.
Pty handling. We buffer output on the agent and flush at 60Hz instead of character-at-a-time, which cuts syscalls by an order of magnitude without adding perceivable latency.
TLS setup. Sessions use resumed TLS tickets where supported; first-byte-to-shell is typically 80ms from a cold browser.
Remote desktop is different
For remote desktop, latency is dominated by frame pipeline, encode, send, decode, paint. We use H.264 for most sessions and switch to WebCodecs-based hardware decode where the browser supports it. On a good path, you see 16-30ms click-to-paint.
The numbers
- Terminal keystroke echo (p50): 42ms
- Terminal keystroke echo (p99, good network): 85ms
- Remote desktop click-to-paint (p50): 21ms
- Session open (cold browser → prompt): 110ms
For comparison, a direct SSH session on a LAN is ~5ms. Over a broadband connection to a remote host, 40-80ms. LynxTrac adds one extra hop’s worth of latency, at the cost of giving you zero inbound ports, full audit, and SSO-backed auth.
What still feels slow
Line editors over trans-continental paths. There’s no way to hide 200ms of RTT on a vim session across the Pacific, that’s physics. For those cases, we recommend tmux on the agent so your typing is local to the remote shell.
More on how this works in practice: the features overview, or email [email protected] with questions.
Related posts
Why remote access should never be a standalone tool
Remote access without context is just a shell in the dark. Access, monitoring, and audit belong on one surface rather than three separate purchases.
How VPN-free remote access works
What the outbound-agent model actually does, versus what a VPN does. Written because enough people have asked variations of 'so how is this different from Tailscale?'
Secure remote access for modern IT teams: what really matters today
Most remote access checklists are stuck in 2015. Here are the controls that actually matter for IT teams operating across cloud, hybrid, and remote-first realities.