Upload speed inflated on low-latency connections (v6.1.0)

[EmanuelPeixoto]

Description

Upload speed is massively inflated (7-10 Gbps reported) on low-latency connections. The v6.1.0 speedtest.js no longer uses XMLHttpRequest.upload.onprogress to track actual bytes sent over TCP. Instead it appears to measure time-to-HTTP-response. On LAN (<1ms latency), empty.php returns 200 OK immediately before the request body is fully transmitted, so the reported upload speed is wildly wrong.

The old v5.x speedtest_worker.js used xhr.upload.onprogress and was accurate. This is a regression.

Server

• OS: NixOS 26.11 (kernel 6.18.38)
• Web server: nginx 1.30.3
• PHP: 8.4.22 (php-fpm, unix socket)
• Speedtest: LibreSpeed v6.1.0 (self-hosted, latest release)
• Mode: Modern UI (index-modern.html), single server, HTTP/2 + HTTPS
• Server latency: <1ms (same physical switch)

Client

• Browser: Zen (Firefox-based) on Linux
• Connection: 1 Gbps Ethernet to same switch as server
• Latency to server: ~0.5ms

Steps to reproduce

1. Self-host LibreSpeed v6.1.0 on a LAN server
2. Access modern UI from another machine on same LAN (<1ms latency)
3. Run upload test against local server
4. Observe upload speeds of 7-10 Gbps on gigabit hardware

Expected behaviour

Upload speed should reflect actual TCP throughput (~940 Mbps on gigabit LAN), as it did in v5.x with xhr.upload.onprogress.

Notes

• Download test is unaffected — garbage.php actually sends data before closing the connection
• The issue diminishes on high-latency connections (WAN) because the HTTP response roundtrip is slower than the upload, masking the problem
• empty.php returns headers immediately without consuming the POST body. With onprogress this didn't matter because timing was driven by TCP progress events, not HTTP response time

[EmanuelPeixoto]

Update: found the root cause

I ran a minimal XHR upload diagnostic in the browser console:

const data = new Uint8Array(20 * 1024 * 1024);
for (let i = 0; i < data.length; i++) data[i] = Math.random() * 256;
let total = 0, start = 0, prev = 0;
function go() {
  const x = new XMLHttpRequest();
  x.open("POST", "/backend/empty.php?r=" + Math.random());
  x.upload.onprogress = e => {
    if (!start) start = performance.now();
    total += e.loaded - prev; prev = e.loaded;
  };
  x.upload.onload = () => {
    const s = (performance.now() - start) / 1000;
    console.log("Total:", (total/1e6).toFixed(1), "MB |", s.toFixed(2), "s |", (total*8/(s*1e6)).toFixed(0), "Mbps");
    if (s < 5) go();
  };
  x.send(data);
}
go();

The server returned HTTP 413 (Request Entity Too Large) on every upload — nginx default client_max_body_size is 1 MB, but the test sends 20 MB blobs.

Two problems:

1. Server config not documented: the default upload blob is 20 MB (xhr_ul_blob_megabytes: 20), but there's no mention in the docs that the web server needs client_max_body_size >= 20M (nginx) or equivalent.

2. speedtest_worker.js doesn't check HTTP status on upload: at line ~504, xhr[i].upload.onload fires for any response, including 413 errors. It should check xhr[i].status and treat non-2xx as failures (like the onerror handler does). When the server rejects with 413 before consuming the body, onprogress events may report inflated speeds because the server responds instantly.

After fixing the server config, upload speeds are now correct (~940 Mbps on gigabit LAN).

[sstidl]

Thanks for the analysis—so, is there anything we can tweak? Feel free to point out where things could use some clarification. Any PR improving the docs is welcome.