The Guide to Network Performance Testing Tools

Every IT manager has heard it: “The network is slow.” It is one of the most common complaints in any UK workplace, and one of the most difficult to diagnose without proper tools and methodology. Is the problem a bandwidth bottleneck at the internet gateway? Excessive latency on a WAN link? Jitter disrupting VoIP calls? Packet loss on a degraded switch port? Without systematic network performance testing, answering these questions relies on intuition rather than evidence — and intuition, however experienced, is an unreliable foundation for infrastructure decisions that may cost thousands of pounds.

Network performance testing is the disciplined practice of measuring, recording, and analysing how your network behaves under real-world and simulated conditions. It transforms subjective complaints into objective data, enables proactive identification of emerging problems before users notice degradation, and provides the quantitative evidence needed to justify investment in upgrades, replacements, or architectural changes. For UK businesses that depend on cloud-hosted applications, Microsoft Teams or Zoom for video conferencing, VoIP telephony, and increasingly distributed workforces connecting over VPN or SD-WAN, rigorous network testing is not a luxury — it is a core operational discipline.

This guide covers everything UK IT professionals and business decision-makers need to know about network performance testing: the critical metrics you should be measuring, the most widely used tools from free open-source utilities to enterprise-grade monitoring platforms, how to establish meaningful baselines, how to interpret results, how to build automated testing schedules, and how to communicate your findings to stakeholders who care about business outcomes rather than packet captures.

Why Network Performance Testing Matters

The shift from on-premise applications to cloud-hosted services has fundamentally changed what “the network” means for UK businesses. A decade ago, most business-critical applications ran on local servers connected to users via a LAN that the IT team controlled end to end. Today, those same applications — Microsoft 365, Salesforce, Xero, cloud-hosted ERP systems, VoIP platforms — traverse the local network, cross one or more ISP connections, travel through internet exchange points, and arrive at data centres that may be in London, Dublin, Amsterdam, or further afield. Every hop introduces potential for degradation, and every degradation affects productivity.

The financial impact is substantial. Research from Gartner and the UK’s own Federation of Small Businesses consistently shows that network-related productivity losses cost UK SMEs between £3,000 and £10,000 per year per affected employee in lost working time, failed transactions, and missed opportunities. For a 50-person office experiencing regular network performance issues, that translates to £150,000–£500,000 in annual hidden costs — far exceeding what most businesses spend on their entire network infrastructure.

Beyond direct costs, poor network performance erodes employee satisfaction, damages customer experience (particularly for businesses with customer-facing web applications or contact centres), and creates a culture of workarounds where staff find unofficial ways to bypass slow systems — often introducing security risks in the process. Systematic network performance testing breaks this cycle by providing the data needed to identify, diagnose, and resolve issues before they escalate.

Understanding the Key Network Performance Metrics

Effective network performance testing requires understanding what you are measuring and why each metric matters. Four measurements form the foundation of virtually all network performance analysis.

Bandwidth (Throughput)

Bandwidth — more precisely called throughput when measured in practice — refers to the volume of data that can be transmitted across a network link in a given time period, typically measured in megabits per second (Mbps) or gigabits per second (Gbps). It is the metric most people think of first, and while it is important, it is far from the only factor that determines how a network “feels” to end users.

A common misconception is that a business with a 1 Gbps internet connection should see 1 Gbps throughput to every destination. In reality, achievable throughput depends on the capacity of every link in the path, the protocol overhead (TCP headers, encryption, and error correction all consume bandwidth), network congestion at any point along the route, and the capabilities of the endpoints. Testing throughput between two points on your LAN tells you about your internal network capacity. Testing throughput to an external server tells you about your internet connection and the path beyond it. Both measurements are valuable, but they answer different questions.

Latency

Latency measures the time it takes for a data packet to travel from source to destination, typically expressed in milliseconds (ms). It is often measured as round-trip time (RTT) — the time for a packet to travel to a destination and for the response to return. Latency is determined primarily by physical distance (the speed of light through fibre is roughly 200,000 km/s, introducing approximately 1 ms of delay per 100 km), the number of network devices (routers, switches, firewalls) the packet must traverse, and processing delays at each hop.

