Network Latency: what it is, how it is measured and how to reduce it

Introduction

Is there anything worse than “having no Internet”? Yes: the connection becoming painfully slow and reloading the page, resending the request to the server, eventually seeing the frustrating blank response… At least, when there is no connection, you can accept it and go do something else other than doomscrolling. But when the network crawls through the mud, the main suspect is latency, and today we will take a close look at it.

We will see what it is, its causes, how to measure it and how to monitor this key indicator, in addition to recommendations on how to reduce it as much as possible.

Let’s begin by knowing the enemy.

What is network latency and why is it important?

Network latency is the time it takes for a data packet to travel from its source to its destination, and to receive a confirmation back (what in telecommunications is called Round-Trip Time (RTT) or Round-Trip Delay (RTD) when we talk about signals in general). Latency is measured in milliseconds (ms) and is critical because:

• It determines the responsiveness of real-time applications (VoIP, video conferencing, trading, apps the organization uses to work…).
• It is one of the keys to user experience. For instance, latency above 100 ms is perceived as slow in interactions with network services, triggering a parade of support tickets with increasingly colorful language.
• It impacts the performance of distributed systems: Microservices, clustered databases or cloud environments accumulate delays on each network call. Today, many organizations have switched from local applications to network-based or cloud-based ones, and reduced latency is key for user productivity.
• It influences SLA (Service Level Agreement) compliance: Exceeding agreed thresholds can lead to penalties or loss of customer trust — they hired us because we promised speed, but we delivered snails.

That is why latency is a critical variable for efficient digital services.

Types of latency in IT: network, storage, application and more

Let’s dive deeper into the different features of latency, starting with the one most commonly associated with the term today, as I did at the beginning of the article.

Network latency

This is the most common latency an IT administrator will want to check to ensure user work is productive and they can quickly access the network resources they need, whether files or network applications. This latency can be checked, for example, with a ping command from a terminal.

ping 8.8.8.8
64 bytes from 8.8.8.8: icmp_seq=1 ttl=119 time=22.0 ms

If we look at the last part, the time variable gives us a value in ms showing that latency — the time the ICMP packet took to go to the destination and return. In this case, 22 ms.

The importance of jitter

Now, this is not the only interesting indicator about latency issues or analysis, because jitter can also be checked. This concept measures variation in latency. If some packets take 20 ms and others take 80 ms to arrive, that variation (±60 ms) is jitter in general terms, which may be the cause for choppy voice in calls or video cuts when it is high. That’s why we must consider not only pure latency when analyzing and optimizing the network, but also the consistency of those speeds.

The ping command is also useful to determine this key indicator. In the last line of the terminal output of the test we ran earlier, we see:

rtt min/avg/max/mdev = 14.878/19.205/21.955/3.097 ms

This shows, in order: the minimum latency, the average, the maximum recorded in the ping packets and that final mdev (mean deviation), which would be jitter. In this case, it remains low, indicating that latency is fine and also stable, with only about 3 ms deviation on average between packets.

Those who dislike staring into the darkness of the terminal because it reminds them of their future need not worry — we will see simpler and more visual tools to monitor latency and jitter.

Obviously, when we talk about network latency, one of the most direct ways to reduce it is by using a wired connection, which will keep it between 1–10 ms if everything works well. WiFi or 5G, on the other hand, can often exceed 30 ms of latency due to interference.

Storage latency

Here we refer to disk access time. Older HDDs used to record about 5–10 ms in their spinning ballet, while SSDs range between 0.1–0.5 ms. This latency affects databases and file systems, for example on your local machine.

Application latency

In this case, we talk about delays in software processing. For example, poorly optimized APIs or Java garbage collection can increase these times, making you desperate when using the application.

Server latency

This refers to the response time of a server, such as a web server (known as Time To First Byte – TTFB). Ideally under 200 ms. But if that brand-new AI startup — essentially just another ChatGPT wrapper — uses a Raspberry Pi Zero to host its page, it won’t matter how fast your connection is, because the server will add that latency. This shows that such latency is not always a problem of bandwidth with our ISP or network configuration, but there may be other culprits.

Main causes of latency

When we encounter latency problems in the network, we need to solve them, and then begins the game of Clue to find the culprit (or culprits, because IT life tends to be complex and we should not dismiss multifactorial reasons). Thus, the main causes of latency are usually:

If your Internet provider is a disaster — because those 600 Mbps for 5 euros were not such a good deal after all — they are probably working with obsolete hardware and/or have congestion issues.

How to measure latency: tools and key metrics

Since we cannot manage what we do not measure, the first thing is to monitor that latency in our network, which we can do with:

Terminal tools to measure latency

Here we have the ping command we have already seen. If we want deeper diagnostics, we can use the traceroute tool, run from a Linux/Unix terminal, or the tracert command from Windows PowerShell. This way, we not only get general latency information, but also latency for each hop that the packet takes until it reaches its destination.

However, it’s important to note that we should first use ping for general latency and, if we don’t like the results or want to know where packets are delayed, use traceroute / tracert. The way this tool works — especially without specific options — can result in higher latency values than ping, since its job is to explore hops and send multiple packets, not just one.

traceroute -I -n 8.8.8.8

