The Race to Zero Latency

A page that loads in 200 milliseconds feels instant to most people. A robotic surgeon operating over a network connection with the same 200-millisecond delay could kill a patient. Somewhere between those two extremes sits one of the least glamorous but most consequential engineering problems in computing: how fast can a signal travel from one point to another, and what happens as we try to push that number toward zero.

For most of the internet's history, the industry obsessed over bandwidth — how much data you could move per second. Bandwidth is easy to market ("Now with gigabit speeds!") and easy to upgrade by laying more fiber or adding more spectrum. Latency is a different beast. It's the time delay before data starts moving at all, and it's bound by physics in ways that no amount of bandwidth can fix. As applications shift from downloading files to holding real-time conversations with servers, models, sensors, and each other, latency has quietly become the metric that decides whether a system feels responsive or broken.

What Latency Actually Is

Latency is the time it takes for a piece of data to travel from a source to a destination and, usually, back again. It's typically measured in milliseconds (ms) as round-trip time (RTT). If you ping a server and get a response in 40ms, that's your RTT for that path.

Latency is not the same thing as bandwidth, and conflating the two causes a lot of confusion:

• Bandwidth is the width of the pipe — how much data can flow through per second (measured in Mbps or Gbps).
• Latency is the length of the pipe — how long it takes any single bit to travel end to end.

A useful analogy: bandwidth is how many lanes a highway has; latency is how long it takes a single car to drive from one end to the other. You can add more lanes to move more cars per hour, but that does nothing to speed up any individual car's trip. Only shortening the road, or letting cars travel faster, reduces latency.

Total latency is the sum of several components:

Propagation delay is the one people forget about and the one that can't be engineered away. Light in a vacuum travels at about 300,000 km/second, but light in fiber-optic glass travels roughly 30-35% slower because the glass's refractive index bends and slows it. That means a round trip between New York and London — about 5,500 km each way — has a theoretical physical floor of roughly 55-60ms in fiber, before you add a single router hop, a single queue, or a single byte of processing. Real-world RTTs on that route tend to run 70-90ms because actual cables don't travel in straight lines and every hop adds its own small delay.

This is the central, uncomfortable fact of the "race to zero latency": you cannot beat the speed of light. You can only get closer to the physical minimum for a given distance, or you can shorten the distance.

Why Latency Has Become the Metric That Matters

For the first few decades of consumer internet, most traffic was asynchronous. You requested a web page, a file, an email — and a delay of a second or two was mildly annoying but not disqualifying. Bandwidth was the bottleneck because pages were getting heavier (more images, video, scripts) faster than connections were getting faster.

That equation has flipped for a growing share of what people actually do online:

1. Interactive and conversational interfaces. Voice assistants, real-time AI chat, and increasingly agentic systems that call tools and APIs mid-conversation all depend on round trips completing fast enough that the interaction still feels like a conversation rather than a request queue.
2. Multiplayer and cloud gaming. In competitive gaming, the difference between 20ms and 80ms of latency is the difference between landing a shot and missing it. Cloud gaming services that stream rendered frames from remote data centers are entirely latency-gated — bandwidth just determines resolution, latency determines whether the game is playable at all.
3. Financial trading. High-frequency trading firms have spent billions of dollars shaving microseconds off the path between their servers and exchange matching engines, including running fiber and microwave links in the straightest possible lines between cities.
4. Video conferencing and live collaboration. Anything above roughly 150ms of one-way delay starts to introduce the awkward talk-over pauses everyone associates with bad video calls.
5. Autonomous systems and robotics. A self-driving car or an industrial robot arm reacting to a remote command needs latency low and, just as importantly, predictable (low jitter), because a control loop with unpredictable delay is a control loop that can overshoot or oscillate.
6. Augmented and virtual reality. Head tracking that lags the display by more than about 20ms produces motion sickness. This is one of the tightest latency budgets in consumer computing.

The common thread is that these are all systems where a human or a machine is in a tight feedback loop with something remote, and the loop only feels seamless if the round trip disappears below the threshold of perception or the threshold of physical control. Bandwidth improvements don't help any of these use cases much once you're past a baseline; latency improvements help all of them directly.

How the Industry Is Attacking the Problem

Because propagation delay is fixed by distance and medium, the practical strategies for reducing latency all reduce to a small number of moves: shorten the distance data has to travel, reduce the number of hops and amount of processing along the way, or make the underlying protocols more efficient about how they use each round trip.

Moving compute closer to users: edge computing

The most direct way to cut propagation delay is to stop sending requests across a continent or an ocean. Edge computing pushes servers, caches, and increasingly inference workloads out of a handful of centralized data centers and into hundreds or thousands of smaller points of presence closer to where users actually are. A content delivery network (CDN) caching a video file in a city near you is the simplest version of this idea; edge functions that run application logic at that same nearby point, rather than round-tripping to a central server, are the more advanced version.