For interactive applications, latency is arguably more important than raw bandwidth. A VoIP call requires minimal bandwidth (under 100 Kbps for most codecs) but becomes unusable if one-way latency exceeds 150 ms. Video conferencing degrades noticeably above 100 ms RTT. Even web browsing, which appears tolerant of latency, suffers because modern web pages require dozens of sequential requests to load fully — each one incurring the latency penalty.

Jitter

Jitter is the variation in latency over time. If latency is perfectly consistent — every packet takes exactly 20 ms — jitter is zero. In practice, consecutive packets experience slightly different delays due to varying queue depths in network devices, different routing paths, and competing traffic. Jitter is measured as the average deviation from the mean latency, expressed in milliseconds.

Jitter is particularly destructive to real-time applications. VoIP and video conferencing systems rely on packets arriving at predictable intervals. When jitter is high, the receiving system must buffer packets to reorder them and smooth out timing variations. Excessive jitter overwhelms these buffers, producing choppy audio, frozen video frames, and dropped calls. The ITU-T G.114 recommendation specifies that jitter should remain below 30 ms for acceptable voice quality.

Packet Loss

Packet loss occurs when data packets fail to reach their destination. It is expressed as a percentage of total packets transmitted. Causes include network congestion (routers dropping packets when buffers overflow), faulty cabling or connectors, degraded network interface cards, wireless interference, and misconfigured quality of service (QoS) policies.

Even modest packet loss has a disproportionate impact on performance. TCP-based applications (web browsing, file transfers, email) can recover from packet loss through retransmission, but each retransmission adds delay. UDP-based applications (VoIP, video streaming, online gaming) cannot retransmit because the data is time-sensitive — lost packets simply result in gaps in the audio or video stream. Packet loss above 1% typically produces noticeable degradation in voice quality, and above 2–3% renders VoIP calls unusable.

Types of Network Performance Tests

Different testing approaches serve different purposes. A well-rounded testing strategy employs several of these methods.

Throughput Testing

Throughput tests measure the maximum data transfer rate between two points on the network. They are conducted by sending a sustained stream of data (typically TCP or UDP) between a client and a server, measuring how much data is successfully transferred per second. Throughput tests reveal bandwidth bottlenecks, oversubscribed links, and underperforming network equipment.

Latency and Loss Testing

The simplest form is an ICMP ping test — sending echo request packets and measuring the round-trip time and loss percentage. More sophisticated tests use TCP or UDP probes to measure latency under conditions more representative of real application traffic, as some network devices prioritise or deprioritise ICMP differently from application traffic.

Stress and Load Testing

Stress tests deliberately push the network beyond normal operating conditions to identify breaking points. By progressively increasing traffic volume, you can determine the threshold at which latency spikes, packet loss begins, or throughput collapses — critical information for capacity planning and understanding how the network will behave during demand peaks.

Application-Specific Testing

Rather than testing raw network metrics, application-specific tests measure the performance of particular services — VoIP call quality (using MOS scoring), video conferencing frame rates and resolution stability, cloud application response times, or file transfer speeds. These tests directly correlate with user experience and are particularly valuable for stakeholder reporting.

Popular Network Performance Testing Tools

The market offers tools ranging from free command-line utilities to comprehensive enterprise monitoring platforms. The right choice depends on your network’s scale, your team’s technical expertise, and your budget.

iPerf3

iPerf3 is the gold standard open-source tool for network throughput testing. It is free, runs on Windows, macOS, and Linux, and provides accurate TCP and UDP throughput measurements between any two endpoints where the software is installed. iPerf3 operates in a client-server model: you run the server component on one machine and the client on another, then initiate a test that floods the connection with data and reports the achieved throughput, jitter, and packet loss.

iPerf3’s strength is its precision and flexibility. You can specify test duration, parallel streams, TCP window sizes, UDP bandwidth targets, and reporting intervals. It is the tool of choice for validating that a network link is delivering its rated capacity — confirming, for example, that a 10 Gbps backbone switch is actually passing 10 Gbps between ports, or that a 100 Mbps internet circuit delivers close to its advertised speed. The limitation is that iPerf3 is a command-line tool with no graphical interface, no historical data storage, and no automated scheduling. It is a point-in-time measurement tool, not a monitoring platform.

PRTG Network Monitor

