How Internet Speed Tests Actually Work

You click the big "Start Test" button. A few seconds later, you see a number: 347 Mbps download, 42 Mbps upload, 14ms ping. You nod approvingly, close the tab, and move on with your life. But what actually just happened? What did your browser do in those 10 seconds? How did it figure out that number? And more importantly -- should you trust it?

Most people treat speed tests like a thermometer. You take a reading, you get a number, end of story. But a speed test is more like a stress test at the cardiologist's office. The methodology matters enormously. Where you run, how long you run, what equipment monitors you, and whether you had coffee that morning all affect the result. The same is true for speed tests: server location, test methodology, network conditions, and even the time of day produce wildly different numbers on the exact same connection.

This article pulls back the curtain on everything that happens from the moment you click "Start" to the moment you see your results. We will cover TCP handshakes, chunk-based data streaming, latency measurement, bufferbloat detection, jitter calculation, and why pong.com's approach produces results that actually reflect your real internet experience. Buckle up -- this is the technical truth.

The First 100 Milliseconds: What Happens When You Click Start

Before a single byte of test data moves, your browser has to do a surprising amount of work. The speed test is not measuring your connection the instant you click -- it is setting up the infrastructure to measure it. Here is the sequence of events that occurs in roughly the first 100 milliseconds:

1. DNS Lookup: Your browser resolves the test server's domain name to an IP address. This query travels to your configured DNS resolver (often your ISP's, or a public resolver like Cloudflare's 1.1.1.1 or Google's 8.8.8.8) and returns the IP of the nearest test server. This takes 5-50ms depending on whether the result is cached.
2. TCP Handshake: Your device initiates a three-way TCP handshake (SYN, SYN-ACK, ACK) with the test server. This establishes a reliable connection and takes one full round trip. If the server is 15ms away, the handshake takes about 15ms.
3. TLS Negotiation: Since modern speed tests run over HTTPS, your browser and the server negotiate an encrypted connection. With TLS 1.3, this adds just one additional round trip. With older TLS 1.2, it adds two. This step exchanges encryption keys, verifies certificates, and establishes a secure tunnel for your test data.
4. WebSocket or HTTP/2 Upgrade: Many speed tests, including pong.com, upgrade the connection to WebSocket or use HTTP/2 multiplexing to enable efficient bidirectional data transfer. This negotiation adds a small amount of setup overhead but dramatically improves measurement accuracy.

All of this happens before any speed measurement begins. It is why the first second or two of a speed test often shows that spinning animation or "connecting" message. Your browser is building the measurement infrastructure on the fly.

One detail most people overlook: all of these setup steps are affected by the same network conditions that affect your speed test results. If your DNS is slow, your handshake is slow. If your path to the server is congested, TLS negotiation is slow. The test infrastructure is not separate from your connection -- it IS your connection. This is why server location matters so much, which we will get to shortly.

How Download Speed Is Actually Measured

Here is the fundamental question: how does a speed test figure out your download speed? The answer is deceptively simple in concept and surprisingly complex in execution. The basic formula is:

When a speed test measures your download speed, here is what actually happens under the hood:

Step 1: Opening Multiple Parallel Connections

A single TCP connection cannot saturate a fast internet connection. TCP's congestion control algorithm (usually CUBIC or BBR) starts slow and ramps up gradually. It also backs off whenever it detects congestion. On a single connection, your 500 Mbps pipe might only show 200 Mbps because TCP never fully opens up.

To solve this, speed tests open multiple parallel connections to the server -- typically between 4 and 16 simultaneous streams. Each stream independently ramps up its throughput, and the combined bandwidth across all streams more closely approximates your connection's true capacity. Think of it like opening multiple lanes on a highway instead of forcing all traffic into one.

Step 2: Streaming Data Chunks

The test server begins sending data to your browser across these parallel connections. The data itself is typically random or pseudo-random binary blobs -- the content does not matter, only the volume. Each connection streams chunks of data, and your browser tracks the bytes received.

