Engine architecture & client execution
The speed testing utility on InternetSpeedTest.online (https://internetspeedtest.online/) is powered by @cloudflare/speedtest, Cloudflare’s open-source JavaScript measurement library licensed under the MIT License. Rather than requiring users to install native binary executables, flash applets, or third-party browser extensions, our entire test suite runs client-side within the browser's native JavaScript execution environment.
To optimize performance and eliminate unnecessary data transfer for users reading our technical guides, the testing engine is loaded dynamically on demand. The engine script is fetched from our static hosting origin only when a visitor triggers the test on our home page or dedicated tool pages like the download speed test, upload speed test, or bufferbloat test. We configure the runtime parameters, payload step-ups, and statistical analysis, but we do not modify the core transport timing events. All reported metrics reflect empirical client-side network telemetry.
Global BGP Anycast infrastructure
All HTTP throughput probes, idle round-trip pings, and loaded latency probes execute against Cloudflare’s globally distributed edge network at speed.cloudflare.com. Routing operates strictly via Border Gateway Protocol (BGP) Anycast:
- Deterministic Short-Path Routing: Instead of asking users to manually guess an optimal test server from a drop-down menu, internet routing automatically directs traffic to the nearest Cloudflare point of presence (PoP) across more than 300 cities worldwide.
- Last-Mile Isolation: In most metropolitan areas, Cloudflare edge servers peer directly with major internet service providers at local Internet Exchange Points (IXPs). As a result, the test measures the actual physical capacity of your ISP's last-mile loop (fiber, cable DOCSIS, DSL, or cellular) without confounding distortions caused by remote transcontinental transit links.
- Verifiable Ingress: We do not display synthetic server distances or fictitious geographic coordinates; all timing reflects real-world transport to Cloudflare’s Anycast ingress.
Five-stage sequential test pipeline
To prevent concurrent phases from competing for CPU cycles or interface bandwidth, InternetSpeedTest.online follows a rigid 5-stage sequential test pipeline:
| Pipeline Phase | Payload & Request Pattern | Technical Purpose & Ramp-Up Boundaries |
|---|---|---|
| 1. Connection Warm-Up | 1 × 0-byte ping + 1 × 100 KB payload | Initializes TCP three-way handshake, TLS 1.3 cryptographic session negotiation, and DNS resolution, preventing cold-start latency from biasing subsequent diagnostic measurements. |
| 2. Idle Latency & Jitter | 20 × sequential 0-byte HTTP probes | Gathers 21 baseline latency samples on an entirely quiet connection. Establishes quiescent round-trip time (RTT) before any saturating traffic begins. Link to our ping test and jitter test. |
| 3. Adaptive Download |
100 KB × 9 requests 1 MB × 8 requests 10 MB × 6 requests 25 MB × 4 requests 100 MB × 3 requests 250 MB × 2 requests | Adaptively steps up payload sizes. If transferring a given chunk size takes longer than approximately 1,000 ms, the engine halts further step-ups. Slower connections conclude early to preserve user data, while gigabit fiber lines scale up to 250 MB chunks to fill large TCP congestion windows. Link to our download speed test. |
| 4. Adaptive Upload |
100 KB × 8 requests 1 MB × 6 requests 10 MB × 4 requests 25 MB × 4 requests 50 MB × 3 requests | Transfers ascending binary payloads upstream from the client browser to the edge server. Utilizes the same 1-second step-up ceiling to adapt to asymmetric broadband lines without squandering bandwidth. Link to our upload speed test. |
| 5. WebRTC UDP Packet Loss | 1,000 × numbered UDP datagrams dispatched in batches of 10 (10 ms pacing between batches) | Streams numbered UDP packets through an authenticated WebRTC TURN relay. Pauses for 3,000 ms after the final packet to collect late out-of-order arrivals before computing packet loss. Link to our packet loss test. |
Throughput measurement & P90 filtering
Rather than relying on inaccurate operating system socket estimates, InternetSpeedTest.online uses the W3C PerformanceResourceTiming API to capture microsecond-precision transfer timestamps directly from the browser's networking stack.
Timing formula & server overhead isolation
For each individual chunk transfer, the engine records high-resolution timestamps:
startTime: The exact moment the browser begins the network fetch.responseStart: The arrival of the first byte of response data (Time to First Byte, TTFB).responseEnd: The arrival of the final payload byte across the network.
To eliminate server-side compute delay, Cloudflare’s edge server responds with an internal processing timing header. The measurement engine subtracts this server processing duration, isolating pure wire transit time. The raw transfer speed is calculated as:
Throughput (bps) = (Payload Bits Transferred) ÷ (Network Transit Time)
Filtering and 90th percentile (P90) aggregation
Early chunks in a TCP connection are constrained by TCP Slow Start (RFC 5681), where the sender conservatively probes line capacity by doubling its congestion window every round trip. Including early slow-start chunks would artificially underestimate your true line speed, while including fleeting initial cache bursts would exaggerate it.
- Discarding sub-10 ms transfers: Transfers taking fewer than 10 milliseconds are automatically filtered out to eliminate operating system timer granularity and thread-scheduling artifacts.
- 90th percentile (P90) calculation: Valid transfer samples are sorted in ascending order, and the 90th percentile (P90) value is reported. The 90th percentile captures the maximum steady-state throughput your connection comfortably sustained, filtering out initial ramp-up friction without reporting unrealistic instantaneous spikes.
Quiescent latency & sequential jitter
Latency (ping) and jitter evaluate the delivery timing and stability of individual packets on an idle connection during Phase 2.
Idle round-trip latency (ping)
Following an initial warm-up request, our engine issues 20 sequential 0-byte HTTP requests to speed.cloudflare.com, producing 21 quiescent round-trip latency samples. With zero payload transfer overhead, the elapsed time measures physical propagation delay, serialization delay, and switching overhead across your last-mile loop:
RTT = (ResponseStart − RequestStart) − ServerProcessingTime
To avoid skew from temporary Wi-Fi beacon interruptions or operating system background tasks, we report the median of the 21 collected samples rather than a volatile arithmetic mean. For more background on latency mechanics, consult our guide on what is ping.
Sequential jitter formula
Jitter represents the variation in round-trip delay between consecutive packets. On InternetSpeedTest.online, jitter is calculated as the mean absolute difference between sequential idle latency measurements across all 21 samples:
Jitter = (1 ÷ (N − 1)) × Σ |RTT[i] − RTT[i−1]| for consecutive samples i = 2 to N (where N = 21).
This sequential delta calculation measures real packet-to-packet volatility directly. Read our detailed guide on what is jitter and how to fix it.
Working latency & bufferbloat assessment
An internet connection with an impressive 15 ms idle ping can become completely unusable if unmanaged router queues fill up during active usage. This degradation is known as bufferbloat. InternetSpeedTest.online measures working latency concurrently during the active download and upload transfer phases.
While maximum-throughput data streams saturate your connection, the engine dispatches lightweight latency probes approximately once every 400 milliseconds. These probes must traverse the exact same modem buffers, router queues, and network interfaces as your bulk traffic:
downLoadedLatency: The median round-trip time recorded during downstream saturation.upLoadedLatency: The median round-trip time recorded during upstream saturation.- Bufferbloat Differential (Δ): The latency inflation caused by bufferbloat is computed as:
Bufferbloat Delta = max(Loaded Down Latency, Loaded Up Latency) − Idle Ping
A bufferbloat delta below 30 ms indicates an exceptionally well-managed router queue (such as one running FQ-CoDel or CAKE active queue management). A delta exceeding 100 ms indicates severe bufferbloat that causes sudden lag spikes during video calls or gaming. Test your working latency on our dedicated bufferbloat test, and read our guide on what is bufferbloat.
WebRTC UDP packet loss via edge TURN relay
Standard web browsing operates over Transmission Control Protocol (TCP), which automatically resends lost packets behind the scenes. Because TCP conceals dropped packets from browser APIs, standard web-based speed tests cannot detect packet loss without resorting to indirect retransmission approximations.
InternetSpeedTest.online overcomes this limitation by implementing WebRTC data channels running over User Datagram Protocol (UDP):
- Secure Ephemeral Credentials: When the test begins, the browser queries our serverless function at
/api/turn-credentialsto obtain short-lived, time-limited credentials for Cloudflare’s Realtime TURN (Traversal Using Relays around NAT) service. - UDP Packet Stream: The browser establishes an authenticated WebRTC connection to Cloudflare’s TURN relay (
turn.cloudflare.com:3478) and transmits 1,000 sequentially numbered UDP datagrams in 100 batches of 10 packets, with a 10 ms delay between batches. - Relay Reflection: The TURN relay immediately echoes each numbered datagram back to the browser over the active UDP socket.
- Grace Period & Loss Ratio: Once all 1,000 datagrams are transmitted, the engine waits for a mandatory 3,000 ms grace period to capture delayed out-of-order packets. Any datagram that fails to return within this window is classified as lost:
Packet Loss Ratio (%) = ((1000 − Packets Received) ÷ 1000) × 100
Learn more about diagnosing packet issues in our guides on what is packet loss and how to fix packet loss.
Telemetry taxonomy: measured vs. derived vs. guidance
To preserve complete scientific transparency, InternetSpeedTest.online strictly separates information into four transparent categories:
| Category | Definition | Included Metrics & Features |
|---|---|---|
| 1. Directly Measured Telemetry | Raw empirical network metrics recorded via high-resolution browser timing and WebRTC socket counters. Zero predictive modeling. |
• Download Throughput (P90 of valid chunks) • Upload Throughput (P90 of valid chunks) • Idle Latency (Median of 21 probes) • Idle Jitter (Mean absolute consecutive delta) • Loaded Download & Upload Latency (Medians under line saturation) • UDP Packet Loss Ratio (Returned / 1,000 datagrams) |
| 2. Mathematically Derived | Deterministic mathematical formulas applied directly to measured parameters. |
• Bufferbloat Delta: max(Loaded Latency) − Idle Latency • Estimated 1 GB Transfer Time: 8 Gb ÷ Upload/Download bps |
| 3. Evaluative Guidance | Objective comparison of measured values against vendor-published service specifications. |
• Streaming stream counts (Netflix & YouTube minimums) • Video conferencing suitability (Zoom & Microsoft Teams targets) • Online gaming readiness rating (Latency, jitter, and loss tolerances) |
| 4. Refused Approximations | Unverifiable figures that commercial speed test utilities frequently fabricate. We strictly refuse to publish these. |
• Single composite "Overall Speed Scores" (e.g., 88/100) • Subjective letter grades (e.g., Grade: A+) • Unverified municipal or national average speed rankings • Synthetic packet loss estimates when UDP is blocked |
Real-world application evaluation thresholds
Rather than condensing diverse connection characteristics into an arbitrary letter grade, InternetSpeedTest.online evaluates your measurements against empirical benchmarks published by major digital service providers:
| Application Category | Official Industry Benchmark | Evaluation Logic & Failure Conditions |
|---|---|---|
| Web Browsing & Email | Baseline HTTP document delivery |
• Good: Download ≥ 5 Mbps. • Limited: Download between 1.5 and 5 Mbps. • Poor: Download < 1.5 Mbps. |
| HD (1080p) Video Streaming | Netflix & YouTube recommend 5.0 Mbps sustained per stream. |
• Good: Download ≥ 10 Mbps (supports multiple streams: Download ÷ 5 Mbps). • Limited: Download between 3 and 10 Mbps (single stream capacity). • Poor: Download < 3 Mbps (buffering or 720p fallback). Consult our guide on internet speed for streaming. |
| 4K UHD Video Streaming | Netflix recommends 15 Mbps; YouTube recommends 20 Mbps sustained per 4K stream. |
• Good: Download ≥ 40 Mbps (capacity for multiple streams: Download ÷ 20 Mbps). • Limited: Download between 15 and 40 Mbps (single stream margin). • Poor: Download < 15 Mbps. See our guide on internet speed for 4K streaming. |
| Video Conferencing | Zoom 1080p group calls require 3.8/3.0 Mbps up/down. Microsoft Teams targets <100 ms RTT, <30 ms jitter, <1% loss. |
• Good: Download & Upload ≥ 4 Mbps, Ping ≤ 100 ms, Jitter ≤ 30 ms, Packet Loss < 1%. • Limited: Upload between 1.5 and 4 Mbps, Ping 100–150 ms, Jitter > 30 ms, or Loss 1–3%. • Poor: Throughput < 1.5 Mbps, Ping > 150 ms, or Packet Loss ≥ 3%. Read our guide on internet speed for video calls. |
| Competitive Gaming | Low round-trip latency, low jitter, zero packet loss, and minimal bufferbloat spike. |
• Good: Ping ≤ 50 ms, Jitter ≤ 15 ms, Packet Loss < 1%. • Limited: Ping 50–100 ms, Jitter ≤ 30 ms, Packet Loss 1–2%. • Poor: Ping > 100 ms, Jitter > 30 ms, or Packet Loss ≥ 2%. • Warning Trigger: Loaded latency increase > 100 ms flags severe queue lag. Read our guide on internet speed for gaming. |
| Large Cloud Uploads | Time required to transfer a standard 1 Gigabyte (8 Gb) file. |
• Good: Upload ≥ 20 Mbps (1 GB transfers in under 7 minutes). • Limited: Upload between 5 and 20 Mbps (1 GB transfers in 7–27 minutes). • Poor: Upload < 5 Mbps (1 GB transfers take over 27 minutes). See our download vs upload speed comparison. |
Browser constraints & measurement boundaries
To accurately interpret your speed test results, it is vital to recognize the physical boundaries inherent in any browser-based network measurement tool:
- Browser Execution Sandbox: JavaScript runs in a single-threaded event loop within browser security boundaries. On mobile devices or resource-constrained laptops, browser garbage collection or CPU throttling can introduce microsecond timing variances that do not exist on the physical Ethernet wire.
- Multi-Gigabit Saturation Boundaries: Modern web browsers incur significant CPU processing overhead when handling socket streams above 2.5 Gbps. On ultra-high-speed fiber connections, client hardware limitations may under-report line capacity; browser tests represent a guaranteed lower bound.
- Wi-Fi Link Layer Inflation: Testing over wireless networks measures the combined performance of your ISP access loop and your local radio environment. Physical distance from the access point, wall attenuation, 2.4 GHz vs. 5 GHz / 6 GHz frequency band selection, and client antenna limitations frequently restrict throughput well below what your router receives. Run our Wi-Fi speed test to evaluate wireless bottlenecks.
- Anycast Short-Path Proximity: Because traffic terminates at the nearest Cloudflare Anycast edge data center, the test reveals your connection's capability over an optimized short path. Connections to distant servers (e.g., game servers in another continent) will experience higher transit latency.
- VPN and Security Software Overhead: Virtual Private Networks (VPNs), corporate proxies, and antivirus web-filtering extensions introduce cryptographic encryption overhead and route detours that degrade throughput and inflate latency.
Protocol for reproducible measurements
To establish a clean, reproducible baseline of your broadband connection, follow our standardized testing protocol:
- Establish a Wired Baseline: Connect your device directly to your router using a certified Cat 6 or Cat 6a Ethernet cable. Disable Wi-Fi to eliminate radio-frequency interference.
- Quiesce Background Activity: Pause background cloud backups (Dropbox, Google Drive, OneDrive), game client updates (Steam, PlayStation), and streaming media players on other household devices.
- Bypass Intermediary Tunnels: Temporarily disconnect commercial VPNs, disable corporate proxies, and pause browser extensions that inspect network traffic.
- Conduct Longitudinal Multi-Hour Testing: Network congestion fluctuates throughout the day. Run tests on our home page during off-peak morning hours (9:00 AM – 11:00 AM) and peak evening hours (8:00 PM – 10:00 PM) to distinguish local in-home Wi-Fi issues from ISP neighborhood node oversubscription. Review our full guide on how to test internet speed properly.
Open auditability, licensing & contact
At InternetSpeedTest.online, we believe in open standards and verifiable code. Our editorial standards are detailed in our Editorial Policy, our privacy commitments are outlined in our Privacy Policy, and our acceptable use guidelines are codified in our Terms of Use.
For technical feedback, engine bug reports, or methodology questions, reach our administration at [email protected]. For enterprise licensing, syndication agreements, or business contracts, contact our contracts team at [email protected] or visit our Contact Page.