Measuring your network: iperf3, LibreSpeed, and Speedtest Tracker

May 24, 2026

“My network feels slow.”

Every homelab runs into that sentence eventually. Maybe a large file copy took longer than it should. Maybe a VM migration dragged. Maybe you’re just curious whether you’re actually getting what you’re paying your ISP for. Saying “my network feels slow” is a starting point, but it doesn’t tell you where the problem is, and that distinction matters enormously when you’re troubleshooting.

Is it the wire? The switch? The Wi-Fi hop? The ISP? A misconfigured MTU? A virtual switch eating CPU? Before you can answer any of those questions, you need numbers — real, reproducible numbers. That’s what this post is about.

Three questions, three tools

Network performance testing is really three separate questions dressed up as one:

1. How fast is my LAN? — wire-to-wire throughput between two machines on your network.
2. How fast does a browser-based user experience on my network feel? — a more holistic test that mimics what a web app actually does.
3. How fast is my WAN, and is it consistent over time? — your ISP link, not just right now but as a historical trend.

Each question has a different answer, and conflating them is a source of endless confusion. A lot of people run Ookla Speedtest, see 900 Mbps, and conclude their network is healthy — while their NFS share crawls at 200 Mbps and they have no idea why. The tool you reach for depends on which question you’re asking.

The commercial landscape (and its limits)

Ookla Speedtest is the household name here, and it’s genuinely good at what it does: measuring your WAN throughput to a nearby server. The free tier works fine for a one-off check. For historical tracking, Ookla sells commercial products, and there are SaaS network monitoring platforms that will track your ISP performance automatically. These solutions are fine. They’re also cloud-first, meaning your test results, test schedules, and aggregate data live on someone else’s infrastructure. For a homelab, that’s an awkward fit.

More practically: Ookla and similar tools can’t test your local network at all. They start at the WAN interface. If you’re diagnosing why your two servers talk slowly to each other, an internet speed test is useless — you need a tool that operates entirely within your own infrastructure.

The self-hosted toolkit

Three tools cover the full picture. None of them require accounts. None of them phone home with your results. You run them yourself, on your own hardware.

iperf3 — raw LAN throughput

iperf3 is a command-line tool that measures pure TCP or UDP throughput between two hosts. One machine runs as the server; the other runs as the client; you get a number. That’s it. No web UI, no graphs, no fuss.

iperf3 answers the “how fast is my wire?” question with brutal honesty. If you’re expecting 10 Gbps between two hosts and you’re seeing 2 Gbps, iperf3 will tell you immediately — and then you start digging into why. Is it a duplex mismatch? A bottleneck in the virtual switch layer? A NIC driver issue? iperf3 isolates the layer so you can reason about the problem.

Common patterns that iperf3 helps diagnose:

• VM-to-VM throughput — are your virtual machines actually talking at the speed you’ve allocated, or is the hypervisor introducing overhead?
• VLAN and trunk testing — does traffic between two different network segments pass at wire speed, or is there a chokepoint?
• NFS and iSCSI baselines — before you blame your storage for being slow, confirm that the network path to the storage isn’t the bottleneck.
• Parallel stream testing — single-stream TCP doesn’t always saturate a 10G link; iperf3’s -P flag lets you run multiple simultaneous streams to get a more realistic saturation number.

The practical setup is simple: install iperf3 on any always-on machine in your lab — a control node, a utility VM, anything that stays up. Run it as a persistent service (a systemd unit is the clean approach), and you have an on-demand throughput endpoint available whenever you need it. The client side is just the iperf3 package installed on whatever machine you want to test from. No proxy, no reverse proxy, no web certificate — it speaks raw TCP.

What iperf3 doesn’t do: it doesn’t track results over time, it doesn’t have a browser UI, and it only measures between two specific endpoints you choose. It’s a diagnostic instrument, not a monitoring platform.

LibreSpeed — browser-based speed test

LibreSpeed is a self-hosted speed test that works in a browser. Pure HTTP, no Flash, no plugins. You open a page, click a button, and it runs download, upload, and ping tests against your own server.

The reason this is different from iperf3 is the measurement layer. iperf3 measures raw TCP throughput — the theoretical ceiling. LibreSpeed measures what a web client actually gets, including HTTP overhead, browser constraints, and the behavior of your reverse proxy. That gap is meaningful and often surprising.

LibreSpeed runs in a simple Docker container (the linuxserver image is a popular choice) and takes almost nothing to deploy. You can proxy it behind a reverse proxy and give it a friendly internal URL, or access it directly. Because it uses HTTP, it works through the same path as every other web service in your lab — which is actually the point. You’re testing the same stack your services use.

A good use case: if you’ve just recabled something, changed a switch configuration, or swapped a NIC, a quick LibreSpeed test from a laptop or phone gives you immediate, human-readable feedback. Did the LAN speed come up after replacing that cable? Open the browser, run the test, see the number. No CLI required.

