RealUserMedia loads the same media file from two delivery services on your own device and network, times every request with the browser’s built-in performance clock, and reports the medians of many repeated rounds. Nothing is simulated and nothing is averaged away — the per-round chart shows every sample the verdict is built from.
The clockThe W3C Resource Timing API — the browser’s own network instrumentation, the same data DevTools shows.
Browser cacheEvery measured request is sent with no-store, so it crosses the real network. Responses that still arrive from the local cache are rejected and re-measured.
StatisticsMedians of repeated rounds — never a mean, never a single try. The round count is always displayed.
ReproducibilityEvery measured URL is visible and copyable, so any result can be re-checked in DevTools or any other tool.
Test on your phoneOn desktop, Scan to test on mobile shows a QR code that opens this exact report on your phone — run it there with Wi‑Fi off for a true mobile-network result. The code is generated entirely in the page; no external service is contacted.
Shared reports arrive warmSharing a report (link or QR) quietly asks a public network of worldwide probe servers to fetch each media URL once — so whoever opens your link finds both sides’ edge caches equally warm at their location. Both lanes are warmed identically; it never runs during a measurement.
Two loading situations are measured separately, because they stress different things. Each has its own tab, its own chart and its own verdict.
First-time visitor
Every test loads one image at a size just above the page’s own, never requested before — a global counter keeps each width brand new while staying in the size class the page actually uses. That is what a first visit really costs.
Up to 30 such tests run inside a 12-second budget. Each answer’s pixels are decoded and checked against the requested size; an answer that isn’t a genuine resize is discarded with the reason shown. When the URL has no size parameter to vary — or coldness cannot be proven — this view is not shown at all rather than shown wrong.
The Edge cache row states each service’s own evidence on those brand-new sizes, judged by first-byte time against that same service’s warm baseline: a service that maps the request onto an already-prepared rendition answers Warm; one that generates every size on demand goes back to its origin — Cold. Both words describe real, measured behavior, whichever side shows them.
Parallel load
One heavy page’s worth of media — up to 100 files requested at once on the same connection, where bandwidth and byte-weight decide the outcome. This is where lighter files win visibly.
Up to 10 paced rounds run inside the time budget. The first round is thrown away as connection warm-up, and rounds are separated by short pauses so server rate-limiters don’t distort the later rounds. The label always states the count that actually ran.
The winner is decided only by the load-duration rounds of the technique on screen. Every other row — TTFB, p75, sizes — is information, not a vote.
Standard gateMedian gap over 5%, statistical confidence over 95% (Mann‑Whitney), and the faster side won most rounds.
Decisive gapA median gap of 40% or more that also took most rounds is declared even below the confidence bar — a 2× result across five aggregate rounds is not noise.
Otherwise“No significant winner”, with one plain-language reason. The evidence line always shows confidence and the round count.
When speed cannot decide, exact bytes do
Small files on a fast line are round-trip bound: both sides answer in a blink and the timing gap sits inside the network’s own noise. Repeating cannot help — but byte counts are exact, with zero noise. So when the measured times are a statistical tie and one side ships the same media at least 20% lighter, the verdict is published on weight: “−N% lighter”, with the honest note that speed alone could not name a winner on this network, and a projection of what those saved bytes are worth on a slow (3G) connection.
The rule is vendor-blind and guarded: it never overrides a statistically significant speed win, and it never fires on a run that was voided (a network-path change, files still being processed, or a lane that did not truly answer).
How the percentages read
Speed badges state how much faster the winner is, relative to the winner — deliberately unbounded, so a 48× win reads as 4,700%. File-size badges stay capped reductions, because a file cannot lose more than all its bytes.
speed % faster = ((slow ÷ fast) − 1) × 100
size % smaller = ((big − small) ÷ big) × 100
This tool is built by a vendor, so it is engineered to be checked by skeptics. The methodology is the product.
One code pathThere is exactly one measurement routine; vendors are configuration rows. No branch anywhere asks who is being measured.
OrderWhich side goes first is randomized on every round, so neither side systematically enjoys a warm slot.
Same assetBoth sides serve the same master file at the same requested size; delivered pixels are decoded and compared.
Bytes beside timeSpeed achieved by shipping a smaller file is a trade, not a win — so weight is always printed next to speed.
Losses shownWhen a competitor wins a metric, it is displayed in their green. Nothing is suppressed.
Your eyesBoth delivered files are rendered on screen so quality is judged by you, not by a score.
A true A/B: maximum quality on both sides
Many CDN URLs carry a quality knob (qlt=70, q=80, q_65). Left as-is, the test would compare a deliberately degraded copy against an optimised one — two different source qualities, which is not an A/B at all.
So when a lane’s URL carries such a parameter below 100, the test asks that lane at quality 100 instead — after verifying the raised URL actually answers (a 404 keeps the original). The comparison becomes the honest question this tool exists to ask: the source at its maximum quality against the optimised delivery of the same pixels. The rule is vendor-blind — it applies to whichever side carries the knob, either or both — the change is disclosed on the report, and the Measured file row shows the exact URLs asked, so anyone can reproduce it.
Some hosts don’t send the CORS headers a browser needs to read their responses. The browser can still load them — so they can still be timed, honestly.
No‑CORS modeWhen one side blocks reads, both sides are measured time-only by the same method, from the browser’s Resource Timing entries. Symmetry is never given up.
BytesShown as “not readable” for a host that hides them — never guessed. A host that sends Timing‑Allow‑Origin exposes real wire bytes even here.
FormatInferred from what this browser negotiates with the platform, and labeled as such.
VideoMeasured by full downloads per round — heavier, slower, and the truest delivery number available.
First-time visitorRequires provable coldness. When it cannot be proven, only Parallel load is shown.
Honest limits, stated up front.
TTFBServer-response time needs the Timing‑Allow‑Origin header. Without it the row is omitted — never shown as a fake zero.
One deviceA run describes this device, this network, this moment. Repeat on different networks and locations before generalizing.
Wi‑FiFast Wi‑Fi hides byte-weight differences behind latency. Cellular is where delivery differences show their real size.
PrivacyNo cookies, no fingerprinting, no personal data. Saved results carry coarse device and network context only.
