Remote desktop latency explained

In a cloud desktop, latency is the time between an action you take — moving the pointer, pressing a key, scrolling — and the moment that action is reflected in the picture you see. It is not the same as bandwidth. Bandwidth is how much data per second the connection can move; latency is how long each piece of interaction takes to make the round trip and come back as pixels.

A connection with enormous bandwidth but high latency still feels sluggish, because the pointer trails your hand and keystrokes appear a beat late. A connection with modest bandwidth but low latency feels local. For interactive desktop work, latency wins.

• Round-trip time (RTT): the network delay between your device and the instance region. This is dominated by geographic distance — light in fiber takes roughly 5 ms per 100 km, so a 1,000 km round trip is already ~50 ms before any processing.
• Input-to-photon latency: the full time from a physical input to the updated frame reaching your eye. This is the number that actually governs perceived responsiveness; it bundles RTT plus encode, decode and display buffering.
• Dropped-frame percentage: how often the stream misses its target frame cadence. Even with low average latency, a 5%+ drop rate produces visible stutter that reads as lag.

Of the three, input-to-photon is the honest measure of "does this feel local." The session broker reports all three live, but the perceptual threshold lives in input-to-photon.

A single interaction passes through a fixed set of stages. Each adds time:

• Input capture: the browser reads the pointer or key event — sub-millisecond.
• Uplink transport: the event travels to the instance region — this is the RTT term, and the largest variable.
• Instance processing: the remote OS applies the event to its frame — typically 1 frame at the display refresh rate (16 ms at 60 Hz).
• Encode: the updated frame is compressed by the codec (H.264/AV1) — 5-15 ms depending on quality preset and hardware acceleration.
• Downlink transport: the compressed frame travels back — another RTT term.
• Decode and display: the browser decodes and paints the frame — 5-10 ms with hardware-accelerated WebRTC.

The two transport terms (uplink + downlink) are each roughly half the RTT, so together they equal one full round trip. The encode, decode and instance-frame terms are the "pipeline depth" — they're roughly constant for a given codec and refresh rate, which is why choosing a nearby region is the single biggest lever you have.

Human perception of input lag has a well-studied threshold. Below roughly 50 ms of input-to-photon latency, the interaction feels immediate to nearly everyone for pointer and typing work. Above 100 ms it is consistently noticed; above 150 ms it actively impairs precision work like design selection or text editing.

• Under 50 ms: feels local. Suitable for design, code editing, spreadsheet work and most productivity tasks.
• 50-100 ms: responsive. Noticeable if you look for it, but not disruptive for general work.
• 100-150 ms: usable but laggy. Fine for reading and light work; uncomfortable for sustained pointer-precision tasks.
• Over 150 ms: disruptive. Typing and selection feel disconnected from your hand.

SisiDesk targets a sub-50 ms P95 input-to-photon latency to a nearby region, which is the threshold at which a streamed desktop stops feeling streamed. See the architecture overview for how the region and codec choices are tuned to hold that.

• Region selection: pick the instance region closest to you. This is the largest single lever — it directly sets the RTT terms. SisiDesk shows the nearest low-latency region by default and lets you override it.
• Network path: a wired connection or strong 5 GHz Wi-Fi removes the last-hop jitter that wired and fiber users never see. Avoid congested shared Wi-Fi for precision work.
• Codec quality: higher quality presets increase encode time. If you're on a marginal connection, the session broker can drop to a faster preset to protect latency over fidelity.
• Display refresh: a 60 Hz instance refresh adds a 16 ms frame term; where available, higher refresh instances reduce it. This is a per-template choice.

These three are routinely confused but behave differently:

• Latency sets the responsiveness floor. You cannot buy your way under it with more bandwidth.
• Bandwidth sets the ceiling on image quality and resolution. More bandwidth lets the codec send richer frames, but only once latency is already acceptable.
• Jitter — variation in latency — is what causes stutter. A connection averaging 40 ms with ±30 ms jitter feels worse than one averaging 60 ms with ±5 ms. The session broker reports jitter alongside RTT.

Every active SisiDesk session surfaces its live transport metrics in the status panel: round-trip time, input-to-photon latency, jitter, and dropped-frame percentage. These are sampled continuously from the media transport, not estimated from a one-shot speed test, so they reflect the connection you actually have while you work.

If input-to-photon drifts above the target, the panel highlights which term is responsible — most often RTT, which means the region or your network path is the cause, not the codec.

What is a good latency for a remote desktop?

For general productivity work, a round-trip latency under 100 ms feels responsive. For design, video scrubbing or any pointer-heavy task, aim for under 50 ms — the point at which input lag drops below the perceptibility threshold and the desktop feels local.

Why does my remote desktop feel laggy even on fast internet?

Because latency is dominated by geographic distance and codec pipeline depth, not raw bandwidth. A 1 Gbps connection to a region on another continent still incurs the speed-of-light round trip plus encode and decode stages. Choosing a region close to you is the single biggest lever.

Does browser-based streaming add latency compared to a native client?

Modern browsers run the same WebRTC media pipeline a native client uses, so the added browser overhead is negligible — typically under 5 ms. The dominant latency terms are network distance and the codec's frame pipeline, not the browser.

How is latency measured in a SisiDesk session?

The session broker reports round-trip time, input-to-photon latency and dropped-frame percentage in the session status panel. These are sampled continuously while a session is active, not estimated from a speed test.

Send the session ID and a screenshot of the status panel to hello@sisidesk.com and we will pull the full transport trace for that session.