Decide what you want to learn

A throughput test estimates transfer performance between a client and a test endpoint under particular conditions. It does not certify every application path or locate a fault on its own. Write down whether you are investigating plan performance, a wireless coverage problem, a slow download or delayed interaction; each question needs additional context.

Wi-Fi is useful when it matches the question

Testing Wi-Fi can help describe the experience where you actually use a device. A wired comparison can help separate some local wireless effects. Neither method is universally correct for every question. Record the device, room, connection type and adapter instead of applying a fixed wireless discount to a result.

Keep a conditions log

Record the date and time, service and endpoint if shown, browser, device, VPN or proxy state, connection method, and other active transfers. Keep failed attempts and warnings. Separate Mbps from MB/s and confirm what the plan advertises; FCC Broadband Consumer Labels can help readers in the United States find provider-disclosed plan information.

Check the wired path where practical

If using Ethernet, note negotiated link speed and any dock, adapter, switch or powerline segment. A gigabit indicator describes one link, not a guarantee of gigabit internet throughput. Keep the computer and service the same when comparing with Wi-Fi, and record unavoidable changes.

Control competing activity

Pause optional large transfers when establishing a quiet baseline, without disabling security software or interrupting essential work. Keep the browser tab foregrounded and note unusual device load. Later, a separate busy-condition comparison may be useful; label it clearly rather than mixing it with quiet runs.

Record endpoints instead of assuming neutrality

Different services and destinations can produce different results. Record the chosen server where available and repeat comparable observations rather than selecting only the highest number. VelocityVerify does not promise a dedicated bare-metal path or a result independent of every provider interconnection. Endpoint differences alone do not prove manipulation.

Read each metric by its method

VelocityVerify estimates HTTP round-trip timing, not UDP or ICMP packet timing. It does not measure a separate upload-loaded latency series or end-to-end packet loss. New letter grades are withheld. See the measurement method and validity rules before interpreting a result. Throughput, round-trip delay and a smoothed variation estimate answer different questions. Preserve warnings and invalid statuses when sharing or exporting a result rather than treating an unavailable measurement as zero.

Escalate a pattern, not a verdict

If the concern persists over a checked wired path, collect repeated results and the affected application’s evidence. If throughput remains well below contracted tiers despite verified link rates, see our guide on why download speeds drop to isolate server egress limits from local bottlenecks. The remaining possibilities include device limits, endpoint behavior, local equipment and the wider network. Ask support to assess the record; a slow wired test does not by itself prove an external fault or guarantee a technician dispatch.