In this guide
What network performance means
Network performance is the behaviour of a connection under a particular workload and set of conditions. It is not one number. A connection can deliver hundreds of megabits per second and still feel poor for voice calls, remote desktop or interactive applications if latency rises sharply when somebody starts a large transfer.
Separate the problem into five questions: how much traffic can the connection carry (throughput); how quickly does a packet receive a response (latency); how consistent is that delay (jitter); are packets being lost (packet loss); and what happens when the connection is busy (loaded latency).
Key performance metrics
| Metric | What it tells you | Why it matters |
|---|---|---|
| Download throughput | Rate at which data is received | Downloads, streaming, cloud services and general capacity |
| Upload throughput | Rate at which data is transmitted | Backups, calls, uploads and cloud workloads |
| Latency | Response time to the test endpoint | Interactive applications and every round trip |
| Jitter | Variation in latency | Voice, video and real-time traffic |
| Packet loss | Traffic that fails to arrive | Retransmissions and degraded application quality |
| Loaded latency | Latency while traffic is moving | Queueing, congestion and bufferbloat |
Do not interpret a metric in isolation. For example, 20 ms latency with 5% loss can be a much worse experience than 40 ms latency with negligible loss.
Throughput and bandwidth
Bandwidth is link capacity; throughput is the useful rate actually achieved. A 1 Gbit/s interface does not guarantee 1 Gbit/s of application throughput. Endpoint CPU, protocol overhead, TCP behaviour, Wi-Fi, security inspection, congestion and the remote service can all limit the result.
Headline speed can therefore mislead. Check the client connection, wireless conditions, competing traffic, VPN/security software, endpoint limitations and the route to the test service. For capacity planning, compare measured throughput with the actual requirement rather than chasing the largest possible speed-test number.
Latency
Latency is the time required for traffic to travel between endpoints and for a response to be observed. A 20 ms measurement does not mean every application transaction takes 20 ms: applications may require multiple round trips, DNS lookups, TLS negotiation and server-side processing.
Latency is affected by distance, routing, transmission and queueing. A useful distinction is idle latency, measured with little competing traffic, and loaded latency, measured while the connection is carrying data.
A large increase from idle to loaded latency indicates queueing somewhere in the path. It does not, by itself, prove that the ISP or router is responsible.
Jitter
Jitter describes variation in packet delay. Real-time applications care about consistency as well as average latency. A stable 30 ms path can be easier for voice to use than one that alternates between 10 ms and 100 ms.
Queueing, contention, wireless retransmissions, route changes and variable processing can all contribute. Do not use one universal jitter pass/fail threshold; acceptable variation depends on the application, codec and buffering.
Packet loss
Packet loss occurs when packets are discarded or fail to reach the destination. Loss can reduce TCP throughput and is particularly harmful to real-time traffic.
Possible causes include a poor wireless link, overloaded interface, faulty cable or optic, congested queue, firewall, router, ISP network or remote endpoint. An Internet test can indicate loss but normally cannot identify the exact device responsible.
Loaded latency and bufferbloat
Bufferbloat occurs when excessive buffering lets queues grow under load. Throughput can remain excellent while interactive traffic suffers a large latency increase.
For example, a connection with 15 ms idle latency that rises to 250 ms during a large upload may have excellent upload throughput but provide a poor Teams or remote-desktop experience at the same time.
| Observation | Possible interpretation |
|---|---|
| Low idle and low loaded latency | Good evidence of a responsive connection under the tested load |
| Low idle, very high loaded latency | Investigate queueing, bufferbloat, router/WAN-edge QoS |
| High idle, similar loaded latency | Investigate path distance, routing, VPN or endpoint selection |
| High latency plus loss | Investigate congestion or physical/connectivity faults |
A reliable test method
1. Define the question
“The Internet is slow” is not a useful test objective. Ask something testable: is this laptop limited by Wi-Fi? Is the WAN delivering its expected capacity? Does latency rise under load? Is the problem local to one VLAN?
2. Record conditions
Record the device, connection type, AP if relevant, VPN state, time, WAN service and whether other users are generating traffic. Repeatable conditions make comparisons useful.
3. Establish a clean baseline
Stop unnecessary large transfers and avoid simultaneous tests. Keep normal security controls in place unless you are deliberately testing their effect.
4. Repeat the measurement
A single result is a snapshot. Run several tests and look for a pattern. Large variation is itself useful evidence.
5. Change one variable
For example, test the same device over Wi-Fi and then Ethernet. Do not change the device, AP, VPN and endpoint at the same time.
6. Compare idle and loaded behaviour
Throughput alone does not explain responsiveness. Look at latency and jitter while traffic is moving, particularly for voice, video and remote access complaints.
Testing Wi-Fi
A Wi-Fi speed test measures the complete path from the client through the wireless network to the test endpoint. It does not directly measure radio quality.
Poor Wi-Fi results can come from weak signal, low SNR, interference, channel contention, excessive channel width, client limitations, retransmissions, AP load, roaming or the wired network behind the AP.
Use a wired comparison
Testing the same service from Ethernet is one of the quickest isolation techniques. Fast Ethernet plus slow Wi-Fi points toward the wireless path; slow results on both suggest looking beyond RF.
For a proper wireless investigation, supplement the speed test with RSSI, SNR, channel, channel width, PHY rate, retransmissions, AP utilisation and roaming information where available. Wi-Fi airtime is shared, so a high negotiated PHY rate does not guarantee high application throughput.
Testing the Internet
Browser-based tests exercise the real client, local network, WAN and an external endpoint. They are useful for checking the end-user experience, but they are end-to-end measurements, not hop-by-hop diagnostics.
A poor result can originate at the client, Wi-Fi, LAN, firewall, NAT device, WAN circuit, ISP routing or test infrastructure. The Ingenix Network Performance Test uses Cloudflare edge infrastructure and reports throughput, idle latency, jitter and latency under load. Results are point-in-time indicators, not a complete LAN survey.
Testing the LAN
When the question is whether a LAN can deliver its designed throughput, use a controlled LAN test such as iperf3 between known endpoints. This removes most of the Internet path from the equation.
- Use known wired endpoints unless Wi-Fi is the subject of the test.
- Confirm negotiated interface speed and duplex.
- Monitor switch/NIC errors, discards and utilisation.
- Use multiple streams where appropriate so a single TCP flow is not the limiting factor.
- Test both directions where upload and download behaviour matter.
- Confirm that host CPU, NIC and storage can generate/receive the target rate.
Interpreting results
| Result pattern | Investigate next |
|---|---|
| High download/upload, low stable latency | Probably healthy for general Internet use; investigate application-specific requirements if problems remain |
| High download, poor upload | Service profile, WAN asymmetry, upstream congestion and local upload demand |
| Low throughput, good latency | Wi-Fi link, WAN capacity, endpoint limits or competing traffic |
| Good throughput, high idle latency | Endpoint selection, routing, VPN or path distance |
| Good idle, high loaded latency | Queueing, bufferbloat and QoS |
| Large variation between tests | Contention, wireless instability, background traffic or time-dependent congestion |
| Loss or severe jitter | Test progressively toward the WAN edge to locate where the problem begins |
Do not over-interpret a score
A composite score is useful for communication, but engineering decisions should use the underlying measurements. A score can hide whether throughput, latency, jitter or loaded behaviour is the actual weakness.
Troubleshooting poor results
- Repeat the test to confirm the result.
- Remove obvious variables such as large background transfers or unnecessary VPNs.
- Compare Wi-Fi and Ethernet to isolate the wireless path.
- Test another device to rule out a client-specific limitation.
- Test closer to the network edge using a wired host on the same LAN/VLAN.
- Check switch and firewall statistics for errors, discards, saturation and CPU load.
- Check WAN utilisation for legitimate congestion.
- Check QoS if latency rises sharply under load.
- Compare paths/endpoints where practical.
- Document the evidence instead of recording only “it was slow”.
Choosing the right test
| Question | Starting test | What it isolates |
|---|---|---|
| Is the Internet connection broadly healthy? | Browser Internet performance test | End-to-end experience |
| Is Wi-Fi causing the problem? | Ethernet vs Wi-Fi plus RF data | Wireless path and airtime |
| Can the LAN deliver its designed throughput? | Controlled iperf3 test | Known LAN endpoints |
| Is there path loss? | Progressive ping/trace plus interface statistics | Where loss/delay begins |
| Does congestion affect interactive traffic? | Loaded latency test | Queueing and bufferbloat |
| Is an application slow? | Application telemetry/packet capture | Application and transport behaviour |
Performance test checklist
Key takeaways
Measure performance against the problem you are trying to solve. Throughput tells you how much traffic the connection can carry; latency tells you how responsive it is; jitter tells you how consistent it is; packet loss tells you whether traffic is disappearing; and loaded latency shows what happens when the connection is busy. Use Internet tests for end-to-end experience, controlled LAN tests for LAN capacity, and wireless telemetry when investigating Wi-Fi. Repeat the test and change one variable at a time.