Investigate the long download latency on h3.speed.cloudflare.com
Categories
(Core :: Networking: HTTP, defect, P2)
Tracking
()
People
(Reporter: kershaw, Unassigned)
References
(Blocks 1 open bug)
Details
(Whiteboard: [necko-triaged])
When testing against h3.speed.cloudflare.com, Firefox shows higher download latency than Chrome. The definition of download latency can be found here.
|
Reporter | |
Comment 1•7 months ago
|
||
According to the download latency definition, the test issues a GET for 0 bytes and measures requestStart to responseStart. In the log below, the long-latency sample occurs while a 25 MB download is in progress:
2025-12-11 13:54:57.903 ⁃ nsHttpChannel ⁃ 1661ee800 ⁃ released ⁃ status=0 ⁃ http-status=200 ⁃ url=https://h3.speed.cloudflare.com/__down?measId=8420284450175521&bytes=25000000
2025-12-11 13:54:57.907 ⁃ nsHttpChannel ⁃ 1661e9000 ⁃ released ⁃ status=0 ⁃ http-status=200 ⁃ url=https://h3.speed.cloudflare.com/__log
2025-12-11 13:54:57.969 ⁃ nsHttpChannel ⁃ 1661f0900 ⁃ released ⁃ status=0 ⁃ http-status=200 ⁃ url=https://h3.speed.cloudflare.com/__down?during=download&bytes=0
2025-12-11 13:55:00.092 ⁃ nsHttpChannel ⁃ 1661f1400 ⁃ released ⁃ status=0 ⁃ http-status=200 ⁃ url=https://h3.speed.cloudflare.com/__down?measId=8420284450175521&bytes=25000000
The bytes=0 request takes ~3 s. During that window, Http3Session appears busy processing input for the 25 MB transfer (the prior bytes=25000000 request), delaying the 0-byte response start.
|
||
Updated•7 months ago
|
Findings thus far:
- Can not reproduce the issue with Cloudflare's new proxy stack, i.e. https://bastion.h3.speed.cloudflare.com/.
- Looking at pcaps from Chrome and Firefox (thanks to @Kershaw) on https://h3.speed.cloudflare.com/ Chrome gives both the 25 MB request and the 0 byte request a priority of 0, while Firefox sets a priority of 4 for both of them.
|
||
Comment 3•6 months ago
|
||
As an FYI, neither works when you're only connected over IPv4.
AFAIK http/3 is not IPv6 exclusive, but the speed.cloudflare sites state "Unable to perform speed measurements: HTTP/3 is not enabled in browser."
Which is false. http/3 is enabled and works on some other sites.
Interesting. I can reproduce the same error on h3.speed.cloudflare.com with IPv6 support, both on Firefox and Chromium:
Unable to perform speed measurements: HTTP/3 is not enabled in browser.
Something must have broken here recently.
That said, bastion.h3.speed.cloudflare.com still works as expected.
|
|
||
Comment 5•5 months ago
|
||
(In reply to Max Inden from comment #4)
Interesting. I can reproduce the same error on h3.speed.cloudflare.com with IPv6 support, both on Firefox and Chromium:
Unable to perform speed measurements: HTTP/3 is not enabled in browser.
Something must have broken here recently.
That said, bastion.h3.speed.cloudflare.com still works as expected.
Don't know if it's their doing or v147(.0.1.) but the Bastion version works for me (on IPv4) too now. However:
-
When turning on DNS-over-HTTPS, h3 only works until you restart the browser.
When the first connection is made with DoH enabled h3 no longer works and falls back to h2.
Turning off DoH also requires a browser restart before h3 starts working again.
This looks like a case of https://bugzilla.mozilla.org/show_bug.cgi?id=1993370 -
Comparing h3 vs h2 speeds: looks like h2 performs better and more consistently. Repeat h3 tests show deterioration of the upload speeds.
-
I do also notice quite a discrepancy in upload speeds comparing both with HTTP/1.1 tests.
When testing on Fast.com or Speedtest.net (use HTTP/1.1) I reach a symmetrical ~1Gbps/1Gbps
On bastion.h3.speed.cloudflare.com (HTTP/3) I reach ~700Mbps/200Mbps > falling to 100Mbps upload when repeating the test.
On bastion.h3.speed.cloudflare.com (falling back to HTTP/2) ~900Mbps/350Mbps
The regular speed.cloudflare.com (on HTTP/1.1) reaches ~900Mbps/700Mbps. So not quite Symmetrical yet, but uploads twice as fast as HTTP/2.
Description
•