Most modern speed tests use one of two approaches for the data transfer:

• HTTP Range Requests: The test requests chunks of a large file using HTTP range headers. The server responds with sequential chunks, and the client counts bytes as they arrive. This is the traditional approach used by many Ookla-based tests.
• WebSocket Binary Frames: The test opens a WebSocket connection and the server pushes binary frames continuously. The client counts frame sizes as they arrive. This approach avoids HTTP overhead and provides more granular timing data.
• Fetch API with ReadableStream: Modern tests use the Fetch API with streaming response bodies. The browser reads from the stream in chunks using response.body.getReader(), counting bytes at each read. This is what many browser-based tests now use, including pong.com.

Step 3: Byte Counting and Time Windows

As data streams in, the test client counts total bytes received and timestamps each measurement. But here is where methodology diverges significantly between tests. Some tests measure a fixed duration (say, 10 seconds) and count total bytes. Others measure until a fixed amount of data has transferred and track elapsed time. Some use a sliding window approach, discarding the first few seconds (the TCP ramp-up period) and the last second (potential ramp-down) to focus on the sustained throughput in the middle.

The sliding window approach is important because TCP slow start means the first 1-2 seconds of a download test show artificially low throughput. A test that includes that ramp-up period in its average will report lower speeds than one that only measures the sustained plateau. This is one reason different tests give different numbers on the same connection -- they handle the ramp-up differently.

Step 4: Calculating the Final Number

Once the test period ends, the client calculates: total bytes received across all streams divided by elapsed time, typically expressed in Megabits per second (Mbps). Note the unit: megabits, not megabytes. One byte equals eight bits, so 50 MBps (megabytes) equals 400 Mbps (megabits). Speed tests always report in bits because that is how ISPs sell their plans.

How Upload Speed Is Actually Measured

Upload testing works on the same fundamental principle -- bytes divided by time -- but the implementation is different because data flows in the opposite direction. Instead of the server pushing data to your browser, your browser pushes data to the server. This introduces some unique challenges.

Here is what happens during an upload speed test:

1. Generating test data: Your browser generates random binary data in memory. This is typically done using crypto.getRandomValues() or similar APIs to create buffers of random bytes. The data needs to be random to prevent compression from inflating the results.
2. Sending via POST or WebSocket: The browser sends this data to the test server using HTTP POST requests or WebSocket frames. Multiple parallel connections are used, just like in the download test, to saturate your upload bandwidth.
3. Tracking progress with XHR/Fetch: For HTTP-based uploads, the browser tracks upload progress using XMLHttpRequest progress events or Fetch API. Each progress event reports the number of bytes that have been sent, and the client timestamps each event to calculate throughput.
4. Server-side acknowledgment: The test server receives the data and sends back acknowledgments. The client uses these acknowledgments to confirm how much data was successfully received, not just sent.

Upload measurement is generally less precise than download for a few reasons. Browser APIs provide coarser upload progress data -- you get progress events at larger intervals rather than the fine-grained byte-level tracking available for downloads. Additionally, TCP acknowledgments flow in the opposite direction (download path) which can be affected by download traffic on asymmetric connections.

For a deep dive into why your upload speed is almost always slower than your download speed and what that means for your daily internet usage, check out our guide on download vs upload speed.

How Ping and Latency Are Measured

Ping measurement is the simplest concept in a speed test but has surprising nuance. At its core, a ping test measures the round-trip time (RTT) for a small packet to travel from your device to the test server and back. Send a tiny message, start a timer, wait for the reply, stop the timer. That is your ping.

But here is where it gets interesting. There are multiple ways to measure ping, and they produce different results:

Browser-based speed tests like pong.com cannot send ICMP packets (that requires OS-level access that browsers do not have). Instead, they measure HTTP or WebSocket round-trip times. This means the ping you see in a browser speed test includes slightly more overhead than a raw ICMP ping -- it includes HTTP header processing, TLS encryption/decryption, and application-level handling on the server. The difference is typically 1-3ms, which is negligible for most purposes.