Paessler’s PRTG is one of the most popular network monitoring platforms among UK IT teams, particularly in the SME and mid-market segments. PRTG uses a sensor-based model where each measurement — bandwidth on an interface, ping latency to a host, CPU utilisation on a server — is a separate sensor. The free tier includes 100 sensors, which is sufficient for small networks of 10–20 devices. Paid licences scale from 500 sensors (approximately £1,400 one-off) to unlimited sensors for large enterprises.

For network performance testing, PRTG excels at continuous monitoring rather than one-off tests. Its sensors track bandwidth utilisation via SNMP, measure latency and packet loss with configurable ping intervals, monitor QoS metrics for VoIP traffic, and can even simulate HTTP requests to measure web application response times. The historical data storage and alerting capabilities mean you can identify degradation trends, set thresholds that trigger notifications before users complain, and generate reports showing performance over days, weeks, or months. PRTG’s web-based dashboard makes it accessible to team members who are not comfortable with command-line tools.

SolarWinds Network Performance Monitor

SolarWinds NPM is the enterprise-grade choice for organisations with complex, multi-site networks. It provides deep visibility into network performance through SNMP polling, NetFlow/sFlow traffic analysis, packet capture and analysis, and intelligent alerting. SolarWinds’ PerfStack feature allows you to overlay metrics from different sources on a single timeline — correlating, for example, a spike in WAN latency with a surge in bandwidth utilisation on a specific interface, instantly revealing the root cause.

The platform’s strength is its depth and breadth. It maps network topology automatically, monitors the performance of individual network paths (NetPath), provides hop-by-hop latency and loss analysis, and integrates with SolarWinds’ broader IT management suite for cross-domain correlation. Pricing starts at approximately £2,500 for a 100-element licence, placing it firmly in the mid-market to enterprise category. For UK businesses with multiple offices, complex routing, or stringent SLA requirements, SolarWinds NPM provides capabilities that simpler tools cannot match.

Cisco Meraki Dashboard

For organisations using Cisco Meraki networking equipment — a popular choice among UK businesses with 50–500 employees — the Meraki cloud dashboard provides built-in performance monitoring and testing capabilities at no additional cost beyond the Meraki licence. The dashboard displays real-time and historical data on throughput, latency, client connectivity, wireless signal strength, channel utilisation, and application-level traffic analysis.

Meraki’s particular strength lies in wireless network performance testing. The dashboard shows per-client connection quality, identifies clients experiencing poor signal or excessive roaming, highlights access points with high channel utilisation, and provides automated RF optimisation. For wired networks, Meraki tracks port utilisation, cable test results, and upstream latency. The limitation is that Meraki’s monitoring covers only Meraki-managed devices — it does not provide visibility into third-party equipment, ISP links, or cloud service paths unless you supplement it with additional tools.

Tool	Type	Cost	Best For	Key Limitation
iPerf3	Open source CLI	Free	Accurate point-to-point throughput testing	No GUI, no historical storage, no automation
PRTG Network Monitor	Monitoring platform	Free (100 sensors); from £1,400	Continuous monitoring for SMEs and mid-market	Sensor count limits on lower tiers
SolarWinds NPM	Enterprise monitoring	From £2,500	Complex multi-site enterprise networks	Steep learning curve; significant cost
Meraki Dashboard	Vendor-integrated	Included with Meraki licence	Meraki-equipped organisations	Only monitors Meraki devices
Wireshark	Packet analyser	Free	Deep packet-level troubleshooting	Requires expertise; not a monitoring tool
ThousandEyes	Cloud-based SaaS	From £12,000/year	End-to-end internet and cloud path visibility	Premium pricing; overkill for simple networks
Nagios/LibreNMS	Open source platform	Free	Budget-conscious teams with Linux expertise	Complex setup; limited out-of-box dashboards
Speedtest CLI	Internet speed test	Free	Quick internet bandwidth verification	Only tests to Ookla servers; limited metrics

Cloud-Based Network Testing

As UK businesses migrate workloads to cloud platforms — AWS, Azure, Google Cloud, and SaaS providers — traditional network testing that only measures the local network misses a critical segment of the path. Cloud-based testing tools address this gap by measuring performance from distributed vantage points across the internet, providing visibility into segments you do not control.

