Pingsivo · 1512 words · Updated 7 October 2026
English editorial adaptation prepared with AI assistance. Hypothetical examples are labelled. Technical sources accompany the relevant explanations.
A useful speed test starts with a specific question. Are you investigating your working location, comparing Wi-Fi positions, or checking what happens when everyone uses the connection? Keep the device, tool and documented conditions consistent. Repeat measurements instead of keeping only the highest number. Each result describes a transfer to a particular destination during a particular period, not the performance of every application at every moment.
Decide what you actually want to measure
A phone in the kitchen and a computer connected directly to the router answer different questions. The phone captures an everyday experience, including the wireless path. The wired computer removes some local variables. Both observations are useful, but they are not interchangeable.
Write down the problem before starting: calls breaking up in the office, slow uploads, or a suspected damaged cable. This determines which conditions must remain unchanged. A test near the router cannot replace a test in the room where calls fail. A cable comparison should retain the computer and, where practical, the same router port.
Avoid chasing a maximum number unrelated to your problem. Excellent download performance does not demonstrate reliable document uploads. A short period of low latency does not guarantee an uninterrupted meeting. Choose the dimension that affects the activity you are investigating.
Prepare a repeatable environment
Pause downloads you control and let visible updates finish. Record whether a television, console or backup is also using the connection. A quiet baseline is useful, but repeat a test under normal household conditions afterwards. The difference can be more informative than either number alone.
Keep the browser in the foreground and run one measurement tool at a time. Note power-saving mode and whether a laptop is plugged in. You do not need to alter every setting: the aim is a reproducible situation, not an artificial laboratory that cannot represent everyday use.
A private window may help investigate browser-session effects. Check which extensions are allowed there; private browsing does not automatically disable all extensions. Do not bypass your organisation's security requirements to obtain a better number.
Understand the measurements
Download describes transfers towards your device; upload describes transfers away from it. Latency measures delay, while variation describes the consistency of repeated responses. Capacity and responsiveness are different properties.
Pingsivo's Internet test uses Cloudflare. Its HTTP latency must not be presented as ICMP ping to your game server. See the Cloudflare engine documentation and Pingsivo's measurement methodology for the relevant scope and limitations.
An incomplete result remains incomplete. Missing upload data is not zero upload capacity. Interruptions, timeouts and failed requests require another attempt or inspection of the exported diagnostic. Do not invent values to complete a comparison table.
Use a small series
Run three successive tests under similar conditions, finishing one before the next. Pingsivo's three-test option can organise this sequence. It consumes more data than a single test, so read the profile information before starting. Record unexpected events such as a backup starting or a device moving.
Keep the whole series. The median is a central value; the minimum and maximum show dispersion. Three similar measurements tell a different story from one fast result surrounded by slow ones. The series summary includes complete tests only, and the number included matters.
Changing measurement services also changes the experiment. Destinations, durations and methods can differ, so start a separately labelled series. Consult the guide to speed units before comparing numbers expressed in incompatible units.
Change one condition at a time
For a Wi-Fi investigation, retain the device and measurement service, then compare the normal position with a position near the router. Add Ethernet if available. Do not change room, device, time and service together and attribute the difference to only one of them.
In a hypothetical example, office measurements vary while measurements near the router are consistent. That supports investigating the local path, but does not identify a particular radio fault. If wired results vary too, widen the investigation. The Wi-Fi and Ethernet protocol explains this approach.
Before buying equipment, formulate a testable hypothesis. “The problem occurs behind this wall” is more useful than “my Internet is bad”. Preserve a baseline so that you can assess whether a change actually improves the situation.
Keep a useful record
Record date, time, device, browser, declared connection, location, VPN use, destination and completion status. These details help a technician much more than a screenshot containing a single large number.
Local history in Pingsivo is optional. Use meaningful labels, such as “office, door closed”. Exported files can support comparisons, but they are editable records rather than independent certification of your subscription. Review labels and URLs before sharing them because they can reveal private information.
Finish with an observation, a limitation and a next action. For example: “Office results vary more; this test does not measure radio signal strength; I will compare access-point positions.” After changing one setting, reproduce the baseline and test the actual call, download or game. Use the stability guide for intermittent problems.
A worked comparison plan for a home office
Consider a hypothetical person whose weekly calls sometimes become difficult in an upstairs office. Their question is not whether the subscription can ever produce a high download result. It is whether changing the local connection improves the working situation. They write that question at the top of a small record and choose the laptop used for meetings. They keep its browser, power setting and VPN state unchanged. They also note that a shared television will remain on, because that reflects the normal working environment rather than an artificially empty network.
The first series is collected at the desk. Before each run, they note whether the meeting application or any backup is active. If a system update begins during the second run, they do not quietly discard the result and pretend nothing happened. They label the interruption, finish the observation and decide whether another comparable run is needed. This preserves evidence about the incident while keeping the controlled series understandable. The three-test interface saves repeated clicking, but it cannot know every activity elsewhere in the home or certify that conditions remained identical.
The second series uses the same laptop near the router. The person changes only the position and records the elapsed time. If the results improve, their conclusion is deliberately limited: the observations are compatible with a location-related difference under these conditions. They have not measured radio signal strength, surveyed interference or ruled out every time-related change. They can strengthen the evidence by returning to the original desk and checking whether the earlier pattern returns. This reversal is often more useful than immediately buying an accessory based on one favourable comparison.
For the wired series, they record the adapter and router port and verify the intended connection in the operating system. They then repeat the same profile. If a wired result is unexpectedly low, the next step is not to declare Ethernet defective as a technology. It is to check the actual equipment and whether the device is using the expected path. Their report keeps each series separate, including its date and connection declaration, so another person can understand which variables changed and which remained uncertain.
Finally, they conduct an ordinary call from the working location after one reversible change. The technical record includes the median and spread of the completed measurements, but the conclusion also says whether speech, video and screen sharing improved. If the call still fails while the browser test looks consistent, that is a reason to investigate the meeting-specific path or device behaviour, not to erase the user's experience. A measurement plan is successful when it narrows the next question and helps verify a practical change, even when it does not immediately identify a single faulty component.
FAQ: making measurements useful
Must every test use Ethernet?
No. Wi-Fi testing is appropriate when you want to evaluate the place where you work. Ethernet is a comparison that removes some wireless variables. An adapter or port can still introduce a limit, so document the hardware instead of treating a wired connection as automatically perfect.
Why do consecutive tests differ?
Other traffic, radio conditions, the destination and device activity can change. Look at a small series and its spread. One difference does not identify a fault; a repeated pattern associated with recognisable conditions is more useful.
Does excellent download speed guarantee smooth gaming?
No. Gaming also depends on the route to the game's servers, response consistency and factors outside this test. Treat the result as evidence about the tested path and then inspect the actual game.
How long should I keep results?
Keep enough history to answer your question. Comparing times of day needs different evidence from checking a hardware change. A small, well-labelled set collected consistently is often more interpretable than many unrelated measurements.
Should I send every screenshot to my provider?
Start with a concise summary and representative examples, including conditions. Ask which additional diagnostic information is needed. Keep original exports, but do not describe editable files as certified evidence or assume they establish contractual liability.