Latency is the delay that occurs when data travels from one point to another across a network, measured in milliseconds. It’s caused mainly by physical distance, and no amount of bandwidth can eliminate it once the distance is fixed.

For most everyday browsing, a little latency goes unnoticed. But for real-time applications, fraud detection engines, telehealth platforms, industrial control systems, and live video, even small delays translate directly into lost revenue, degraded user experience, or safety risk. Understanding where latency comes from, and how to architect around it, has become a core infrastructure decision rather than a networking afterthought.

What Is Latency, Exactly?

Latency is the time it takes for a data packet to travel from its source to its destination. Technically, this one-way measurement is what engineers call latency in the strictest sense.

In practice, most teams talk about round-trip time (RTT): the total delay from the moment a user’s device sends a request until it receives a response. RTT is the number that actually determines what a user experiences, so it’s the more useful figure for planning infrastructure.

Latency is different from bandwidth. Bandwidth measures how much data a connection can carry at once, like the width of a pipe. Latency measures how long it takes any single piece of data to travel through that pipe, start to finish. A connection can have enormous bandwidth and still suffer from high latency if the physical path is long or congested.

What Causes Network Latency?

Four factors combine to create the latency a user or application experiences:

• Physical distance: data can only travel as fast as the speed of light allows, so the farther it travels, the longer it takes. This is the single biggest driver of latency and the one variable infrastructure decisions can most directly control.
• Network hops: every router, switch, or intermediary system a packet passes through adds a small amount of processing delay. A path with fewer hops is almost always faster than one with more, even over the same distance.
• Congestion: shared, public internet paths route traffic alongside millions of other users. When a link is congested, packets queue up and wait, adding delay that a private connection wouldn’t have.
• Transmission medium: fiber-optic connections carry data faster and more consistently than older copper or wireless links, though even fiber is bound by the same distance limits as everything else.

Because distance is the dominant factor, the most durable way to reduce latency is to physically shorten the path data has to travel, not simply add more bandwidth to a long path.

Latency vs. Bandwidth: Why More Bandwidth Doesn’t Solve a Latency Problem

It’s a common assumption that upgrading to a bigger internet connection will fix slow application performance. In many cases, it won’t.

Network engineers describe true throughput using the bandwidth-delay product, which is bandwidth multiplied by latency. A sending system waits for acknowledgment from the receiving system before pushing more data. If that acknowledgment takes 50 milliseconds instead of 20 milliseconds, the connection can’t use its full bandwidth no matter how large the pipe is.

Consider two connections with identical 100 Mbps bandwidth. One has 50 ms round-trip latency; the other has 20 ms. The lower-latency connection will consistently deliver higher real-world throughput, because less time is lost waiting for acknowledgments. This is why a company troubleshooting slow application performance should look at latency and route quality first, not just bandwidth.

How Much Latency Is Too Much? Thresholds by Use Case

Latency tolerance depends entirely on what the application is doing and who, or what, is on the other end.

Human-to-machine applications, like loading a webpage or streaming a video, tend to tolerate more latency because human reaction time is already slower than the network. Machine-to-machine applications, where systems act on data in real time, have far less room for delay.

• General web browsing: users notice delay above roughly 200 to 300 ms round-trip; below that, pages feel responsive.
• Video conferencing and VoIP: quality degrades noticeably above 150 ms RTT, with audible lag and talk-over becoming common.
• Cloud gaming and interactive applications: most providers target under 50 to 80 ms RTT to avoid visible input lag.
• Real-time fraud detection and financial transactions: decisioning systems often require single-digit-millisecond response times, since a delayed decision can mean a missed fraud signal or a lost trade.
• Industrial automation and IIoT: closed-loop control systems on a factory floor frequently require latency under 10 ms to keep machinery synchronized safely.
• Telehealth and remote diagnostics: real-time imaging and remote-monitoring platforms need consistently low, predictable latency to avoid diagnostic delay.

Real-World Use Cases Where Latency Determines Performance

Latency isn’t an abstract network metric. In several industries, it’s the difference between a system that works and one that fails at the exact moment it matters most.

• Financial services: high-frequency trading and real-time fraud-scoring platforms depend on being close to exchange infrastructure and payment networks, because pricing and risk signals can change within milliseconds.
• Healthcare: remote patient monitoring, telehealth video, and diagnostic imaging platforms all depend on consistent, low-latency connections between clinical sites and cloud or colocation infrastructure to avoid degraded video or delayed data transfer.
• Manufacturing: as plants adopt Industrial IoT and connect sensors, PLCs, and robotics to cloud analytics, the compute processing that data needs to sit close enough to the plant floor to act on it in real time, not just collect it.
• Media and streaming: live sports, breaking news, and major broadcast events create simultaneous concurrency spikes that only geographically distributed, low-latency infrastructure can absorb without buffering.

How to Reduce Latency: A Practical Framework

Reducing latency requires addressing both the technology carrying the data and the physical distance it has to travel. Neither one alone is enough.

• Choose private interconnection over the public internet. Public internet traffic shares congested, indirect paths with millions of other users. A private, direct connection between two points, sometimes called a cross-connect, avoids that congestion and takes a more predictable route.
• Reduce network hops. Every router a packet passes through adds delay. Interconnecting directly with cloud providers, carriers, and partners inside a shared facility removes unnecessary hops compared to routing everything through a single, centralized data center.
• Move infrastructure closer to users and data sources. This is the only way to address the distance component of latency, which no amount of network optimization can fully eliminate. Deploying compute in regional or edge-adjacent facilities near the people and systems generating the data shortens the physical path.
• Use a hybrid architecture. Keep latency-sensitive workloads, such as fraud detection, real-time analytics, and industrial control, close to where the data originates, while using centralized cloud regions for workloads that can tolerate more delay.

How DataBank Helps Reduce Latency

DataBank operates carrier-neutral data centers across 70+ facilities in 25+ U.S. markets, giving enterprises the ability to place compute closer to end users, partners, and cloud regions instead of routing everything through one distant, centralized site.

Inside DataBank’s interconnection marketplace, customers connect directly to cloud on-ramps, network carriers, and business partners over private cross-connects instead of the public internet, cutting out the congestion and unpredictable routing that add latency to shared connections.

For latency-sensitive workloads, financial transaction processing, healthcare data exchange, manufacturing IIoT, and real-time analytics, this combination of geographic proximity and direct interconnection is what turns a theoretical latency budget into a consistently met one. Instead of trying to out-engineer distance with more bandwidth, enterprises can shorten the distance itself.

Conclusion

Latency will never reach zero, but it doesn’t need to. The goal isn’t eliminating delay; it’s reducing it to the point where it no longer limits what an application can do.

That starts with an honest look at where your infrastructure sits relative to your users, your cloud providers, and your data sources, and whether your network path is public and congested or private and direct.

Talk to a DataBank solutions engineer about mapping your current latency footprint and identifying where proximity and interconnection could close the gap.