If your team has engineers or support staff logging into company PCs from another continent, the lag is hard to miss: the cursor drifts a half-second behind, keystrokes appear late, and screen sharing feels sluggish even when the internet connection itself looks fine. That gap is not just a slow connection; it is a combination of physical distance, routing, and client-side settings. Once those causes are separated, there is a surprising amount that can actually be fixed.
1. Why Overseas Connections Feel So Much Slower
The single biggest factor in latency is physical distance. Light itself needs roughly 70-100ms for a round trip between, say, Seoul and New York, and real internet traffic, bouncing through multiple ISPs and undersea cable landing points, often adds up to 150-250ms. Peering congestion and border inspection equipment on some routes push it even higher. Even within the same country, a branch office on a weaker regional circuit can see similar symptoms compared to headquarters.
2. The Three Components of Latency
To actually reduce lag, it helps to know where the time is going:
- Propagation delay – proportional to distance and hop count. This cannot be configured away; only a better route helps.
- Processing delay – the time spent encoding and compressing the screen on one end and decoding it on the other. This is the part client settings can directly improve.
- Bandwidth and congestion delay – packets queuing up when upload speed is insufficient or the local network is busy. This is fixed with better circuits and QoS.
3. Client Settings That Actually Cut Perceived Lag
The physical distance cannot be shortened, but processing delay is very much within reach. In order of real-world impact:
- Lower the frame rate. For document editing and coding, where the screen is mostly static, 15-20fps feels just as responsive as 30fps while sending far less data per second.
- Send a lower resolution than the native monitor resolution. Streaming a 4K display at full resolution dramatically increases encoding load and, with it, latency. Stepping down one notch, for example from 2560×1440 to 1920×1080, helps noticeably.
- Set compression to standard rather than best quality. Quality-first modes take longer to encode. For text-heavy work, standard compression looks nearly identical.
- Enable GPU hardware acceleration on both the controlling and the controlled machine. Hardware encoding is consistently faster than software or CPU encoding.
- Turn off extras that are not needed, such as wallpaper transmission, window animations, or audio forwarding, to free up bandwidth for the parts that matter.
4. Network and Routing-Level Fixes
Client settings only go so far; the path the traffic takes matters just as much.
- Use a wired connection whenever possible. Wi-Fi adds an unpredictable 20-50ms depending on distance and interference, which stacks badly on top of already-high international latency.
- Run a traceroute before blaming slow internet. A traceroute, or tracert on Windows, shows exactly which hop the delay spikes at. If one specific ISP segment jumps sharply, that points to a peering issue worth escalating rather than a client-side problem.
- Pick the nearest available region or relay. If the remote access tool allows choosing a server region, pick the one closest to the connecting user. Tools that support direct peer-to-peer connections skip the relay hop entirely, shaving off more latency.
- Reconsider full-tunnel VPN. Routing all traffic through a head-office VPN before it reaches its real destination can add a detour longer than the direct route. Where security policy allows, split tunneling for remote-access traffic specifically is worth discussing with IT.
- Apply QoS to prioritize remote-access traffic. On a shared office circuit, marking remote desktop ports with higher priority through QoS or DSCP marking keeps them from being starved by other traffic such as backups or large downloads.
5. Designing Workflows Around Latency That Cannot Be Eliminated
Latency across an ocean will never reach zero, so it is worth designing how a team works with that constraint in mind:
- Protect overlap hours for real-time work. Reserve the window where time zones genuinely overlap for anything that needs live collaboration, and shift everything else to async.
- Replace live screen-sharing with recordings for reviews. When something only needs to be checked or approved, a screen recording or annotated screenshot removes latency from the equation entirely.
- Schedule critical sessions outside peak congestion hours. Network congestion varies by time of day even on the same route, so connecting outside local peak hours often noticeably improves the experience.
6. Quick Reference Checklist
| Item | Target / Recommendation | How to Check |
|---|---|---|
| Frame rate | 15-20fps for work sessions | Client display settings |
| Output resolution | One step below native monitor resolution | Client display settings |
| GPU acceleration | Enabled on both endpoints | Client advanced settings |
| Connection type | Wired or Ethernet preferred | Network adapter settings |
| Route diagnosis | Each hop under about 100ms | traceroute / tracert |
| VPN routing | Split tunneling where policy allows | VPN client configuration |
| Work scheduling | Real-time tasks within overlap hours | Team calendar coordination |
For teams managing a distributed workforce or an overseas branch, the best approach is not to change everything at once: run a traceroute first to find where the delay is actually coming from, then adjust client settings and compare the before-and-after. WYRemote allows fine-tuning frame rate, resolution, and compression per session and routes connections toward the nearest available region, which makes it easier to keep remote access workable even when a team is spread across continents.
If you run into this often, take a look at Y-Remote, a browser-based remote control SaaS that needs no VPN or port forwarding.