The RTT badge in the bottom-right of this site is a live measurement of network latency between your browser and the edge. In trading, a 1ms advantage matters. But measuring latency accurately requires understanding what you’re actually measuring — which most tools get wrong.

Here’s exactly how it works.

---

The Foundation: What Is RTT?

Round-Trip Time (RTT) = Time for a request to travel from client → server → client.

Your Browser ──────────────────────────→ Server
    │                                        │
    │  ← Time A (Request leaves)             │
    │                                        │
    │                                        │  ← Processes request
    │                                        │
    │  ← Time B (Response arrives)           │
    │                                        │
RTT = Time B - Time A
```diff

RTT includes:
- **Network latency** (physical distance, routing)
- **TLS handshake** (on first request)
- **Server processing** (ideally near-zero for pings)

---

**Browser-reported latency and actual server-side latency are different things.** The Performance API measures what your user *experiences*, which includes TCP, TLS, and queueing — not just your handler's execution time. A server that responds in 2ms can still feel like 80ms on first load due to TLS negotiation and TCP slow start.

You need to measure the entire path, not just the handler.

---

## Measuring RTT

Here's how the RTT badge actually works. Open your browser's DevTools console and run:

```javascript
// Measure RTT to this site's ping endpoint
const measure = async () => {
  const start = performance.now();

  await fetch('/api/ping?t=' + Date.now(), {
    cache: 'no-store',
    mode: 'cors'
  });

  const end = performance.now();
  const rtt = end - start;

  console.log(`RTT: ${rtt.toFixed(2)}ms`);
  return rtt;
};

// Run 5 samples
const samples = [];
for (let i = 0; i < 5; i++) {
  samples.push(await measure());
  await new Promise(r => setTimeout(r, 1000));
}

// Calculate mean and standard deviation
const mean = samples.reduce((a, b) => a + b) / samples.length;
const std = Math.sqrt(
  samples.map(x => (x - mean) ** 2).reduce((a, b) => a + b) / samples.length
);

console.log(`Average RTT: ${mean.toFixed(1)}ms σ±${std.toFixed(1)}ms`);
```bash

Try it now and compare your RTT to the badge. They should match!

---

## Why We Show Standard Deviation (σ±)

A single RTT measurement is **noisy**. Network conditions change. Garbage collection spikes. Background tabs compete for resources.

That's why the badge shows `σ±` (standard deviation):
- **Low σ (< 5ms)**: Stable connection, consistent routing
- **High σ (> 20ms)**: Jitter, congestion, or mobile network

For trading systems, **jitter matters as much as average latency**. A 10ms average with 50ms spikes is worse than a stable 15ms.

---

## Common Misconceptions

Let's clear up some latency myths:

**Myth:** "My server responds in 2ms, so my latency is 2ms."
**Reality:** Server processing is usually the *smallest* component. Network RTT, TLS handshakes, and TCP slow-start often dominate. A 2ms server response becomes 80ms+ on the first page load.

**Myth:** "CDNs fix latency."
**Reality:** CDNs reduce latency *for cacheable content*. API calls and personalized content still hit origin servers. Edge functions (like Cloudflare Workers) solve this by running code at the edge.

**Myth:** "Ping and HTTP latency are the same."
**Reality:** ICMP ping measures L3/L4 only. HTTP includes DNS resolution, TCP handshake, TLS negotiation, and HTTP parsing. HTTP latency is always higher.

---

## The Performance API Deep Dive

The browser's Performance API gives you forensic-level timing data:

```javascript
// After fetching, examine the full timing breakdown
const entries = performance.getEntriesByType('resource');
const pingEntry = entries.find(e => e.name.includes('/api/ping'));

if (pingEntry) {
  console.log({
    dns: pingEntry.domainLookupEnd - pingEntry.domainLookupStart,
    tcp: pingEntry.connectEnd - pingEntry.connectStart,
    tls: pingEntry.secureConnectionStart > 0
         ? pingEntry.connectEnd - pingEntry.secureConnectionStart
         : 0,
    request: pingEntry.responseStart - pingEntry.requestStart,
    response: pingEntry.responseEnd - pingEntry.responseStart,
    total: pingEntry.responseEnd - pingEntry.startTime,
  });
}
```sql

This breaks down *where* time is spent-crucial for optimization.

---

## Why Edge Computing Changes Latency

Traditional architecture:

```text
User (Tokyo) → CDN → Origin (Virginia)
               ↓
          300ms RTT
```text

Edge architecture (what this site uses via Cloudflare Workers):

```text
User (Tokyo) → Edge Node (Tokyo) → Response
               ↓
            15ms RTT

The function runs in the same region as the user. No transatlantic round-trips for API calls.

---

Practice Exercise

Your mission: Compare RTT across different conditions.

1. Baseline: Run the RTT measurement code above
2. VPN Test: Connect to a VPN in a different continent, re-measure
3. Mobile Test: Try from your phone on cellular
4. Cache Warm: Run the measurement 10 times, compare first vs. last

What do you observe about TLS handshake impact on first request?

---

Key Takeaways

1. RTT ≠ server latency - Measure the full path, not just your handler
2. Show variance, not only averages - σ± reveals connection stability
3. Edge code beats origin code - For latency-sensitive endpoints
4. The Performance API is powerful - Use it to diagnose exactly where time goes

---

What’s Next?

Continue learning: What Is Latency?

Full technical deep-dive: How This Site Measures Latency