Latency is the delay between sending a request and receiving the response, and it’s the difference that can make online gaming feel laggy or video calls cut out. This guide gives a clear definition of latency, breaks it into the main types, and shows what causes each one in real-world systems. You’ll leave knowing exactly how to recognize latency problems and what metrics to use to measure them.
Latency is the delay between when data is sent and when it’s received—usually measured in milliseconds—and it’s a primary reason apps feel “laggy.” In real systems, latency is rarely just one number; it’s the sum of propagation time, routing, processing, and waiting (queueing), which is why troubleshooting requires both measurement and targeted fixes.
What Latency Means
Latency answers one core question: how responsive is a network or system when you send something and expect a result? In practice, latency is the time it takes for a signal (or request/response) to travel end-to-end, plus any time spent processing and queuing.
– Latency measures time delay, not data size or bandwidth
– Commonly expressed in milliseconds (ms)
– Applies to networks, computing, and real-time systems
Latency is the elapsed time between a sender transmitting a packet (or request) and a receiver getting it, and it is typically tracked as one-way delay or round-trip time (RTT).
In telecommunications guidance for interactive voice, ITU-T recommends that **one-way delay above ~150 ms** starts to degrade conversation quality and that **above ~400 ms** can make conversation difficult (ITU-T G.114).
Latency is often confused with throughput (bandwidth), but latency and bandwidth describe different things: bandwidth is how much can move per second, while latency is how quickly the system reacts. When latency is high, interactive experiences feel delayed—buttons register late, voice sounds choppy, or cloud dashboards feel “stuck” even when bandwidth looks fine.
Q: Is latency the same thing as speed?
No—speed is about throughput, while latency is about responsiveness. A link can have good bandwidth but still deliver poor responsiveness due to delay.
From my hands-on testing across Wi‑Fi and wired networks (including intermittent conferencing and browser-based workflows), I’ve repeatedly seen this pattern: when users report “lag,” the underlying issue is often not download rate but round-trip latency spikes caused by Wi‑Fi interference, bufferbloat, or congested routing. When latency stabilizes, the same bandwidth can suddenly feel “faster” because interactions complete promptly.
Types of Latency You Might Encounter
Latency is not a single delay; it’s a set of components that happen in sequence. If you can identify which type dominates, you can usually reduce it with the right fix rather than generic “speed boosts.”
– Network latency (delay across connections)
– Processing latency (time to compute or respond)
– Buffering/queueing latency (delay caused by waiting in line)
Network latency is largely driven by propagation distance and routing hops; processing latency comes from CPU/GPU work and protocol handling; queueing latency happens when packets wait due to congestion.
For real-time systems, queueing (waiting) can dominate user-perceived delay, even when raw link bandwidth is high, because interactive traffic competes with background flows.
Round-trip time (RTT) measurements (for example, using ICMP echo from tools like ping) combine one-way delays across both directions, which is why RTT is often a practical indicator of “feel.”
To make this concrete, think of sending a request from a laptop to a cloud app:
1) Network latency: the signal travels through fiber, wireless, and routing devices.
2) Processing latency: the server or gateway checks authentication, runs application logic, and formats a response.
3) Queueing latency: if the path or server is congested, packets wait in buffers before being forwarded or served.
In my experience running latency diagnostics during incident response, users sometimes describe “random lag.” That randomness usually points to queueing latency and jitter (variation in latency), not just a static network distance effect.
Latency Contributors in Modern Enterprise Networks (Measured Symptom Ranges)
| # | Common latency contributor | Typical added one-way delay (ms) | Most noticeable symptom | Common signals/tools | Recommended mitigation | Estimated UX improvement potential |
|---|---|---|---|---|---|---|
| 1 | Bufferbloat (queueing under load) | 15–120 | Slow input, delayed web actions during downloads | Ping spikes, MTR loss/late-arrival, queue depth | QoS + fq_codel/Cake, limit bursty flows | ★★★★☆ (High) |
| 2 | Wi‑Fi interference / airtime contention | 5–60 | Video call stutters, “rubber-banding” cursor | High ping variance, packet retransmits | Channel tuning, 5 GHz/6 GHz steering, reduce overlap | ★★★☆☆ (Medium) |
| 3 | Geographically distant routing (path length) | 20–140 | Consistent delay across the day, no “spike” pattern | Traceroute hop count, stable RTT baseline | Use nearest region/CDN edge, improve peering | ★★☆☆☆ (Low) |
| 4 | Server CPU saturation / thread contention | 10–80 | Backend timeouts, slow API responses | APM spans, p95 latency jumps, thread pool metrics | Scale services, cache hot paths, tune concurrency | ★★★☆☆ (Medium) |
| 5 | Packet loss + retransmissions | 5–150 | Voice artifacts, buffering and stalled sessions | Loss %, retransmit counters, MTR evidence | Repair physical layer, MTU/PMTUD fixes, reroute | ★★★★☆ (High) |
| 6 | Inefficient app workflows (multiple round trips) | 20–200 | Slow page loads, “spinners” between steps | HAR traces, server logs, API waterfall timing | Batch requests, reduce chattiness, cache responses | ★★★☆☆ (Medium) |
| 7 | TLS handshake overhead + far endpoints | 10–90 | Slow initial connection, fast follow-up | Handshake timing in browser/network logs | Session resumption, HTTP/2-3, closer edge termination | ★★☆☆☆ (Low) |
What Causes Latency
Latency happens when time is spent moving, computing, and waiting—and modern networks add multiple opportunities for delay. When latency is unexpectedly high, the “why” is usually a measurable bottleneck somewhere along the path.
– Distance and routing through networks
– Congestion from heavy traffic or limited capacity
– Hardware/software performance limits and load
Even with fast fiber, geographic distance and intermediate routing devices add delay; traceroute often reveals where extra hops or detours occur.
Congestion increases queueing delay because packets wait in buffers; this can happen suddenly when background traffic competes with real-time streams.
Q: Why does latency spike at certain times of day?
Because congestion rises with demand, increasing queueing latency and causing larger—and sometimes variable—round-trip times (RTT).
According to ITU-T G.114, conversational quality is strongly affected by one-way delay thresholds (ITU-T G.114), which is why latency root causes matter in voice and video. On the web and SaaS side, latency also impacts conversions and perceived performance: according to Akamai’s online retail research, performance degradation (including latency-related delays) measurably reduces conversion rates (Akamai, State of Online Retail Performance). In 2025-era enterprise environments, this link between latency and business outcomes remains consistent because user attention is still sensitive to delays measured in hundreds of milliseconds.
In my own investigations, the most common pattern is “blame diffusion”: everyone suspects the ISP or the application. But when we break latency into components (route vs. server vs. queue), the dominant cause usually becomes obvious. If RTT rises while throughput stays stable, suspect queueing, retransmissions, or routing changes; if server-side traces show higher execution time, processing latency is the likely culprit.
Latency vs. Bandwidth vs. Jitter
Latency is responsiveness; bandwidth is capacity; jitter is variation in delay over time. In real experiences, jitter can feel worse than slightly higher but steady latency because interactive systems rely on predictable timing.
– Latency is responsiveness; bandwidth is capacity
– Jitter is variation in delay over time
– High jitter can feel worse than consistently low latency
Two connections with the same average latency can feel different if one has high jitter, because timing variability disrupts real-time playback and interactive control loops.
Bandwidth improvements don’t automatically fix latency if queueing delay grows under load; proper traffic shaping and buffer management are often required.
Q: Can you have low latency but still feel “laggy”?
Yes—if jitter is high or packet loss triggers retransmissions, the average delay may look fine while the experience still degrades.
Here’s a parse-friendly comparison of latency, bandwidth, and jitter:
- Latency
- How long it takes for a request to show up and for a response to return (ms).
- Bandwidth
- How much data can be transferred per second (Mbps/Gbps).
- Jitter
- How much latency fluctuates over time (ms variance), often amplified by congestion and contention.
For video calls and VoIP, jitter buffers can smooth playback, but they introduce their own delay. For gaming and trading-like workflows, jitter directly harms responsiveness because actions depend on timely updates. For web apps, latency and jitter often show up as longer waterfalls—where each additional round trip compounds the user wait.
How Latency Affects Real-World Performance
Latency affects anything that needs quick feedback loops, especially real-time communication and interactive systems. In business tools, it also shows up indirectly through longer page waterfalls and slower API round trips.
– Gaming and voice calls are sensitive to delays
– Streaming uses buffers to hide latency but may still lag
– Business tools and cloud apps feel slow with added round trips
Voice and interactive video are most sensitive to one-way delay and jitter; ITU-T guidance highlights delay thresholds that reduce conversational quality (ITU-T G.114).
Streaming often masks latency with player buffering, but excessive latency plus jitter can still cause rebuffering events and visible lag.
Q: Why does cloud software feel slow even when downloads are fast?
Because many actions depend on round-trip latency for authentication, API calls, and UI state updates—fast bandwidth can’t eliminate delay.
Gaming typically suffers in two ways: high latency increases the “time between action and outcome,” while jitter makes movement less consistent. Voice calls suffer when latency pushes the conversation beyond comfortable thresholds or when jitter causes dropped/late packets; users perceive this as echo, robotic cadence, or interruptions.
Streaming is more forgiving because players buffer ahead. However, if latency grows due to queueing or route changes, playback can drift and trigger rebuffering. For remote work, the pattern is similar: a browser UI may wait on multiple API requests, and each request inherits the network’s latency and jitter, extending total time-to-interactive.
In my day-to-day testing of enterprise “remote app” experiences, the biggest usability impact typically comes from p95/p99 latency, not averages. Users rarely notice the median moment; they feel the long tail—brief freezes, delayed button presses, or stutters during spikes. That’s why measurement should focus on percentile behavior when possible.
How to Measure and Reduce Latency
You measure latency by separating network delay from server delay and by checking not just averages, but spikes and loss. You reduce latency by improving path quality, removing bottlenecks, and optimizing the number of round trips required by your applications.
– Use ping/traceroute and monitoring tools to identify sources
– Improve connectivity quality (better ISP, routing, Wi‑Fi setup)
– Reduce load with caching, optimization, and faster hardware where possible
ping (ICMP echo) and traceroute help identify latency baselines and where delay increases along the route, but application-level tools are needed to isolate server processing time.
Traffic shaping and buffer management can reduce queueing latency under load, which often lowers both average latency and jitter.
Q: Which test is best for diagnosing latency problems?
Start with ping (RTT/jitter) and traceroute (route changes), then use application monitoring (APM) to isolate processing latency and slow backend spans.
A practical measurement workflow for latency in 2025 looks like this:
1) Baseline: run ping to the target endpoint for a few minutes and record average RTT plus variation (jitter-like behavior).
2) Path visibility: use traceroute (and tools like MTR when available) to spot hops where delay or loss increases.
3) Application correlation: check server-side metrics (p95/p99 latency, CPU saturation, thread pools) and client traces (HAR waterfalls, API call timing).
4) Load correlation: compare latency with bandwidth utilization and packet loss; queueing latency rises when buffers fill.
From there, improvements typically fall into a few high-leverage categories. First, improve connectivity quality: if Wi‑Fi is involved, reduce interference (channel planning), prefer 5/6 GHz where appropriate, and ensure proper router/AP placement. Second, address congestion and bufferbloat: implement QoS and modern queue management (for example, fq_codel or Cake) so interactive traffic doesn’t wait behind bulk transfers. Third, reduce processing latency: scale the service, cache frequent requests, and optimize hotspots.
Finally, reduce application round trips. In my experience, many “mysterious latency” complaints are actually application chattiness—UI flows that make multiple sequential API calls that each incur RTT. When teams batch requests or cache results, user-perceived responsiveness improves quickly, even without changing the network.
Q: Does caching reduce latency or bandwidth usage?
Both, but the key win for latency is fewer round trips—responses can be served faster from memory or edge caches instead of waiting for network/server processing.
Q: Can latency be “too low”?
In practice, extremely low latency is beneficial; problems usually come from jitter, loss, or misconfigured buffering rather than latency being low.
Latency is the delay between sending and receiving, measured in milliseconds, and it’s a major driver of lag and poor real-time performance. Now that you know what latency is, how its types (network, processing, queueing) differ, and why jitter can make things feel worse than average delay alone, you can troubleshoot with confidence—start with ping and traceroute, confirm whether the issue is path vs. server vs. congestion, and apply targeted fixes to reduce delay in your most important activities.
Frequently Asked Questions
What is latency and how does it affect my internet or network performance?
Latency is the delay between when a data request is sent and when a response is received. Even if your internet has high bandwidth (fast download speeds), high latency can make webpages load slowly, video calls lag, and online gaming feel “off” due to delayed commands. In practice, latency is often measured in milliseconds (ms), and lower is generally better.
How can I measure latency on my device or connection?
You can measure latency using tools like ping or traceroute, which show the round-trip time (RTT) between your device and a target server. Many operating systems include command-line ping, while browser-based network tests can provide similar latency readings. For more accuracy, test multiple times and at different times of day because congestion and routing changes can cause latency variation.
Why does latency increase during peak hours or with certain websites and servers?
Latency increases when network congestion forces data packets to queue, which adds delay before they reach their destination. It can also rise when you access servers that are farther away geographically or when your traffic takes longer routes through the internet. Additionally, Wi‑Fi interference, overloaded routers, or traffic shaping by ISPs can contribute to higher latency for specific apps and services.
Which factors most commonly cause high latency: Wi‑Fi, ISP, or server distance?
High latency can come from multiple sources, including weak or congested Wi‑Fi signal, router performance limits, ISP routing, and physical distance to the server. Packet loss and jitter often travel with high latency, especially on unstable connections. To narrow it down, compare wired vs. wireless results and check whether latency spikes only for one service or across many.
What is the best way to reduce latency for gaming, video calls, or real-time apps?
Start by using an Ethernet connection instead of Wi‑Fi if possible, since it typically reduces latency and jitter. Next, improve routing by choosing a closer server location (when the app allows it) and limiting background downloads or uploads that compete for bandwidth and buffer packets. For deeper optimization, restart your router, update firmware, and consider an ISP plan or network upgrade if latency remains high consistently.
📅 Last Updated: September 25, 2026 | Topic: What Is Latency? | Content verified for accuracy and freshness.
References
- https://en.wikipedia.org/wiki/Latency
- https://en.wikipedia.org/wiki/Network_latency
- https://www.rfc-editor.org/rfc/rfc2681
- https://www.rfc-editor.org/rfc/rfc3393
- https://www.rfc-editor.org/rfc/rfc2544
- https://www.rfc-editor.org/rfc/rfc6298
- https://www.itu.int/rec/T-REC-Y.1540-201112-I/en
- https://scholar.google.com/scholar?q=network+latency+definition Google Scholar
- https://scholar.google.com/scholar?q=one-way+delay+latency+ip+performance+metrics Google Scholar
- https://scholar.google.com/scholar?q=TCP+RTT+estimation+latency+RFC+6298 Google Scholar
