How much should I trust a speed test?

A test describes that spot at that moment only. Results move with the number of users, distance from the mast and the priority roaming users receive, and the test itself consumes your allowance. Run one to confirm the connection works, then judge by real use.

A speed-test app returns numbers that look very precise — download speed, upload speed, latency — but those numbers describe only the connection at the exact spot you were standing, at the exact second you tapped test. They are not a fixed value that holds for the rest of the day, let alone everywhere else in the same city. This page explains why results swing around so much, how to read them usefully, and when real-world use should be trusted over a test app's number.

The most overlooked point is that a test itself consumes your own data. Every time you tap test, the app downloads and uploads a sample file to measure the result, and that comes out of your real data allowance exactly like normal use does. Running the test repeatedly to 'find the best number' wastes data needlessly, since the outcome can change again the very next minute regardless.

What the numbers you see actually measure

Download speed describes how fast the phone pulled data from the internet at the moment of the test. Upload describes the opposite direction. Latency, or ping, describes the round-trip time between the phone and the test server. All three are a snapshot of the network in that split second — not a daily average, and not a promise of what speed will hold going forward.

Different test apps also choose different test servers. Some pick whichever server is geographically closest, others pick based on the network operator currently connected. Two apps run at the same spot can therefore return different results, not because either app is wrong, but because each measured through a different network path.

Why the result swings during the same day

The number of users sharing the same mast at that moment has a direct effect on the speed you measure. The more people connected at once, the less bandwidth is left to split among them. A time of day when an area is crowded — a local rush hour, for instance — will typically test lower than a quiet time, even standing at the exact same spot.

Distance from the mast is another factor that keeps shifting as you move around. The further from the mast, or the more obstructions in the way — a dense building, an underground space — the weaker the signal, and the lower the measured speed drops along with it. Two spots only a few hundred metres apart can return very different results if one has a clear line to the mast and the other is blocked.

How to test usefully without wasting data

1. 1Run one test to confirm the connection worksThe main purpose of a test is confirming the internet actually works, not chasing the highest possible number. If the first run returns a usable result, there is no need to run it again just to double-confirm.
2. 2Time the test close to when you actually need the connectionTesting at night then expecting the same result during a busy daytime hour in a crowded venue can set up a false expectation. If an important task needs to happen at midday, test close to that time instead.
3. 3Note the location the test was run at, not just the numberA result is tied to location almost as much as to time. Remembering exactly where a test was run helps explain why a different spot in the same city returns a different figure.
4. 4Let real use be the final judgeOnce the connection is confirmed, judge by actual use — a map loading, a message sending, a video call not stuttering — rather than the number sitting on a test app's screen.

Comparison: what each number tells you, and what it does not

When a test reads low but real use still feels normal

Most of what a traveller actually needs — opening a map, sending a message, calling a ride, checking email — uses far less bandwidth than the figure a test app measures. If a map opens smoothly and messages send normally, those tasks still work fine even when a test shows a lower number than expected. Treating the test figure as the sole measure can lead to worrying more than the situation warrants.

When real use is genuinely slow too, not just the test figure

If a map genuinely fails to load, a message will not send, or a page hangs unusually long, alongside a low test result, that is a sign the issue is not confined to the test app. Check remaining data allowance first, since a full-speed allowance that has run out tends to drag both real use and the test figure down together.

Another point worth separating out is slowness tied to one specific website or app, versus slowness affecting everything at once. If one app is slow while another works normally around the same time, the problem more likely sits with that app's own destination server rather than the network connection you are on. Trying a different app for comparison first gives a clearer read than judging from a single app alone.

Testing from a phone versus a laptop tethered to its hotspot

Testing over a hotspot measures both the cellular signal path and the hotspot's own overhead combined. The figure therefore tends to read a touch lower than testing directly on the phone broadcasting that hotspot, since there is an extra layer of signal conversion involved. That difference is a normal part of tethering, not a sign the plan itself is delivering less speed.

Accommodation Wi-Fi and the eSIM's mobile network return different results

A phone connected to both accommodation Wi-Fi and the eSIM's mobile network at the same time will usually default to Wi-Fi automatically whenever a Wi-Fi signal is present. A test run at that point measures the accommodation's Wi-Fi quality, not the eSIM's mobile network at all. To test the mobile network specifically, Wi-Fi needs to be switched off first before tapping test — otherwise the figure reflects the accommodation's own internet, something entirely outside an eSIM plan's responsibility.

This confusion often surfaces when a traveller returns to their accommodation and feels the connection has suddenly improved or worsened, when in fact the phone has simply switched to the accommodation's Wi-Fi instead of the mobile network. Knowing in advance which network the phone is currently using — by checking the icon or network name on screen — helps interpret a test result correctly, rather than assuming it is the same network throughout the whole trip.

Use a test to plan ahead of something important, not only after a problem appears

If something important genuinely depends on the internet — an online meeting, a deadline to submit — testing a short while ahead of the actual time is more useful than testing only once a problem has already appeared, since it leaves time to find a backup, such as moving to a spot with better signal or arranging alternative internet, before it becomes too late. A test like this should be run at the same spot where the task will actually happen, not somewhere nearby with different signal conditions.

Testing while moving versus testing while standing still gives different results

Testing on a moving train or car tends to return a lower and more erratic result than testing while standing still, because the phone is continually handing over between different masts as it moves. That handover process takes a brief moment each time, and it affects the measured figure. For a steadier reading of a real situation, testing while stationary works better than testing while aboard a moving vehicle.

When to trust a test result, and when to move past it entirely

Trust a test result as confirmation that the connection succeeded at that spot. Move past it once you start comparing two test runs at different spots and times to conclude a plan has gotten 'better' or 'worse', because too many variables separate those two numbers for a meaningful direct comparison. The comparison worth making is between real use and what a given task actually needs, not between two test-app numbers.

• Run one test to confirm the connection; do not repeat it chasing a higher number
• Note the location and time of the test, to understand why another spot reads differently
• Judge by real tasks — maps, messages — rather than the number on the test app
• Check remaining data first if both the test and real use are slow together
• Do not compare two test runs at different times and places and conclude the plan improved or worsened

Estimate the data you will need before buying a plan

When it is worth contacting the team about speed

Contact the team when both real use and test results stay low across several points on the trip, despite the full-speed allowance not yet being used up, and after trying a different position or a manual network selection. Include the plan name, country, the date and time the problem occurred, and a test result if one was run, through LINE at https://lin.ee/skDPoNx (@esimonline), email at esimonline.asia@gmail.com, or by phone at 089-942-0818 / 088-521-6848. We take messages around the clock, every day — late at night Thailand time a reply can take a little longer.