Cisco ThousandEyes is the market leader in this space. It deploys software agents on your network and in cloud environments, then continuously tests connectivity, latency, packet loss, and path metrics to your critical services. The platform visualises the entire network path from your office to the destination, identifying exactly where degradation occurs — whether in your LAN, at your ISP, in a transit provider, or at the cloud platform itself. This is invaluable for resolving disputes with service providers, as you can present hop-by-hop evidence rather than vague complaints about “slow internet.”

For smaller budgets, tools like Datadog Network Performance Monitoring, Pingdom, and Uptrends offer cloud-based testing that checks connectivity and response times from multiple global locations. These are particularly useful for UK businesses with international customers, remote workers connecting from various locations, or staff using SaaS applications hosted overseas. Even free tools like Cloudflare’s speed.cloudflare.com and Google’s Measurement Lab (M-Lab) provide useful internet performance data, though they lack the depth and historical analysis of paid platforms.

Baselining Network Performance

A performance baseline is a documented record of how your network performs under normal operating conditions. It is the reference point against which all future measurements are compared. Without a baseline, you cannot determine whether current performance is normal, degraded, or improved — you can only react to obvious failures rather than subtle deterioration.

How to Establish a Baseline

Building a meaningful baseline requires measurements taken over a representative period — typically two to four weeks — that captures the full range of normal operating conditions. This means testing during business hours and outside them, on weekdays and weekends, during typical usage and during known peak periods (month-end processing, marketing campaigns, all-hands video calls). Key steps include the following.

First, identify your critical network paths: LAN backbone links, WAN connections between offices, internet gateway circuits, and the paths to your most important cloud services. Second, deploy appropriate testing tools — PRTG sensors, scheduled iPerf3 tests, or cloud-based probes — to measure bandwidth, latency, jitter, and packet loss on each path at regular intervals (every five to fifteen minutes is typical). Third, record the data over the baseline period and calculate statistical summaries: mean, median, 95th percentile, and maximum values for each metric on each path. Fourth, document the results in a baseline report that records the measurement methodology, the testing period, and the observed values.

When to Update Your Baseline

Baselines are not permanent. They should be refreshed after any significant network change — a circuit upgrade, a new office connection, a major infrastructure deployment, a change in ISP, or a substantial increase in headcount or cloud application usage. A baseline that was established two years ago on a 100 Mbps circuit is meaningless after upgrading to a 1 Gbps connection. Many organisations refresh their baselines quarterly, aligning the exercise with other IT review cycles.

Interpreting Test Results

Collecting data is only half the challenge. Interpreting that data — distinguishing normal variation from genuine problems, identifying root causes, and prioritising remediation — requires context and experience.

What Good Looks Like

On a well-functioning internal LAN, you should expect throughput close to the rated link speed (900+ Mbps on a gigabit connection), latency under 1 ms between devices on the same switch and under 5 ms across a campus network, negligible jitter (under 1 ms), and zero packet loss. Internet-facing metrics will be less pristine: throughput should reach 80–95% of the circuit’s rated speed, latency to UK-based services should be under 20 ms, and packet loss should remain below 0.1%.

Red Flags to Watch For

Several patterns in test results warrant immediate investigation. Throughput consistently below 70% of link capacity suggests congestion, duplex mismatches, or failing hardware. Latency that increases progressively over the course of the working day points to growing congestion as more users and applications compete for bandwidth. Jitter spikes correlating with specific times or events (large file transfers, backup jobs, software updates) indicate a need for QoS policies. Any packet loss above 0.1% on a wired connection is abnormal and typically indicates a hardware fault, cable issue, or severe congestion. On wireless networks, up to 1% packet loss may be tolerable depending on environmental conditions, but anything higher demands investigation.

Correlating with User Experience

The ultimate test of network performance is user experience. Maintain a log of user complaints with timestamps and correlate them with your monitoring data. If users report “slow Teams calls” every Tuesday afternoon, check your jitter and latency data for that time window. Often, the correlation is immediate and obvious — a weekly backup job saturating the WAN link, a batch process consuming bandwidth, or a scheduled cloud sync competing with interactive traffic. This correlation transforms network testing from an abstract technical exercise into a concrete problem-solving methodology.

Automated Testing Schedules

