Why Latency Matters in Remote Work — and How to Cut It

中文版本： 《远程工作中延迟到底意味着什么》

"It feels slow." It's the most common complaint about remote desktop tools, and the least quantified. This post is about what "slow" actually means — what latency numbers correspond to what subjective experience, and what you can do to bring those numbers down.

What Latency Actually Is

In remote desktop, end-to-end latency is the time from when you click or type until you see the result on your screen. It's made up of:

Input capture
  + Network round trip (you → remote)
  + Remote machine processing
  + Frame encode
  + Network round trip (remote → you)
  + Frame decode + display

Network is usually the dominant term. A frame encoded in 8ms but routed through a relay in Frankfurt picks up 200ms before you see it.

How Latency Feels at Each Band

Latency	What you experience
< 30ms	Feels local. Typing, dragging, scrolling — indistinguishable from native.
30-60ms	Still very usable. Most professional work is fine.
60-100ms	Slight delay you can perceive. Drag operations get sluggish. Code editing is OK.
100-150ms	Noticeable. Fast typists outrun the display. Mouse drags feel like dragging through mud.
150-250ms	Frustrating. You wait for the cursor to catch up. Tasks take 30-50% longer.
> 250ms	Unusable for active work. OK only for occasional clicks / checks.

These are subjective bands, but they map well to research on input-output lag in human-computer interaction. Anything under 100ms feels "real-time"; anything over it your brain starts compensating, and that compensation has a cost.

Where Latency Comes From

Three culprits, in order of impact:

1. Geographic detour through a relay

If your remote desktop tool routes traffic through a vendor data center far from both endpoints, you pay the detour twice. A San Francisco user remoting into a San Francisco server through a Frankfurt relay adds ~150ms round-trip — turning a 20ms session into a 170ms one.

This is the single biggest reason to prefer P2P architecture over relay-based.

2. Encoder/decoder choices

H.264 with hardware acceleration: ~5-15ms. Software-only encode at high quality: 30-80ms. A tool stuck on old codecs adds latency you can't compensate for elsewhere.

3. Network instability

A clean 80ms link feels better than a jittery 50ms one. Packet loss above 1% causes the codec to fall back to lower-quality keyframes, which feel worse than baseline latency.

Which Tasks Suffer Most

Task	Sensitivity
Reading documents, reviewing code	Low — you can tolerate 200ms
Writing emails, light coding	Medium — 100ms starts to hurt
Heavy IDE work, refactoring	High — 80ms is the comfort ceiling
Drawing, 3D modeling, video editing	Very high — 50ms is the comfort ceiling
Gaming, real-time audio production	Extreme — 30ms is the comfort ceiling

If you're doing creative or interactive work remotely, your tool choice matters more than your hardware.

How to Measure It

Concrete tests beat vendor marketing:

Type test: open a text editor and type a sentence quickly. Watch if characters lag.
Mouse trail: enable "mouse trails" in OS settings and drag fast. The gap between cursor and trail is your input latency.
Frame timing: tools like frame-timing or built-in WebRTC stats show codec + transport delays separately.
Ping comparison: ping <remote-machine> directly (if possible) vs the round-trip your tool reports.

How to Cut It

In rough order of effectiveness:

Use a P2P-first tool. The biggest gain is usually here.
Connect both endpoints to ethernet when possible. Wi-Fi adds 5-20ms even on a good network.
Match codec to scene. Most tools auto-select; if yours doesn't, pick a low-latency profile.
Reduce display resolution if bandwidth is the bottleneck. Lower resolution = less data to ship = less buffering.
Disable visual effects on the remote side. Translucent windows, animations, drop shadows all eat encode time.