This makes the tool “linger” less by sending ICMP packets (-I option, same type as tracert) and not resolving IP addresses (-n). In summary: ping to know latencies, and if they are not good, traceroute to investigate problematic hops.

How to measure server latency from the terminal

If we want to show off as terminal wizards and measure server latency with Time To First Byte (TTFB), we can do it with the curl tool in Linux/Unix.

curl https://google.com -w "TTFB: %{time_starttransfer}"

This returns the page’s HTML code and, at the end, something like this appears — the output I just got from my machine:

TTFB: 0.594890

So we know the latency until the server sends us the first byte.

GUI tools to measure latency

If the terminal is intimidating, no problem, there are several visual tools for analysis. My favorite not called Pandora is Pingnoo, open source (as we like here) and available for Windows, Linux, and macOS. With it, we can analyze latency and visually examine the results.

The point is, latency values alone are limited. It’s an indicator to monitor so that our network and services run smoothly, but it’s not the only thing to consider. In any minimally complex organization, using a separate tool for each analysis creates information silos that don’t communicate or provide a global view of the IT infrastructure. A global perspective is essential, and that’s why you can measure latency and much more with Pandora FMS.

Monitoring and diagnosing latency with Pandora FMS and Pandora MINI

Pandora FMS is the global monitoring system of our technological empire and, of course, you can measure latency, in addition to always having history and aggregated data in a single control panel — so you feel like Captain Kirk at the helm of the Enterprise. With Pandora FMS, everything we have seen can be done without writing arcane spells in the terminal, allowing, for example:

• Remote monitoring: with basic ICMP tests to check whether the host is online and its latency, as well as other tests like TCP and SNMP.
• Web monitoring: which enables multiple tests, such as the Remote HTTP module to check latency, without having to fiddle with curl. You’ll know latency, load times, server status codes…
• Custom alerts: to be notified right away when something is wrong and, for example, puts SLAs at risk.

In the end, latency is not a whim, it is a tool for control and optimization, and having an integrated tool like Pandora FMS enables a much broader and faster capacity to manage that optimization and diagnose issues. Moreover, it provides history data, custom dashboards, and everything we’ve always wanted to feel in control of at least one aspect of our life.

Diagnosing latency with Pandora MINI

If you want something free and simple, but also capable of visually controlling latency and network/server states, there is Pandora MINI, the 100% free tool for Windows that you can download HERE. It is not as powerful as its big sister, but MINI shares its DNA and skills, so we can add to our MINI main screen the services to monitor (such as internal or external servers), so we will see whether they are online and with what latency, in a colorful and visual way.

That’s not all, since we can also analyze latency issues in more detail with:

• Its jitter calculation: found in Monitoring > Jitter.
• Integrated Traceroute to take a closer look at possible issues, available in Tools > Traceroute.
• And much more, like WHOIS queries or an integrated dashboard.

That way, you can control simple infrastructures or diagnose issues without complex installations or configurations on the machines.

Impact on performance and user experience

Latency is probably the number one cause of bulging veins on foreheads. When it rises, user experience falls, leading to:

• VoIP/video calls: latency above 150 ms causes echo and desynchronization.
• Streaming: the dreaded buffer keeps spinning, with problems from jitter above 50 ms.
• Online gaming: those extra milliseconds are why that 11-year-old kid gave us 10 headshots in a row and laughed in the chat (choppily).
• Industrial IoT: high latency can lead to critical failures.
• Cloud/SaaS: using online apps with high latency causes productivity drops and user tickets that aren’t exactly love notes.

How to reduce latency: practical strategies

We now know almost everything about the enemy but, how do we defeat it? The table of causes earlier gave us some clues, and here are the main strategies to reduce latency. You can use them as a checklist to see what applies to your particular IT infrastructure:

• Edge Computing: The buzzword that sounds like a movie title and describes processing data closer to where it is produced, instead of sending it all to a central server that may be further away, adding latency. In processes where speed is critical (such as retail or industry, for example), it’s an option to consider.
• CDNs (Content Delivery Network): Serving static content from local or nearby nodes, reducing distance. There are also newer solutions for dynamic content.
• Caching: Caching solutions at application, database, or network level can significantly reduce latency for information that doesn’t change frequently. Beware of serving outdated content, though.
• Network segmentation: Creating VLANs for critical traffic (voice, video).
• Hardware upgrades: So that, budget permitting, we have high-performance devices.
• Proper protocols: Using HTTP/2 or QUIC can shave off some time.
• QoS policies (Quality of Service): Prioritizing critical traffic on routers.
• Direct connections: Using BGP to determine optimal routes between autonomous systems on the Internet.
• Load balancing solutions: Implementing such solutions helps distribute traffic evenly across multiple servers, avoiding bottlenecks.
• Data optimization and compression: Whenever possible without hurting user experience, such as excessive decompression workload on older machines.
• Provider SLAs: Validate and secure guarantees of optimal service levels, with possible measures and compensation if not met.
• And of course, constant and global monitoring. In many cases, latency will be temporary, but we must address it as quickly as possible.

As we can see, latency has a lot to it, but that’s because it’s responsible for many of those support tickets so “informative” that simply say “the network is down.” With proper optimization and a monitoring and alerting system that allows us to address problems and bottlenecks, users will love us for how quickly things work. Until another part of the infrastructure fails, but that’s life in IT.