For AI applications specifically, this is becoming a serious design constraint. Running a large model's inference in a single centralized region might be acceptable for a chatbot answering a text query, but it's a nonstarter for a voice assistant that needs to feel conversational, or a robotics system reacting to a camera feed. Expect more inference to move toward regional and edge deployment, with lighter, distilled models serving latency-sensitive requests locally and heavier models handling anything that can tolerate a longer round trip.

Better protocols

A meaningful share of internet latency historically came not from the physical distance but from protocol overhead — the back-and-forth handshakes required before any actual data moves. TCP's three-way handshake, followed by TLS's own negotiation, could mean multiple round trips before a single byte of the actual request was sent.

QUIC, the transport protocol underlying HTTP/3, was designed specifically to cut this overhead. It combines connection establishment and encryption negotiation into fewer round trips, and it solves a problem called head-of-line blocking, where a single lost packet in TCP could stall an entire connection's worth of data. For someone on a lossy mobile connection, this can matter more than any amount of added bandwidth.

Shortening and straightening the physical path

Undersea cables, terrestrial fiber routes, and even microwave relay towers are laid out with increasing attention to taking the shortest, straightest path between major hubs, rather than the cheapest path to build. This is expensive and slow — a new transoceanic cable takes years to plan and lay — but it produces real, permanent latency reductions because it directly shortens the distance light has to travel.

Low-Earth-orbit satellite networks

Traditional satellite internet, using geostationary satellites roughly 36,000 km above the equator, has terrible latency — often 500-600ms round trip — because the round trip to space and back is simply long, even at light speed. Low-Earth-orbit (LEO) satellite constellations orbit at a few hundred kilometers altitude instead, which cuts that propagation distance dramatically. For long-distance routes, LEO satellite links can in principle beat fiber, because light travels faster through vacuum than through glass, and a satellite hop can sometimes offer a straighter path than a fiber route that has to follow existing terrestrial infrastructure. This is a genuinely interesting frontier: for very long routes, space may end up being the lower-latency medium.

Smarter queuing and congestion control

A lot of real-world, day-to-day latency isn't propagation delay at all — it's queuing delay caused by congested links and poorly tuned buffers, a phenomenon researchers call "bufferbloat." Newer congestion control algorithms and active queue management techniques try to keep queues short and predictable rather than letting them balloon under load, which reduces both average latency and the jitter that makes latency unpredictable.

Practical Implications for Businesses and Builders

For teams building products, latency is no longer purely a network engineering concern — it's a product and architecture decision that shows up early in the design process.

• Measure the right thing. Average latency numbers hide the problem. The tail — the 95th or 99th percentile latency — is usually what determines whether users perceive an application as reliable, because it's the worst case that shows up often enough to notice.
• Decide what has to be synchronous. Not every operation needs a round trip in the critical path. Techniques like optimistic UI updates, local-first architecture, and asynchronous background processing can make an application feel instant even when the underlying network hasn't actually gotten any faster.
• Choose infrastructure geography deliberately. Where you deploy servers, caches, and edge functions relative to your actual user base has a direct, measurable effect on perceived performance — often a bigger effect than code-level optimization.
• Budget latency like you budget memory or compute. Interactive and real-time products benefit from setting an explicit latency budget per user action (for example: under 100ms for a UI interaction, under 300ms for a voice response) and treating each architectural decision as either spending or saving from that budget.
• Understand your protocol stack. Whether an application uses HTTP/1.1, HTTP/2, or HTTP/3/QUIC, and whether it's built on WebSockets versus repeated polling, has a real effect on round-trip efficiency, especially on mobile networks with variable signal quality.
• Plan for jitter, not just average latency. For control systems, real-time collaboration, and voice, consistency matters as much as speed — a connection that alternates between 20ms and 300ms is often worse than one that's steady at 100ms.

The following comparison illustrates how differently latency budgets play out across common application types:

The Real Limits: What Zero Latency Can't Mean

"Zero latency" is a useful rallying cry, but it's worth being precise about what's actually achievable, because a few hard limits aren't going away.

