A speed test is a short lab note, not a verdict. TNET’s public result shows download, upload and ping. Saved tests also retain jitter for your dashboard. Packet loss is a separate diagnostic that should be checked in the Starlink app or the application showing the problem. This guide explains how to read those signals together and how to repeat the run so it means something. Start with TNET’s Starlink Speed Test.
Run the test first, then read it
Do not interpret a screenshot from another app, another hour, or another room as if it were this kit. Open the Starlink Speed Test, use the same browser session you will keep for history if you save results, and run from the device that actually matters—ideally a computer, ideally wired.
This guide is the reading layer. What to expect from Starlink speed is the expectation layer. If the pattern is bad, why Starlink is slow is the repair order.
Public aggregators and user reports scatter widely. Use repeated measurements from your own connection, not a forum average.
Download
Download is inbound throughput: how fast a large incoming transfer can run during the sample. Streaming, updates, and most web pages spend their time here.
Read it as a capacity check, not as a quality score. A strong download with poor upload or high loss can still feel broken on a call. A moderate download with steady latency can still be a fine household link.
Suspicious download patterns:
- Far below your other runs at the same hour, with no extra load in the house.
- Fine next to the router, terrible in another room (that is Wi-Fi).
- Fine on Ethernet, weak on the phone (still Wi-Fi or the phone radio).
- Collapses only during rain, snow on the dish, or a known obstruction window.
A low download on one lunch-break test is a clue. Three lows at the hour you stream are a pattern.
Upload
Upload is outbound throughput. Calls, cloud backup, sending a file, and some VPNs live here. On Starlink, upload is commonly the smaller number in public tests. That gap is expected. A “small” upload is not automatically a fault.
Read upload against the job:
- A short video call needs less sustained upload than a raw camera backup.
- Several cameras and a call at once share the same outbound path.
- A VPN can tax upload and add delay; compare one run with it off.
If download looks healthy and people still freeze on camera, believe upload, latency, or Wi-Fi before you believe “the internet is slow.” Depth on causes and improvements sits in Starlink upload speed.
Suspicious upload: much weaker than your own baseline at the same hour; much weaker on Wi-Fi than on a wire; paired with high loss. Do not chase a round Mbps target you saw online as if it were a TNET spec.
Latency
Latency is round-trip delay, usually shown in milliseconds. It is wait time. It is not how many megabits moved.
Lower and steadier is better for calls and games. A single latency figure is the sample’s central delay, not the whole story. If the number jumps between repeats, the jumpiness matters as much as the average.
Starlink latency is typically higher and more variable than a good fiber path, and much lower than older geostationary satellite internet. For why delay moves, read Starlink latency explained.
Suspicious latency: a spike only on Wi-Fi; a spike only with a VPN; a spike that tracks obstruction or weather; a calm Ethernet number and a wild phone number. Those splits tell you where the delay is.
Jitter
Jitter is how much latency changes during the test. Think of latency as the wait and jitter as whether the wait is predictable.
Calls and real-time games care about jitter more than a movie download does. A file transfer can ride through uneven delay. A voice packet that arrives late is already useless.
TNET estimates jitter during the latency phase and retains it with saved account results, although it is not a separate headline metric on the public result card. Use your own repeats:
- If jitter is low whenever you are wired and high on Wi-Fi, fix the room, not the dish.
- If jitter is high on Ethernet during rain or a busy evening, the path or the cell may be the story.
- If jitter is high and packet loss is also up, treat that as a stability problem, not a “need more download” problem.
Packet loss
Packet loss is the share of data that did not arrive. TNET’s browser speed test does not report packet loss, so use the Starlink app, a game or meeting diagnostic, or another purpose-built loss test for this signal. A little loss during a short sample can be noise. Repeated loss that you can feel—robot voices, rubber-banding, stalled pages—is a real fault.
Loss is not the same as low download. You can lose packets on a link that still posts a decent throughput number, because the test retries or the sample is short. You can also have low throughput with little loss if the pipe is simply busy or the radio is constrained.
If the Starlink app or a test flags elevated loss, do not ignore it, and do not assume the dish is the only cause. Wi-Fi interference, a bad cable, a struggling device, and obstructions all drop packets. The dedicated article is elevated packet loss on Starlink.
Good versus suspicious
A good result is one that matches your recent tests at that hour, on that path, well enough for the job. For a movie, that means download that does not stall. For a call, that means upload plus delay that stay usable. For a game, that means delay and loss that stay boring.
A suspicious result is one that disagrees with itself or with your baseline:
- Download huge, upload near a stall, on a call-heavy household.
- Latency fine on one run, double on the next, same device, thirty seconds apart, no extra load.
- Packet loss on Wi-Fi, none on a wire.
- A phone in the yard looks fine; the office computer looks dead (local network, not the satellite).
- Evening tests always sag; 10 a.m. tests do not (load or congestion, not a broken dish).
- One spectacular number you cannot repeat.
Do not grade a result against a stranger’s screenshot. Grade it against your repeats and against the application that failed.
Wi-Fi versus wired
Most “Starlink is slow” screenshots are Wi-Fi tests. That is still useful—it is what the tablet sees—but it is not the dish.
Wired (Ethernet) is the cleanest view of the kit, if your router and computer support it. Use it to decide whether the problem is the link.
Wi-Fi next to the router is the second-best view. If this is fine and the bedroom is not, you have a coverage problem.
Wi-Fi far away, through brick, or next to a microwave is a local radio test. It will smear latency, jitter, and loss.
When you compare, change one variable. Do not compare a phone on cellular-off Wi-Fi in the kitchen with a laptop on VPN on Ethernet in the office and call both “Starlink.”
Mesh nodes, extenders, and guest networks add hops. Note them on the pad next to the result.
Repeat tests so they mean something
One run is a coin flip. A small set is a picture.
- Pause backups, game updates, and camera clouds for the sample.
- Run the Starlink Speed Test twice in the same conditions. If they disagree wildly, run a third.
- Repeat at the hour the problem happens, not only when it is convenient.
- Repeat on Ethernet or next to the router, then in the problem room.
- Note weather, obstruction warnings, and whether the house was busy.
- Change one thing—VPN, location, cable—then test again.
Save or write the results. Memory turns every outage into “it’s always been this bad.”
If repeats stay poor after Wi-Fi is honest, follow the slow-connection sequence. If only delay looks ugly, use the latency guide. If only outbound looks ugly, use the upload guide.
The action that matters
Reading a result without capturing a clean sample is guesswork. Run TNET’s Starlink Speed Test, compare download, upload and ping, and review saved jitter in your dashboard when available. Check packet loss separately when the Starlink app, a game, or a call reports instability. Then change one thing and measure again.