What Is Loaded Latency?

Idle latency and loaded latency are two different questions

Most speed tests answer one question about responsiveness: how quickly does a small message travel to a server and back when nothing else is happening? That figure is idle latency. It is genuinely useful, because it reflects distance, the technology your provider uses and the first few metres of your own network.

It is also the friendliest possible condition. Home connections are rarely idle. A phone is backing up photos, a laptop is pulling an update, someone is watching a film in another room. The question that matters in daily use is therefore different: how quickly does the connection respond while it is doing all of that?

Loaded latency

The round-trip response time measured while the connection is deliberately kept busy with a transfer. It is usually reported as the increase over idle latency, because that increase is what you notice.

The gap between the two numbers is the interesting part. A line that responds in 18 ms when idle and 26 ms when loaded behaves consistently. A line that responds in 18 ms when idle and 320 ms when loaded is, for practical purposes, two different connections depending on what else is running.

Why delay appears when the connection is busy

Every link in a network path has a maximum rate. When data arrives faster than a link can forward it, the excess waits in a queue. Queues are useful: a short one smooths out bursts and keeps the link fully used. The problem is a queue that is allowed to grow very long before anything pushes back.

Your own transfers are what fill that queue. A download pushes the narrowest point on the way into your home; an upload pushes the narrowest point on the way out. Once the queue is deep, a small, urgent packet — a keystroke in a remote session, a voice frame, a game input — has to wait behind everything already queued ahead of it. That waiting time is the extra delay you measure.

This is why raw capacity does not protect you. Filling a 500 Mbit/s link takes more data than filling a 50 Mbit/s link, but a modern device has no trouble filling either. What decides the outcome is how the equipment on the path manages its queue once it is full, not how large the number on your bill is.

Download-loaded and upload-loaded latency must be graded separately

Home connections are usually asymmetric: far more capacity downstream than upstream. The consequence is that the two directions saturate at very different points, and the queues that form are managed by different equipment.

Upload-loaded latency is the more common problem in practice. A cloud backup, a large email attachment or a video call's outgoing stream can fill a modest upstream link completely, and everything else you do then waits behind that queue — including the small acknowledgements that make your downloads work. It is entirely normal to see a connection that behaves well under download load and badly under upload load.

Reporting a single combined number would hide that difference, and the difference is exactly what points to the next step. Norynt therefore measures and grades each direction on its own, and reports them separately in your result.

How Norynt measures loaded latency

Norynt does not estimate loaded latency from throughput. While the Measurement Lab NDT7 transfer is running, a separate stream of small timing probes runs alongside it, off the main browser thread, and records how long each round trip takes during that phase.

Those probes are then compared with the idle baseline collected before the transfer began. The reported figure is the increase over that baseline, in milliseconds, for the download phase and for the upload phase.

Probes are only counted when they are trustworthy. A probe that was delayed because the browser tab itself was busy, or one that was answered by a rate-limited service, describes your computer or the measurement service rather than your connection, so it is discarded. If too few valid probes remain for a phase, Norynt reports the figure as unavailable instead of publishing a weak number.

An unavailable loaded-latency result is not a bad result. It means the run did not collect enough trustworthy timing samples, usually because the tab lost focus or the device was under heavy load. Running the test again in a foreground tab normally resolves it.

How Norynt grades the increase

The grades below describe how much delay a busy connection adds compared with the same connection when idle. They are applied to each direction separately.

These grades describe measured behaviour during your test. They do not identify a responsible device, and they are not a verdict on your provider or your router.

What can produce a high figure

Several conditions produce a similar pattern, which is why Norynt presents them as ranked hypotheses rather than conclusions:

• Another device or application was transferring data during the test, so the line was already partly full.
• The upstream or downstream link reached its limit and the queue in front of it grew unmanaged.
• Equipment on the path buffers aggressively and has no queue management enabled.
• A Wi-Fi link between your device and the router became the constrained point rather than the internet connection itself.

Distinguishing between them requires changing one condition and measuring again — which is what the verification steps below are for.