LibreSpeed also makes a good sanity check for network segments you don’t normally exercise. Testing from the wireless side of your network vs. a wired client will reveal whether Wi-Fi is degrading the path — and by how much.

One thing to understand: LibreSpeed tests throughput to the LibreSpeed server, not to the internet. If your LibreSpeed server lives on the same LAN as the client, you’re measuring LAN speed. That’s useful. If you want to measure WAN speed with a browser test, you’d need to host LibreSpeed somewhere external — but at that point, you’re reinventing Ookla. For LAN testing, it’s exactly the right tool.

Speedtest Tracker — WAN history over time

Speedtest Tracker does something neither of the above tools does: it runs on a schedule, records every result, and gives you a dashboard of your ISP performance over time.

Internally it uses the Ookla Speedtest CLI to run tests, so you’re measuring against the same infrastructure as Ookla’s consumer app — but the results stay on your server, in your database, in your control. You can see trends. You can see when your ISP degrades on Saturday evenings. You can see whether that “up to 1 Gbps” marketing claim holds up at 9pm on a weekday.

The setup is similarly Docker-based. Speedtest Tracker has a Filament admin panel, stores results in SQLite by default, and runs tests on whatever cron schedule you configure. Every six hours is a reasonable starting point — frequent enough to catch patterns, infrequent enough not to distort your ISP usage statistics.

The dashboard shows download, upload, and ping results over time with basic charting. It’s not as visually dense as a Grafana dashboard, but it’s purpose-built for this specific use case and requires zero additional configuration to get a graph of your WAN history.

One honest caveat: Speedtest Tracker reaches out to Ookla’s servers to run tests. If you’re uncomfortable with Ookla seeing your IP address and result metadata, that’s a real concern. It’s the cost of using Ookla’s infrastructure as the measurement endpoint. The alternative is to set up a LibreSpeed instance on a VPS somewhere and use that as your WAN test target — but that’s a more involved setup, and for most homelabs the ISP performance graph is the primary use case.

How these three tools work together in practice

The mental model that makes this useful:

Something feels slow → start with iperf3. It answers “is the wire the problem?” in thirty seconds. If iperf3 shows wire-speed throughput, the network path is fine and you look elsewhere. If iperf3 is slow, you’ve isolated the problem to the network and can start investigating the specific path.

You’ve changed something → run LibreSpeed. After a hardware swap, a switch config change, or a cabling job, LibreSpeed gives you a fast browser-accessible sanity check that doesn’t require being at a CLI. Good for quick before/after comparisons.

ISP acting up? → check Speedtest Tracker’s history. Before you call your ISP support line, pull up the last two weeks of results. If you’ve got a graph showing 950 Mbps every day until yesterday at 6pm, you have evidence. If results have been variable for months, you have a different kind of evidence. Either way, you’re negotiating from data instead of “it feels slow.”

In this lab, iperf3 runs as a persistent systemd service on an always-on node so there’s always a test endpoint available. LibreSpeed runs as a Docker container accessible via an internal DNS name. Speedtest Tracker runs alongside it on the same host, scheduled every six hours with results persisted to disk. The three services together cost almost nothing in RAM or CPU — LibreSpeed is particularly lightweight — and they’ve paid for their existence many times over in debugging time saved.

Who should bother with this?

Run all three if you have more than one machine on your network, you’ve ever been surprised by how slow something was, or you pay for a fast ISP connection and want to verify you’re getting it.

Run at minimum Speedtest Tracker if you just want to keep an eye on your ISP without thinking much about it. Deploy the Docker container, set a schedule, forget about it for a month. When something feels off, you’ll have history.

iperf3 is essential if you’re doing any serious storage work — NFS, iSCSI, SMB shares. The difference between a healthy 10G network and a degraded one shows up in NFS performance long before you notice it anywhere else, and iperf3 is the fastest way to rule the network in or out as the cause.

You can probably skip all three if you’re running a single machine, you use your homelab purely for software development with no performance-sensitive workloads, and your ISP reliability doesn’t matter to you. No shame in it. Not every tool belongs in every lab.

The bigger picture

There’s a pattern in homelab tooling where the diagnostic infrastructure gets neglected in favor of the service infrastructure. People spend weekends deploying media servers and password managers and then, when something breaks, realize they have no baseline to compare against. “It was working before” is not a useful data point when you’re trying to figure out if a cable, a switch, or a hypervisor setting is responsible for a performance regression.

These three tools are cheap to run, cheap to maintain, and genuinely useful in proportion to how much complexity your lab has accumulated. Network complexity has a way of growing faster than network understanding. Having instrumentation in place before you need it is the same discipline as having backups in place before you need them. The time to set up a speed test server is not at midnight when you’re already frustrated.

Start with Speedtest Tracker — deploy it, let it run for a month, and you’ll have a baseline. Add iperf3 the next time you’re doing any network work. LibreSpeed takes about ten minutes to containerize. Three tools, maybe half an afternoon combined, and you’ll never have to say “my network feels slow” without being able to immediately follow it up with “here’s what I know so far.”

That’s a better place to debug from.

← all posts