The RTT (Round Trip Time) header is an experimental Client Hint that tells a server how long it takes for a request to travel from the user to the server and back.
Unlike technical low-level pings, this value is calculated at the application layer, meaning it includes the time the server actually takes to process the data.
🚀 Why Use It?
The primary goal of the RTT header is performance optimization. If a server knows a user has a "laggy" connection (high RTT), it can adapt the experience in real-time by:
- Sending lower-resolution images.
- Skipping non-essential "heavy" scripts.
- Reducing the number of external resources to minimize extra round trips.
🛠 Key Technical Details
1. Privacy First (Rounding)
To prevent "fingerprinting" (where an attacker uses your exact millisecond latency to identify you), the RTT value is always rounded to the nearest 25 milliseconds.
- Example: If your actual speed is 112ms, the header will report
RTT: 100orRTT: 125.
2. The Opt-In Process
A browser won't just start blurting out your connection speed. The server must first "ask" for it using the Accept-CH (Accept Client Hints) header:
- Server: "I'd like to know your RTT, please." (
Accept-CH: RTT) - Client (on next request): "Sure, my RTT is 150ms." (
RTT: 150)
3. Caching Warning
The documentation warns against using RTT in the Vary header. Because your network speed changes constantly, your RTT value will too. If a server caches a different version of a page for every single RTT value, the cache will become bloated and useless.
🚦 Status & Compatibility
⚠️ Experimental Warning: This is not a "Baseline" feature. It is currently experimental and mostly supported by Chromium-based browsers.
BrowserSupport StatusChrome / Edge✅ Supported (v67+)Opera✅ Supported (v54+)Firefox / Safari❌ Not Supported
📝 Syntax Example
HTTP
# The request from the user's browser
GET /homepage HTTP/1.1
Host: example.com
RTT: 125