Speed tests typically send multiple ping samples (10-20 or more) and report either the median or the minimum value. The median is more representative of your typical experience, while the minimum represents your connection's best-case latency. Most modern tests, including pong.com, report the median to give you a realistic expectation. For more on what constitutes a good ping value, see our complete guide to ping speeds.

How Bufferbloat Detection Works: Loaded vs Unloaded Latency

This is where things get really interesting -- and where pong.com fundamentally differs from legacy speed tests. Bufferbloat detection measures the difference between your unloaded latency (ping when your connection is idle) and your loaded latency (ping while your connection is being saturated with traffic).

Here is the technique step by step:

1. Measure unloaded latency: Before the throughput test begins, the test sends a series of ping measurements to establish your baseline latency. This is your connection's latency when nothing else is using it. Let us say it is 15ms.
2. Saturate the connection: The test begins a full download test, opening multiple parallel streams and pushing as much data through your connection as possible. The goal is to fill your bandwidth completely.
3. Measure loaded latency simultaneously: While the connection is saturated, the test continues sending ping measurements on a separate connection. These pings now have to compete with the flood of download data in your router's buffer queue.
4. Calculate the difference: If your loaded latency is 18ms compared to an unloaded 15ms, your connection handles congestion well (low bufferbloat). If your loaded latency jumps to 350ms while unloaded was 15ms, you have severe bufferbloat -- your router's oversized buffer is adding over 300ms of delay under load.
5. Grade the result: The ratio of loaded-to-unloaded latency is used to assign a bufferbloat grade, typically from A+ (minimal increase) to F (catastrophic increase).

The key insight is that measuring speed and latency separately tells you very little about your actual internet experience. You need to measure them simultaneously. A connection with 500 Mbps download but 400ms loaded latency will feel terrible for anything interactive -- video calls freeze, games lag, even web browsing feels sluggish during heavy downloads. A connection with 100 Mbps but 20ms loaded latency will feel snappy and responsive even while streaming 4K video.

For a comprehensive explanation of bufferbloat and why it specifically destroys video calls, read our deep dive: What Is Bufferbloat and Why It Ruins Your Zoom Calls.

How Jitter Is Calculated

Jitter measures the variability in your ping times -- not how fast packets travel, but how consistently they travel. If your ping bounces between 10ms and 50ms from one packet to the next, you have high jitter. If it stays rock-steady between 14ms and 16ms, you have low jitter.

The standard calculation method (defined in RFC 3550 for RTP traffic) works like this:

1. Send a series of ping packets at regular intervals (e.g., every 50ms)
2. Record the round-trip time for each packet
3. Calculate the absolute difference between each consecutive pair of measurements
4. Average those differences to get the mean jitter value

For example, if your ping measurements are: 15ms, 22ms, 14ms, 30ms, 16ms, the consecutive differences are: |22-15|=7, |14-22|=8, |30-14|=16, |16-30|=14. The average of [7, 8, 16, 14] is 11.25ms jitter. Some tools calculate jitter as the standard deviation of all ping measurements, which gives slightly different numbers but captures the same concept: how inconsistent is your connection's timing?

Low jitter (under 5ms) means your connection delivers packets with metronomic consistency -- ideal for video calls, gaming, and VoIP. High jitter (over 30ms) means packet delivery is erratic, causing audio glitches, video stuttering, and that infuriating robotic voice effect on Zoom. For a deeper dive, see our article on what jitter is and how it affects video calls.

Why Different Speed Tests Give You Different Numbers

This is the question everyone asks: "I got 480 Mbps on Speedtest.net, 390 Mbps on Fast.com, and 420 Mbps on pong.com. Which one is right?" The honest answer is they are all right -- they are simply measuring different things along different paths.

Here are the major factors that cause speed tests to produce different results on the exact same connection at the exact same time:

