Idle latency
Useful as the quiet baseline. It shows the fastest response the current device, local network and route can deliver without meaningful traffic pressure.
Responsiveness under load
What Is Loaded Latency?
Loaded latency measures how long data takes to respond while the broadband connection is actively downloading, uploading or serving other devices. It reveals delay that a quiet ping result can hide.
Quick answer
Loaded Latency Is the Delay Added While the Connection Is Busy
Idle latency is measured while little or no traffic is using the line. Loaded latency is measured while download or upload traffic is active. The difference between the two values is the loaded-latency increase.
Loaded latency
Useful for real household conditions. It shows whether games, calls and browsing remain responsive while transfers and other devices compete for capacity.
Loaded-latency increase = busy ping − idle ping
Calculate Your Responsiveness Loss Under Load
Enter your quiet and busy ping. The percentage shown is the relative latency increase from idle—not a loss of download capacity.
Latency Delta— ms
Increase vs Idle—%
Diagnostic Status—
Enter valid values. Busy loaded ping must be equal to or higher than idle ping.
Result-led diagnosis
Match the Loaded-Latency Pattern to the First Useful Check
This table combines the symptom, likely layer and next comparison so the page does not repeat separate Issue, Validation and Fix sections.
| What the Test Shows | Most Likely Layer | First Useful Check |
|---|---|---|
| Idle ping is low, but both wired download and upload load create a large rise | Router or access-path queueing. The connection remains fast when quiet but loses responsiveness when capacity is filled. | Repeat with household traffic paused, then compare the upload and download phases separately. Use the bufferbloat explainer for queueing theory. |
| Ethernet remains stable, but Wi-Fi adds a sharp loaded-latency jump | Local Wi-Fi airtime. Retries, interference, weak signal or mesh backhaul are adding delay before traffic reaches the broadband line. | Keep Ethernet as the control and retest in the problem room near and far from the access point. |
| The upload phase is much worse than the download phase | Upstream saturation. Background cloud sync, CCTV, livestreaming or file sending may be filling the smaller upload path. | Pause upload-heavy tasks and compare the available upstream capacity with the package benchmark. |
| The same wired test becomes worse at similar evening times | Shared or provider-side capacity. The bottleneck changes by time of day rather than by room or device. | Repeat identical wired tests on at least two days and retain the time, idle ping, loaded values and packet-loss result. |
| Only one device is poor in the same room | Client processing or software. CPU load, VPNs, browser extensions, security scanning or adapter behaviour may be delaying the test locally. | Compare a second device using the same connection and browser conditions before changing the router. |
| Periodic spikes persist over Ethernet across several devices | Gateway hardware, firmware or external route. The problem is no longer isolated to Wi-Fi or one client. | Record the hub model, firmware, timing pattern and a direct wired comparison before provider escalation or hardware replacement. |
Measurement matrix
Loaded-Latency Test Ranges and Diagnostic Meaning
Use these comparisons as practical indicators rather than universal guarantees. Repeat the same method before treating one result as proof.
| Testing Phase | Healthier Result | Degraded Boundary | Immediate Diagnostic Indication |
|---|---|---|---|
| Quiet idle baseline | Low and repeatable | Already high or unstable | An unstable idle result means the first problem may be baseline routing, Wi-Fi, signal quality, packet loss or device load rather than traffic pressure. |
| Wired Ethernet under load | Delta around 5 ms or less | Delta above 25 ms | A high wired delta points towards router queueing, upload saturation, gateway hardware or an oversubscribed external path. |
| Wi-Fi under load | Close to wired control | Sharp rise above wired | A Wi-Fi-only increase indicates local airtime contention, retries, weak coverage or mesh/repeater backhaul constraints. |
| Upload-loaded phase | Similar to download load | Largest phase increase | The upstream path is likely filling first. Check cloud sync, CCTV, file sending, livestreaming and other active uploads. |
| Peak-time wired comparison | Close to quiet-hour result | Repeatable evening rise | A time-of-day pattern that remains over Ethernet supports shared provider capacity or routing congestion rather than a room-specific Wi-Fi fault. |
Controlled comparison
Run the Six-Step Loaded Latency Check
Keep the same test device and change one variable at a time so each comparison answers a specific question.
- Run a baseline loaded-latency test.
Record idle ping plus separate download-loaded and upload-loaded values. Use the LinkSpeed loaded latency test with background traffic noted.
- Compare Ethernet with Wi-Fi.
Repeat the same test over a direct cable. A healthy wired result with poor Wi-Fi results isolates the added delay to the local wireless path.
- Compare download and upload phases.
If upload creates the larger jump, pause cloud backup, CCTV, file sync and livestreaming before retesting.
- Test at quiet and peak times.
Run the same wired method during a quiet period and when the issue normally occurs. Keep the device, server and test conditions consistent.
- Cross-check another device.
If only one laptop or phone is poor, investigate its CPU load, VPN, browser, security software and Wi-Fi adapter before changing network hardware.
- Map the proven pattern to the next guide.
Use the result paths below rather than applying several router, Wi-Fi and provider changes at once.
Use the result
Choose the Next Step That Matches the Proven Delay
This guide stays focused on measurement and interpretation. Detailed radio, upload and queue-management changes remain in their specialist pages.
If wired loaded latency is high
Repeat with household traffic paused. If the delta remains high, use the dedicated bufferbloat optimisation guide for supported router and shaping checks.
If only Wi-Fi is poor
Keep Ethernet as the baseline and follow the Wi-Fi speed and shared-airtime diagnostic guide for coverage, channel and mesh checks.
If upload causes the largest rise
Compare the available upstream capacity and use the slow upload troubleshooting guide for active uploads and upstream saturation.
If peak-time Ethernet is repeatedly worse
Collect matching daytime and evening results across at least two days before contacting the provider. Include idle ping, loaded values, packet loss and the test device.
If only one device is affected
Check CPU load, VPN routing, browser extensions, security scanning and adapter drivers. A network-wide change is unlikely to correct a single-client problem.
If the delta remains low
Loaded responsiveness is probably not the main bottleneck. Check packet loss, jitter, server distance or application-specific routing instead.
Detailed answers
Loaded Latency FAQs
Use these answers to distinguish quiet ping from busy responsiveness and decide whether the next check belongs to Wi-Fi, device load, hardware, provider capacity or bufferbloat.
What is the difference between idle latency and loaded latency?
Idle latency measures responsiveness while the connection is quiet. Loaded latency measures responsiveness while downloads, uploads or other traffic are actively using the connection.
Why does my ping look good until someone streams video?
A quiet ping can look healthy because little traffic is waiting. When a stream or large transfer starts, packets may queue at the router, upload path or Wi-Fi link, increasing the delay seen by games, calls and browsing.
Does high loaded latency always mean bufferbloat?
No. Bufferbloat is one common cause, but Wi-Fi airtime, device processing, variable mobile capacity, router hardware and provider congestion can also increase latency under load.
Can router or modem hardware cause loaded-latency spikes?
Yes. Hardware or firmware can be a suspect when spikes remain visible over Ethernet, affect more than one device and repeat under similar load even after household background traffic is paused.