Manual, ad-hoc testing is better than no testing, but its value is limited by the small window of time it captures. Network problems are often intermittent, occurring during specific conditions that a one-off test may miss entirely. Automated testing schedules solve this by running measurements continuously or at frequent intervals, building a comprehensive picture of network behaviour over time.

Recommended Testing Frequencies

For most UK business networks, the following schedule provides a good balance between data granularity and resource consumption. Run latency and packet loss tests (ping or similar) every 60 seconds to critical infrastructure and key applications. Run throughput tests every 15–30 minutes on WAN and internet links, and every hour on LAN backbone paths. Run full application performance tests (simulating real user workflows) every 5–15 minutes during business hours. Run wireless performance sweeps every hour on all access points. Adjust these frequencies based on your network’s criticality and the capacity of your monitoring tools.

Implementing Automation

PRTG, SolarWinds, and most enterprise monitoring platforms include built-in scheduling for all sensor types. For iPerf3 and other command-line tools, automation is achieved through cron jobs on Linux servers or Task Scheduler on Windows machines, with results logged to CSV files or ingested into a centralised monitoring platform. Open-source solutions like Grafana combined with InfluxDB or Prometheus provide powerful visualisation and alerting for custom-automated test results, though they require more technical effort to configure than commercial alternatives.

Testing Before and After Changes

Network changes — firmware upgrades, configuration modifications, new equipment deployments, circuit migrations, QoS policy adjustments — are among the most common causes of performance degradation. A disciplined approach to pre-change and post-change testing prevents changes from inadvertently causing more problems than they solve.

The Pre-Change / Post-Change Methodology

Before any planned network change, run a comprehensive set of performance tests across all potentially affected paths. Record throughput, latency, jitter, and packet loss on each path. Document the results as the pre-change snapshot. Implement the change during the planned maintenance window. Immediately after the change, run the identical set of tests. Compare post-change results against the pre-change snapshot. If performance has improved or remained stable, the change is validated. If performance has degraded on any path, investigate immediately — you have the pre-change data to prove the change caused the regression, and you can roll back with confidence.

This methodology integrates naturally with ITIL change management processes and provides the documented evidence that auditors and compliance teams require. It also builds institutional knowledge: over time, your team develops a library of change-impact records that informs future planning and risk assessment.

Wireless vs. Wired Network Testing

Wireless and wired networks present fundamentally different testing challenges. While wired networks are relatively predictable — a gigabit Ethernet link either works at near-rated speed or it does not — wireless networks are subject to a complex interplay of environmental factors that make performance highly variable.

Wired Network Testing

Testing wired networks focuses on link integrity, throughput validation, and switching infrastructure performance. Cable testers (such as Fluke Networks tools) verify that cabling meets specification — Cat5e for gigabit, Cat6/Cat6a for 10 Gbps. iPerf3 tests between endpoints confirm that switches and uplinks deliver expected throughput. SNMP monitoring tracks interface errors, CRC errors, and collisions that indicate physical layer problems. The key advantage of wired testing is reproducibility: if you run the same test twice on a healthy wired network, you should get virtually identical results.

Wireless Network Testing

Wireless testing is more complex because performance depends on signal strength, channel utilisation, interference from neighbouring networks and non-Wi-Fi devices (microwaves, Bluetooth, cordless phones), client device capabilities, and the physical environment (walls, floors, furniture, human bodies). A wireless network that performs well at 8 AM in an empty office may degrade significantly by 10 AM when the office is full and fifty devices are competing for airtime.

Effective wireless testing includes site surveys using tools like Ekahau or NetSpot to map signal coverage and identify dead zones, channel utilisation analysis to detect congestion and interference, client-level performance testing from various locations at various times, roaming tests to verify that devices transition smoothly between access points, and capacity testing to understand how performance degrades as client density increases. The Meraki dashboard, as mentioned earlier, provides much of this data automatically for Meraki-managed wireless networks.

Key Differences in Metrics

Metric	Wired (Expected)	Wireless (Expected)	Notes
Throughput	90–95% of link rate	30–60% of PHY rate	Wireless overhead is substantial; Wi-Fi 6 improves efficiency
Latency	< 1 ms (same switch)	2–10 ms typical	Wireless medium access introduces inherent delay
Jitter	< 1 ms	2–15 ms	More variable due to contention and retransmissions
Packet Loss	0% (healthy link)	0–1% (acceptable)	Some wireless retransmission is normal; >2% needs investigation
Consistency	Highly consistent	Variable by time and location	Wireless tests must be repeated at different times and locations