Server Location and Network Path

The biggest factor, by far. A speed test server hosted inside your ISP's data center will show higher speeds than one across the public internet because the data travels a shorter, more optimized path. It is like measuring how fast you can drive -- testing on a private track with no traffic will always produce a faster result than testing on public roads during rush hour. Both numbers are "real," but they tell you different things.

Number of Parallel Connections

Tests that use more parallel streams will generally report higher speeds. A test using 16 connections can saturate your pipe more completely than one using 4 connections. This is especially true on high-speed connections (500 Mbps+) where a single TCP stream's congestion window may not grow large enough to fill the pipe within the test duration. But here is the counterargument: real-world web browsing typically uses 4-8 connections to a given domain, so testing with 16 might overstate your practical experience.

Test Duration and Ramp-Up Handling

A 5-second test will give different results than a 15-second test. Longer tests allow TCP more time to find the optimal throughput and smooth out transient network hiccups. Short tests may catch your connection during a brief congestion event and report lower speeds, or catch it during a clear window and report higher speeds. How each test handles the TCP slow-start ramp-up period also matters significantly.

TCP Congestion Control Algorithm

Different operating systems and browsers use different TCP congestion control algorithms. Linux typically uses CUBIC, while newer systems may use BBR. These algorithms determine how aggressively your connection ramps up throughput and how it responds to packet loss. The same test can produce different results simply because you ran it on Chrome on Windows (CUBIC) versus Safari on macOS (also CUBIC, but with different kernel-level tuning parameters).

For a detailed side-by-side comparison of how pong.com, Speedtest.net, and Fast.com stack up, check out our full platform comparison.

The Role of CDN Edge Servers vs ISP Test Servers

The server that handles your speed test is not just any server. Where it physically sits in relation to your ISP's network determines what your test actually measures. There are three main categories of speed test servers, and each one answers a fundamentally different question about your internet:

ISP-Hosted Servers sit inside or adjacent to your ISP's own data centers. When you test against these servers, your data barely leaves your ISP's network. The result tells you: "Is my ISP delivering the bandwidth I am paying for on their own network?" This is what most Speedtest.net servers measure, and it is great for verifying your plan speed. But it says nothing about what happens when your data needs to leave your ISP's network to reach YouTube, Zoom, or a game server.

CDN Edge Servers (like Netflix's Open Connect or Google's edge cache) sit inside ISP facilities but are operated by content providers. Testing against these tells you how well your ISP delivers traffic from that specific content provider. Fast.com's results tell you how Netflix will perform on your connection -- valuable, but not representative of all internet traffic.