1. The speed of light in fiber is fixed. No protocol improvement, no amount of capital investment, and no clever engineering changes the roughly 200,000 km/s speed of light through glass. Any two points separated by real distance have a real latency floor. Global applications will always face an irreducible minimum delay between, say, Singapore and São Paulo.
2. The last mile is often the worst mile. Core network backbones have gotten remarkably fast and low-latency over the past two decades. The connection between an internet service provider's network and an individual home or device — over Wi-Fi, cellular, or older cable infrastructure — is frequently where most of the real-world delay and jitter actually lives.
3. Processing time is now a first-class contributor. As more requests involve a model performing inference rather than a server fetching a stored value, the "processing delay" term in the latency equation has grown, sometimes dwarfing the network delay entirely. A perfectly optimized network path is no help if the AI model on the other end takes 800ms to generate a response.
4. Cost and physics trade off against each other. Building denser edge infrastructure, laying straighter cables, and launching satellite constellations all reduce latency, but each is capital-intensive, and the marginal cost of shaving off the next 10ms typically rises steeply. There's a real economic ceiling on how close to the physical minimum most applications can afford to get.
5. Security and reliability add latency by design. Encryption handshakes, integrity checks, redundant routing, and DDoS protection all introduce processing overhead in exchange for safety. Some of the "waste" in real-world latency is actually a deliberate trade-off, not an oversight.

None of this means the effort is pointless — shaving the achievable overhead down toward the physical floor still produces meaningful, felt improvements in responsiveness. It just means "zero latency" is better understood as an asymptote the industry is approaching, not a destination it will reach.

What to Watch Next

A few developments are likely to shape how much closer we get to that asymptote over the next several years:

• Wider deployment of LEO satellite constellations for long-haul routes where a vacuum path can beat terrestrial fiber, particularly for underserved or geographically isolated regions.
• Continued rollout of edge inference for AI applications, as voice assistants, copilots, and agentic tools push more of their processing physically closer to users to hit conversational latency budgets.
• 6G research explicitly targeting sub-millisecond radio latency for industrial automation and haptic/tactile internet applications, building on 5G's low-latency ambitions but aiming at use cases like remote surgery and precision robotics that current networks can't reliably support.
• Protocol-level work beyond QUIC, including further reductions in handshake overhead and smarter multiplexing for the growing volume of real-time, bidirectional AI traffic.
• Better tooling for measuring and budgeting tail latency, as more product teams treat responsiveness as a first-class metric alongside uptime and error rate, rather than an afterthought discovered through user complaints.

The throughline across all of these is that latency improvements increasingly come from architecture and geography — where compute lives, how few round trips a protocol needs, how directly a signal can travel — rather than from a single breakthrough technology. The race to zero latency is really a race to remove every unnecessary delay between the physical floor set by distance and the actual experience a user or machine gets.

FAQ

What is a good latency for internet use?

For general web browsing, under 100ms feels responsive and under 300ms is generally acceptable. Real-time applications like video calls or online gaming need much lower numbers — typically under 150ms and under 50ms respectively — because delays above those thresholds become perceptible as lag or awkward pauses.

Why can't we just make the internet faster with more bandwidth?

Bandwidth determines how much data can move at once, while latency determines how long any single piece of data takes to make the round trip. Adding bandwidth doesn't shorten the physical distance a signal has to travel, so it does little to help latency-sensitive applications like gaming, voice AI, or video calls once you're past a baseline data rate.

What is the theoretical minimum latency between two points on Earth?

It's set by the speed of light traveling through fiber-optic glass, which is roughly 30-35% slower than light in a vacuum. For antipodal points on Earth (the maximum possible distance), that floor is well over 100ms round trip; for typical intercontinental routes like New York to London, it's roughly 55-60ms before real-world routing and hardware overhead is added.

Can satellite internet ever be lower latency than fiber?

For very long-distance routes, yes, in principle. Low-Earth-orbit satellites can route a signal through the vacuum of space, where light travels faster than it does through fiber-optic glass, and can sometimes take a more direct path than terrestrial cable routes. For most everyday, shorter-distance connections, fiber remains lower latency because ground infrastructure is already close to users.

How does 5G or 6G help with latency?

5G was designed with an "ultra-reliable low-latency communication" mode targeting single-digit-millisecond radio latency, well below 4G's typical range. 6G research is pushing this further, aiming at sub-millisecond radio latency to support applications like remote-controlled robotics and haptic feedback that need extremely tight, predictable timing.

What is edge computing and how does it reduce latency?

Edge computing places servers, caches, or AI inference closer to where users physically are, rather than centralizing everything in a small number of distant data centers. Since propagation delay is proportional to distance, moving processing physically closer to the request directly reduces round-trip time.

Why does latency matter more for AI applications than it used to for regular web apps?

Conversational AI and voice assistants operate in a tight feedback loop where a delayed response breaks the sense of a natural exchange, unlike loading a web page where a short pause is barely noticed. As more processing shifts to model inference rather than simple data retrieval, both network latency and model processing time now count against the same tight response budget.

Teams building latency-sensitive products — real-time AI, live collaboration, or anything with a tight feedback loop — can find hands-on architecture help through Woyce Technologies.