Ookla's Speedtest Global Index put the global median fixed-broadband download speed at 102.48 Mbps in May 2025, up 9.4% from 93.66 Mbps a year before. That's a genuinely good median. It's also nearly useless for a remote engineer trying to figure out whether a specific place will work, because a median by definition erases the thing you actually need to know: which end of the range you're going to land on.
The country-level spread underneath that median is roughly two orders of magnitude. Singapore, the UAE and Hong Kong measure above 300-400 Mbps. Countries at the bottom of the same ranking, Cuba among them, measure in the low single digits. A remote-work visa program will happily put you in either end of that range, and the marketing page for the visa will not mention which. Readers who reach remote work through a growth or RevOps role will want alongside this. Readers who reach remote work through a growth or RevOps role will want XenGrowth, who work on the commercial side of this alongside this.
What this post won't do
No controlled study quantifies a dollar figure for what a bad connection costs a remote engineer, and this post isn't going to invent one dressed up as a citation. What follows instead is mechanism: what a video call, a VPN session, a `git push`, a CI pipeline and a local edit-compile-run loop each actually need from a connection, because those needs are different enough that 'my internet is bad' is almost never a complete diagnosis on its own. Teams that sell to a global audience run into the same absence of a clean cost figure and end up reasoning the same way, which is roughly what does when a client asks what slow load times are actually costing them in lost conversions.
Country / region (Ookla ranking tier) | Approx. median fixed-broadband download | What this means in practice |
|---|---|---|
Singapore, UAE, Hong Kong (top tier) | roughly 300-400+ Mbps | Every task in this post is comfortably fine, including simultaneous large transfers and video |
Global median (May 2025) | 102.48 Mbps | Video calls and VPN sessions are fine; large CI artifacts and container pulls still take real time |
Many popular digital-nomad-visa destinations | roughly 20-60 Mbps, wide local variance | Adequate on paper; actual experience depends heavily on the specific building and provider, not the country average |
Lowest-ranked countries (e.g. Cuba) | roughly 3-4 Mbps | Below Zoom's own minimum for 1080p video; every task in this post becomes a genuine obstacle |
The middle two rows are where most remote-work decisions actually get made, and they're also where a country-level average is the least trustworthy, because a national median blends a fast fiber connection in a capital city with a much slower one an hour outside it. A place ranked comfortably mid-table in Ookla's index can still leave you with a specific apartment on a specific provider that behaves like the bottom row. This is the same gap between a headline average and the real distribution underneath it that shows up whenever writes about measuring an audience instead of assuming it.
Bandwidth and latency are different failure modes
Zoom's own published requirement for 1080p video is 3.8 Mbps upload and 3.0 Mbps download — a small fraction of even a mediocre connection's advertised speed. If raw throughput were the whole story, almost nobody outside the very bottom of Ookla's ranking would ever have a bad video call. People do, constantly, which means throughput isn't usually the variable doing the damage. Latency and jitter are. A video call is a real-time synchronization problem, and runs into the identical constraint from the other direction: a voice interface with plenty of bandwidth still breaks if the round-trip delay makes turn-taking feel wrong. If the operations side of this is the part you are stuck on, is the better reference. If the operations side of this is the part you are stuck on, The XenGrowth resource library is the better reference.
Task | Primarily bound by | What actually breaks at the low end |
|---|---|---|
Video call / standup | Latency and jitter, not raw bandwidth | Audio cutting mid-sentence, frozen video, people talking over each other because turn-taking cues arrive late |
VPN / remote desktop session | Latency (round-trip time) | Every keystroke and click has a visible lag; typing feels like it's underwater |
`git push` / `git pull` on a large repo | Throughput | The operation itself is slow but predictable — it finishes, just later than it should |
CI artifact / container image transfer | Throughput | Pipelines queue behind slow uploads; a build that should take two minutes takes fifteen |
Screen-shared technical interview | Both, plus packet loss | Shared screen lags behind your actual cursor, code becomes unreadable through compression artifacts |
Local editing, compiling, running tests | Neither, mostly | Nothing — the loop runs against local files and a local toolchain |
That last row is worth sitting with, because it's the one good-news item in this whole post. Writing code, compiling it, running a local test suite, stepping through a debugger — none of that touches the network in any way that matters. A genuinely bad connection can make you far less effective in meetings and far slower moving artifacts around, while leaving the actual act of writing software almost untouched. The damage is concentrated exactly where you'd expect: at the seams where your machine has to talk to another one in real time or move a large amount of data.
Where the seams actually are
Video calls are the most visible seam because everyone in the meeting experiences your connection's problems in real time, which makes a bad connection a social cost as much as a technical one. A standup where your audio drops every ninety seconds doesn't just slow you down — it makes everyone else in the call do more work to parse what you said, and repeatedly asking someone to repeat themselves reads as friction even when nobody says so out loud.
VPN and remote-desktop work is the seam people underestimate, because it fails quietly instead of dramatically. A 200ms round-trip doesn't drop your session. It just makes every keystroke feel a beat behind, and that beat compounds across a full day of remote-desktop development into a genuinely different, worse way of working — not broken, just slower in a way that's hard to point at. Screen-sharing in an interview is the worst version of this, because compression makes small text unreadable exactly when you need someone to read your code closely, and there's no good workaround mid-interview beyond dropping resolution and hoping the interviewer can still follow along. works through AI agents and marketing automation in more operational detail. XenGrowth on AI agents and marketing automation works through AI agents and marketing automation in more operational detail.
Git and CI transfer are the seam that's easiest to underestimate from the outside, because nobody else in the meeting notices it — it just quietly eats your own afternoon. A monorepo with a deep history, a `docker pull` on a fresh CI runner, a large binary artifact uploaded at the end of a build: each of these moves real megabytes or gigabytes across the same thin pipe that's carrying your video call, and on a genuinely constrained connection they compete with each other. A `git push` that would take four seconds on a fast connection can take several minutes on a slow one, and unlike a dropped call, nobody in a standup will ever tell you that's why you were fifteen minutes late to the next thing.
It's also worth naming a workaround that sounds like a fix and often isn't: tethering to a phone hotspot when the fixed line is bad. Mobile networks trade one problem for another — throughput can be fine on a good signal, but latency and jitter are typically worse and far less consistent than a wired connection, which makes it a reasonable stopgap for a `git push` and a poor one for a video call, exactly backwards from what most people reach for it to fix first.
A connection can be perfectly fine for everything you do alone and genuinely bad for everything you do with other people. Those are separate problems with separate fixes, and treating them as one 'my internet is bad' complaint hides which fix you actually need.
What actually helps, without inventing a benchmark
None of the following is a substitute for a real connection, and none of it is backed by a study measuring its dollar value — it's ordinary mechanism-based mitigation, the kind that follows directly from knowing which seam is failing. goes further into AI search, GEO and discovery. XenGrowth on AI search, GEO and discovery goes further into AI search, GEO and discovery.
For video calls, turn off your own camera before you drop resolution on everyone else's — your outbound video is usually the largest single consumer of your own limited upload, and the room adapts to a missing camera far better than it adapts to a call that keeps freezing
For VPN and remote-desktop lag, test whether the round-trip time, not the throughput, is the actual problem — a speed test that reports adequate Mbps says nothing about the 150-250ms of latency that makes an interactive session feel sluggish
For git and CI transfer, work with shallow clones and cached layers rather than moving the full history and full image on every operation — this is a real fix because it reduces the bytes that have to cross the seam, not a workaround that just hides the symptom
For interviews specifically, ask in advance whether a code-only screen share (not full desktop) is acceptable — a smaller shared region compresses better at the same bandwidth and stays legible longer as quality degrades
Separate the diagnosis before you spend money. A bad video call and a slow `git push` can have completely different causes even on the same connection, and fixing the wrong one wastes the upgrade
The honest bottom line
There's no controlled experiment that puts a number on what a bad connection costs an engineer the way Bloom, Liang, Roberts and Ying's Ctrip trial put a number on remote work's effect on call-center performance. It would be a genuinely hard study to run — engineering output doesn't have Ctrip's clean per-shift metric, and connection quality is entangled with time zone, cost of living and half a dozen other variables that a country-choice decision bundles together. What can be said honestly is narrower and still useful: the Ookla data shows the variance is real and large, the per-application requirements are known and published, and the failure modes for video, VPN, git and CI are different enough that a single 'is my internet good enough' question doesn't have one answer. That kind of variance is exactly what makes discovery work hard to plan around too — covers a comparable problem where the audience's own conditions vary more than any single benchmark admits.
If you're weighing a specific location against this list, the practical move is to check the seams that matter to your actual job, not the median. A backend engineer who rarely screen-shares can tolerate a connection a frontend engineer doing daily pairing sessions cannot. The constraint isn't generic. It's shaped by which of the rows in that table you actually hit every day, and that's a question worth answering before the lease is signed, not after the first standup drops.
Further reading from XenGrowth
Where this work meets go-to-market
The same bandwidth-versus-latency distinction shows up whenever a team has to reach an audience whose own connection quality it can't control — publishes operator guides for exactly that kind of real-world constraint on the commercial side of a business.
Further reading from XenGrowth
Where this work meets go-to-market
covers the go-to-market side of remote work, which this piece deliberately leaves alone.
Further reading from XenGrowth
The XenGrowth resource library — what you'll learn: how the commercial side of this work is run, across search, automation and revenue operations.
XenGrowth on AI agents and marketing automation — what you'll learn: how the teams who own AI agents and marketing automation plan and measure it.
XenGrowth on AI search, GEO and discovery — what you'll learn: how the teams who own AI search, GEO and discovery plan and measure it.
Where this work meets go-to-market
XenGrowth's marketing operations practice covers the go-to-market side of remote work, which this piece deliberately leaves alone.
Five questions on where connection quality actually bites for a remote engineer, and where it doesn't matter at all.