Public Internet Servers (like Cloudflare's edge network used by pong.com) sit on the open internet, accessible through the same peering points and transit networks your real traffic uses. Testing against these tells you what your actual internet experience will be like for the vast majority of websites, services, and applications you use daily. The numbers might be slightly lower than ISP-hosted tests, but they are more representative of reality.

HTTP/2 Multiplexing and Parallel Streams

Traditional speed tests open multiple TCP connections because HTTP/1.1 can only send one request per connection at a time. If you want to download four chunks simultaneously, you need four connections. Each one has its own TCP handshake, its own TLS negotiation, and its own congestion window. That is a lot of overhead.

HTTP/2 changed the game by introducing multiplexing: the ability to send and receive multiple data streams over a single TCP connection simultaneously. Instead of opening 8 separate connections with 8 separate handshakes, an HTTP/2 speed test can open one connection and then run 8 parallel streams within it. Each stream has its own flow control, and data frames from different streams can be interleaved on the same connection.

Why does this matter for speed testing? Several reasons:

• Reduced setup time: One handshake instead of eight. The test starts measuring sooner.
• Shared congestion window: All streams benefit from the same TCP congestion window, which means the connection can ramp up to full speed faster because the window is shared rather than each stream independently discovering the optimal rate.
• Lower overhead: Less header duplication, better compression (HTTP/2 uses HPACK header compression), fewer packets dedicated to connection management.
• More realistic: Many real-world websites use HTTP/2 multiplexing, so testing with it better reflects actual browsing conditions.

Pong.com leverages Cloudflare's HTTP/2 (and HTTP/3 where available) infrastructure for its speed measurements. This means the test protocol closely mirrors how your browser actually communicates with modern websites -- you are measuring your connection's performance using the same protocols and paths your real traffic uses.

Why Your Speed Test Doesn't Match Your Real Experience

This is the billion-dollar question. You see 300 Mbps on a speed test, but Netflix buffers, Zoom freezes, and web pages load slowly. What gives? There are several concrete explanations:

• The speed test only measures raw throughput. Your experience depends on latency, jitter, packet loss, and bufferbloat too. A connection with 500 Mbps but 200ms loaded latency and 5% packet loss will feel terrible for interactive uses.
• The test server path is different from real traffic paths. Your ISP may deliver great speeds to a test server hosted in their own data center, but the path to YouTube or Zoom crosses congested peering points that throttle your actual traffic.
• Your connection is shared. While you run the test, nobody else is using your connection. But when you are actually using the internet, your kids are streaming, your partner is on a video call, and your smart home devices are chattering away. The test measures peak capacity, not what is available during normal household usage.
• Wi-Fi bottleneck. Your speed test might run over Wi-Fi, which adds latency, reduces throughput, and introduces jitter compared to a wired connection. See our Wi-Fi vs Ethernet guide for details.
• DNS resolution time. Speed tests establish connections to known servers. Real browsing involves DNS lookups for every new domain, which can add 20-100ms per page if your DNS is slow.
• Server-side limitations. The website or service you are using might have its own bandwidth limits. Netflix throttles streaming bitrate to save bandwidth. Game servers send small packets. No amount of download speed will make a server respond faster if the server itself is slow.

This gap between speed test results and real experience is exactly why pong.com measures more than just speed. By testing latency under load, jitter, and bufferbloat alongside raw throughput, you get a connection health score that actually predicts how your internet will feel. A connection with an A grade on pong.com will genuinely feel great. A connection with an F grade will feel sluggish no matter what the raw Mbps number says. For more on how the health score works, read our Connection Health Score explainer.

How Pong.com's Testing Approach Differs from Legacy Tests

Traditional speed tests were designed in an era when the only question that mattered was "how fast is my connection?" They measured download speed, maybe upload speed, and tossed in a ping measurement for good measure. That was adequate when browsing the web meant loading static pages and the biggest application was email.

The modern internet is fundamentally different. We have real-time video conferencing, cloud gaming, collaborative document editing, IoT devices, and smart homes all sharing the same connection. Raw speed is no longer the whole story. Pong.com was designed from scratch for this reality. Here is what makes the approach different:

• Simultaneous latency measurement: Pong.com measures latency continuously during both download and upload tests, not just before them. This reveals bufferbloat that only appears under load.
• Real-world server path: By routing through Cloudflare's public edge network instead of ISP-hosted servers, pong.com measures the internet path your actual traffic travels.
• Comprehensive jitter analysis: Rather than just reporting average ping, pong.com calculates jitter to reveal consistency problems that affect real-time applications.
• Connection Health Score: All metrics are combined into a single A-F grade that predicts your actual experience. Speed is one component, but latency, loaded latency, jitter, and bufferbloat all contribute.
• Historical tracking: Pong.com stores your test history so you can track connection quality over time, identify patterns (does it degrade during peak hours?), and document issues for your ISP.
• No data selling: The test interface is clean and focused. Your test results are not monetized through data partnerships with ISPs.

A Packet-Level View: Following Your Data Through a Speed Test

Let us trace a single speed test from start to finish at the packet level. This is what your network equipment sees during a typical pong.com test:

1. T+0ms: Your browser sends a DNS query to resolve the test endpoint. A UDP packet leaves your device, hits your router, travels to your ISP's DNS resolver (or a public resolver), and comes back with an IP address.
2. T+25ms: Your browser sends a TCP SYN packet to the resolved IP address. This packet travels from your device through your router, through your ISP's network, possibly across a peering point, and reaches a Cloudflare edge server.
3. T+40ms: The server responds with SYN-ACK. Your browser responds with ACK. The TCP connection is established.
4. T+55ms: TLS Client Hello. Your browser proposes encryption parameters. The server responds with Server Hello, its certificate, and key exchange data. Your browser verifies the certificate and sends its key share. Encrypted tunnel established.
5. T+80ms: Unloaded latency measurement begins. Small HTTP requests bounce back and forth, measuring round-trip time without throughput load. Multiple samples are collected over 1-2 seconds.
6. T+2000ms: Download test begins. Multiple parallel streams request large data payloads. The server begins sending megabytes of data per second across these streams.
7. T+2100ms: Loaded latency measurement starts simultaneously. Lightweight ping requests are interleaved with the heavy download traffic, measuring how latency changes under load.
8. T+12000ms: Download test ends. Upload test begins. Your browser starts pushing random data to the server through parallel streams while continuing latency measurement.
9. T+22000ms: Upload test ends. Final jitter and latency calculations are performed client-side. Results are compiled and displayed.

Throughout this entire process, your router is doing the heavy lifting. It is managing NAT translation, queueing packets in its buffer, prioritizing traffic (if QoS is configured), and handling the TCP flow control that determines how fast data moves. The router's buffer management is the single biggest factor in whether your loaded latency stays low or spikes into bufferbloat territory.

Common Speed Test Misconceptions

Years of oversimplified speed test marketing have created some persistent myths. Let us clear them up:

Tips for Getting the Most Accurate Speed Test Results

If you want speed test results that actually mean something, follow these best practices:

• Use a wired Ethernet connection when possible. Wi-Fi introduces variables (signal strength, interference, channel congestion) that make results less repeatable.
• Close other applications and tabs. Background downloads, streaming, cloud sync, and software updates all consume bandwidth that reduces your test results.
• Disconnect other devices or at least pause their heavy usage. Your smart TV streaming 4K, your gaming console downloading updates, and your phone backing up photos all compete for bandwidth.
• Run the test multiple times at different times of day. A single test is a snapshot. Network conditions change throughout the day, with evening peak hours often showing significantly lower speeds.
• Understand what you are testing. If you want to verify your ISP plan speed, use a server close to your ISP. If you want to know your real-world experience, use pong.com's Cloudflare-based test.
• Check your Wi-Fi signal strength if testing wirelessly. A weak signal (one or two bars) will bottleneck your results regardless of your actual internet speed.
• Disable VPN connections during testing. VPNs add encryption overhead and route traffic through remote servers, which always reduces measured speeds.
• Test from the right device. An old laptop with a 100 Mbps network card cannot measure a 500 Mbps connection. Make sure your device's hardware supports the speeds you are testing.

Frequently Asked Questions

The Bottom Line: Speed Tests Are More Complex Than They Look

A speed test is not just a thermometer. It is a complex measurement system that involves TCP handshakes, TLS negotiations, parallel data streams, byte counting, sliding time windows, and statistical calculations -- all happening in 10-20 seconds. The server location, test methodology, number of connections, and how ramp-up periods are handled all determine the final number you see.

The most important takeaway is that the number on screen is not "your internet speed." It is your speed to one specific server, measured with one specific methodology, at one specific moment. Different tests give different numbers because they use different servers, different methods, and measure different things. None of them are wrong -- they answer different questions.

If you want the most complete picture of your internet connection -- not just how fast it is, but how healthy it is -- you need a test that measures throughput, latency, loaded latency, jitter, and bufferbloat together. That is exactly what pong.com was built to do. Run your first comprehensive connection health test and see the difference for yourself.