6 Network Performance Problems

Establish a baseline

Begin by recording what is affected, when the problem occurs, and whether it affects one device, several devices, one application, or all network use. Compare the affected device with a known-good device.

If possible, test the same device over Ethernet. Better performance on Ethernet points toward a Wi-Fi or radio-frequency issue; similar problems on Ethernet and Wi-Fi suggest investigating a shared network path or service.

Measure both when the network is idle and when it is busy. Test progressively: check connectivity and delay to the local router, then to a reliable remote host, and finally to the affected application or service. ping can reveal delay and missed replies, but it tests ICMP rather than necessarily testing the application. Some devices limit or deprioritize ICMP responses, so confirm suspected problems with an application-level test or network monitoring data.

Interpret performance signals

Latency is the time taken for data to travel between endpoints, while round-trip time (RTT) measures a trip there and back. High latency can make interactive tasks feel sluggish. Compare typical and peak readings: delay that rises mainly when the link is busy can indicate queuing or congestion. Jitter, or variation in delay, can disrupt voice and video even when average latency seems acceptable.

Packet loss means packets fail to reach their destination. Loss can trigger retransmissions and reduce application performance. Determine whether loss appears on the local link, across the wider path, or only in a particular application; interface discard counters and packet traces can help locate where packets are dropped. A few missing ping replies alone do not prove that application traffic is being lost.

Bandwidth is the capacity of a connection, while throughput is the rate actually achieved. Compare a controlled speed or file-transfer test with the expected service rate, accounting for other users, Wi-Fi overhead, the remote server, and the test method. High bandwidth does not guarantee that a connection will feel fast if latency or loss is high.

Congestion occurs when traffic demand competes for limited capacity or airtime. It may cause throughput to fall and latency to rise during busy periods. Check whether slowdowns coincide with heavy downloads, backups, many active clients, or high interface or wireless-channel utilization. Client count alone does not establish congestion; activity and channel use matter.

Investigate wireless conditions

For Wi-Fi, note signal strength, access point, band and channel, and whether the issue changes with location or time. Weak signal, obstacles, interference, competing nearby networks, and busy airtime can lead to lower rates, retries, delay, and unstable connections.

Compare performance close to the access point with performance in the problem area. Check access-point or client reports for signal-to-noise ratio, retries, channel utilization, and roaming or disconnect events. If several devices near one access point are affected, investigate its radio conditions and load. If only one device is affected, compare its adapter, driver, and wireless settings with a working device.

Narrow down the cause

Use patterns in repeated tests to choose the next area to investigate. Treat these observations as clues, not proof: paths can differ, and intermediate network devices may handle diagnostic probes differently from ordinary traffic.

• Delay or loss to the router, especially on Wi-Fi: Investigate local wireless conditions, the client adapter, the access point, or the local link.

• A steady router test but slow or lossy remote tests: Investigate the router uplink, internet path, or remote destination.

• Performance that worsens mainly during busy periods: Investigate link capacity, queueing, active traffic, or wireless-channel congestion.

• One slow application while other services work: Investigate the application server, service path, or application-specific requirements.

• Trouble on only one device: Investigate its adapter, driver, background traffic, or local configuration.

Verify findings with repeatable tests

Repeat tests, compare wired and wireless results, and check device or access-point counters. If the evidence remains inconclusive, collect a packet trace during a reproducible slowdown and compare observations from both ends when possible.

Make one change at a time, then repeat the same test to verify whether it helped. Comparing measurements at different times and points along the path is more useful than changing settings at random. Interpret latency, packet loss, throughput, and congestion together, and include signal quality, interference, airtime use, and roaming when investigating Wi-Fi.