RTT

RTT reports the browser’s running estimate of round-trip latency, in milliseconds:

Accept-CH: RTT

RTT: 75

What the number actually is

Three properties people regularly get wrong:

• Application-layer, not ping. It includes TCP/TLS and server think-time as observed by recent real requests, so it runs higher than an ICMP ping to the same host.
• Rounded to the nearest 25 ms, a deliberate granularity reduction against fingerprinting. You’ll see 0, 25, 50, 75…
• It describes the recent past. The estimate blends measurements across connections; a value of 450 says “this session has been living at satellite-or-worse latency”, not “the next request will take 450 ms”.

Latency vs bandwidth

RTT and Downlink fail in opposite directions: video streaming dies on low bandwidth but tolerates latency; an interactive app dies on latency but barely needs bandwidth. High RTT (say ≥ 300 ms) argues for fewer, larger requests: bundle aggressively, inline critical assets, avoid chatty API waterfalls. These decisions genuinely can be made server-side at HTML-generation time.

In practice, though, most teams should act on ECT instead: it already folds RTT into its four clean buckets. Reach for raw RTT when you need the actual distribution. Latency telemetry by geography is a real use, and it pairs naturally with IP-level geolocation data (an Ipregistry lookup tells you where and what network; RTT tells you how it felt).

Caching warning

Never Vary: RTT; dozens of possible values make cache hit rates collapse. Bucket it in your application logic first, or don’t cache on it at all.

In JavaScript

navigator.connection?.rtt   // 75

Chromium-only, Network Information API family, marked experimental by MDN since 2018 without much movement. It is usable, but always with a no-header default path.