Free vs. Paid Tools: Making the Right Choice

Budget constraints are real, particularly for UK SMEs. The good news is that free tools can provide genuinely useful network performance testing capabilities. The question is where free tools suffice and where paid tools deliver value that justifies their cost.

For a small business with a single office and a straightforward network, a combination of iPerf3 for throughput testing, ping scripts for latency monitoring, and the free tier of PRTG (100 sensors) provides a practical and cost-effective testing toolkit. For mid-market organisations with multiple sites, complex routing, and demanding application requirements, the time savings, integration, and support provided by commercial tools typically justify the investment many times over. The worst approach is spending £10,000 on an enterprise monitoring platform and never configuring it properly — an underutilised tool delivers less value than a free tool used effectively.

Reporting for Stakeholders

Network performance data is only valuable if it reaches the people who can act on it. Technical teams need detailed metrics and packet-level data. Management needs concise summaries tied to business impact. Both audiences are important, and they require different reports.

Technical Reports

For your IT team, reports should include detailed metrics for every monitored path, trend analysis showing performance changes over time, alerts and incidents with root cause analysis, and capacity utilisation data for planning purposes. Tools like PRTG and SolarWinds generate these reports automatically. For custom setups, Grafana dashboards provide flexible, real-time visualisation that technical teams find invaluable.

Executive and Stakeholder Reports

For management and non-technical stakeholders, translate raw metrics into business language. Instead of “WAN latency averaged 45 ms with 0.3% packet loss,” report “Remote office staff experienced occasional delays in video calls and cloud application access, which we have traced to the WAN connection and are addressing with a circuit upgrade budgeted at £2,400 per year.” Include visual summaries — traffic-light status indicators, trend charts showing improvement over time, and comparisons against industry benchmarks. Always connect the data to outcomes stakeholders care about: productivity, customer experience, risk, and cost.

Compliance and Audit Reports

UK businesses operating under regulatory frameworks (FCA, NHS, ISO 27001, Cyber Essentials Plus) may need to demonstrate that network performance is monitored and managed as part of their operational resilience obligations. Maintain timestamped performance records, document your testing methodology, retain baseline comparisons, and ensure your monitoring data is available for audit review. Most enterprise monitoring tools include compliance-friendly reporting templates; for custom setups, ensure data retention policies align with your regulatory requirements.

Building a Network Performance Testing Strategy

Individual tools and tests are useful, but their value is maximised when they form part of a coherent strategy. A practical network performance testing strategy for a UK business should include the following elements.

Define what matters. Identify the network paths and applications that are most critical to your business. For most organisations, this means the internet circuit, WAN links between offices, the path to key cloud services (Microsoft 365, your line-of-business application, your VoIP provider), and the wireless network in high-density areas.

Select appropriate tools. Match tools to requirements and budget. A combination of iPerf3 for ad-hoc throughput testing, PRTG or a similar platform for continuous monitoring, and a cloud-based tool for end-to-end path analysis covers the majority of needs.

Establish baselines. Run a two-to-four-week baseline measurement across all critical paths. Document the results and store them where they will be accessible for future comparison.

Automate continuous testing. Configure your monitoring platform to run tests at appropriate intervals and alert your team when metrics deviate from baseline thresholds.

Integrate with change management. Make pre-change and post-change testing a mandatory step in your change process. No exceptions.

Report regularly. Produce monthly technical reports for the IT team and quarterly business-language summaries for management. Use the data to support investment cases and demonstrate the value of network improvements.

Review and adapt. Revisit your testing strategy quarterly. As your network evolves — new applications, new offices, increased remote working, cloud migrations — your testing must evolve with it.

Network performance testing is not a one-off project. It is an ongoing discipline that, when practised consistently, transforms network management from reactive firefighting to proactive optimisation. The tools are available, many of them free. The methodologies are well-established. The only requirement is the commitment to measure, analyse, and act on the data — and that commitment is what separates organisations that merely have a network from those that truly manage one.