Speed Test Guide

A reference for the DeskTest.net Speed Test. It measures the real sustained download and upload throughput in Mbps at one desk, then translates those numbers into which Teams and Zoom video modes will actually hold up. Use it when the complaint is "video calls keep freezing" or "the connection feels slow" - the questions the reachability-focused Network Test cannot answer.

Open the Speed Test →

What does the Speed Test measure?

Three steps run in order, all against edge.desktest.net, DeskTest.net's own edge server:

1. Download throughput. The tool first runs a short warm-up fetch to gauge the link, then requests a right-sized block of throwaway bytes from edge.desktest.net/gen and streams it with response.body.getReader(), tallying bytes against performance.now(). The first fraction of a second (roughly 0.7 s of TCP slow-start) is discarded, and only the steady-state remainder is scored. That is what "sustained" means: a peak reading during ramp-up would flatter a link that cannot actually hold the rate.
2. Upload throughput. The browser generates a buffer of random filler bytes (from the cryptographic RNG) and POSTs it to edge.desktest.net/sink, which reads and discards it. The rate is the payload size over the request wall time. The Fetch API exposes no upload-progress stream, so this is the whole-request rate rather than a discarded-warm-up window - close enough for a desk sanity check.
3. Video call readiness. A few tiny requests give a rough ping and jitter, then the measured download and upload speeds are compared against per-mode bandwidth thresholds for Teams and Zoom, and the highest mode that clears both directions is reported.

When should I run this?

• "Video calls keep freezing." The single most common front-desk network complaint. Run this to see whether the desk actually has the up and down headroom the call needs.
• Before rolling out Teams or Zoom to a site. Check a representative desk in each office or leasing branch. Upload is usually the constraint on a call and the number most people never check.
• When "the internet feels slow." Reachability can be perfect while throughput is a crawl. This puts a number on it.
• After an ISP or plan change. Confirm the desk is getting something in the neighborhood of what the plan promises.
• To separate bandwidth from latency. If this test passes but calls still stutter, the problem is jitter or packet loss, not raw speed - switch to the Network Test.

Reading the results

Each step shows a status badge: Pending (gray), Running (yellow), Pass (green), or Fail (red). The download and upload steps show a live Mbps readout with a bar that rescales itself, so both a 5 Mbps DSL line and a gigabit fiber drop read sensibly.

Expand a step to see the detail: for download, the sustained figure, how many megabytes were measured over how many seconds, the total transferred, and whether the warm-up was discarded. For upload, the payload size and how long the POST took. The verdict step shows a table of video modes with the rough bandwidth each needs and whether this desk clears it.

The verdict panel at the top gives the plain-language answer - HD holds up, video works but not in full HD, or bandwidth is too low - plus what that supports and a recommended next step. Copy Diagnostic Report produces a plain-text summary (both speeds, ping and jitter, the full mode table, and the overall verdict) to paste into a ticket or an email to the network team.

The video-mode verdict

A live video call sends and receives at the same time, so the binding constraint is whichever direction is slower - usually upload. The tool reports the highest mode that clears both directions. The thresholds sit near the middle of the published Teams and Zoom guidance:

These are estimates. A call that clears the bar on paper can still stutter if jitter is high, if packets are being lost, or if several people share the same link during a busy morning. Treat a green verdict as "bandwidth is not your problem" rather than "calls are guaranteed perfect".

What this is not

• Not a multi-server speedtest. It measures against one server (DeskTest.net's edge). Distance to that edge, and its capacity, both cap the reading. Your ISP's headline number, measured to a nearby server, may be higher.
• Not moving your files. Every byte is random filler generated on the fly and discarded at the edge. Nothing you have is uploaded, and nothing is stored as content.
• Not a certified measurement. A browser tab shares the CPU, the Wi-Fi radio, and the link with everything else running. Close other heavy tabs and downloads for the cleanest reading, and run it two or three times.
• Bounded on purpose. Total bytes and total time are capped in every phase, so on a very fast link the window may be shorter than ideal, and on a very slow link the run stops rather than dragging on. Either way it cannot run away or drain an unbounded amount of data.

Common failures and fixes

download-failed: could not stream test bytes

The browser could not stream bytes from edge.desktest.net. This is a reachability problem, not a slow link - there is no speed to report because nothing arrived.

1. Run the Network Test first. If it also fails, the fault is egress (firewall, proxy, DNS, captive portal), not bandwidth.
2. Re-run in a private window with browser extensions disabled; a strict content blocker can kill the transfer.
3. If a corporate proxy or VPN is in the path, it may be blocking edge.desktest.net. Ask the network admin to allow it, or disconnect the VPN and retry.
4. Wait a moment and try again - a single dropped connection is often transient.

upload-failed: download worked, upload did not

The download completed but the POST to edge.desktest.net/sink failed. Some proxies and web filters allow downloads but inspect, throttle, or block large uploads.

1. Re-run in a private window with extensions disabled.
2. A data-loss-prevention (DLP) proxy - Zscaler, Netskope, Forcepoint - may inspect or block large POST bodies. Ask the network admin whether outbound uploads are filtered.
3. Disconnect any VPN and retry; some split-tunnel setups route uploads through a slower inspection chain that times out.
4. Run the test again - a single dropped upload is often transient.

Green download but a red verdict

Both measurements completed but the slower direction (usually upload) falls below what a usable video call needs. The download number alone is not the whole story: a plan sold as "100 down" can pair that with an upload of a fraction of a megabit, which is what actually breaks calls.

1. Switch from Wi-Fi to a wired connection and re-test; Wi-Fi upload is often much worse than wired.
2. Move closer to the access point, or onto a less congested band, if wired is not an option.
3. Check whether a backup, cloud sync, or large upload is saturating the link at the same time.
4. If the upload stays this low on wired with nothing else running, the plan's upload tier is the ceiling - escalate to the ISP or network team.

For IT admins

The test needs one host reachable: edge.desktest.net (DeskTest.net's own Cloudflare edge). It calls two endpoints there over HTTPS - GET /gen?bytes=N for the download and POST /sink for the upload - both carrying only generated, discarded filler bytes. There are no third-party scripts, fonts, or analytics on the page.

If your egress is a strict allow-list, add edge.desktest.net so the test can run. Notes by product:

• Zscaler ZIA / Netskope. A DLP or SSL-inspection policy that blocks or throttles large POST bodies will show up here as an upload failure while download passes. If you want a clean upload number, exempt edge.desktest.net from body inspection.
• Bandwidth-shaping proxies. Any appliance that rate-limits per-connection throughput will cap the reading below the raw link speed. That is often the real answer to "why is it slow" - the shaper, not the ISP.
• VPN egress. A distant or congested VPN concentrator adds latency and caps throughput. Re-test with the VPN off to separate the tunnel from the local link.

The measurement is single-vantage-point by design. For an ISP dispute you still want a multi-server tool; use this to compare desks, segments, and wired-versus-Wi-Fi within your own environment, where the fixed server is a feature because it holds the far end constant.

Related

• Speed Test - the test itself
• Network Test - reachability, latency, and jitter (this test measures throughput; that one measures whether you can get out and how fast the round trip is)
• Network Test Guide
• WebRTC Test Guide - the peer-to-peer path Teams and Zoom actually use
• About DeskTest.net
• DeskTest.net home

Elsewhere on the web:

• Cloudflare Speed Test - multi-metric throughput and latency-under-load from Cloudflare's global network.
• Speedtest by Ookla - the classic multi-server download/upload/ping test, useful for an ISP dispute.