The distance you cannot optimize

The other courses in this series have been about work the server does. This one is about the part of the response time that happens before the server is involved at all.

The floor

Light travels about 200,000 kilometers per second through fibre, and a request has to get there and back. That gives every pair of points on Earth a hard floor for a round trip, and no amount of caching moves it.

Real networks are slower than that: routing isn't a straight line, and every hop adds a little. Typical round trips to a server in the eastern United States:

Those are the numbers to hold in your head, because they set the scale for everything else in this course.

Why one round trip is never the cost

A first request takes several round trips before any application code runs.

There's DNS, if it isn't cached. There's TCP's handshake, one round trip. There's TLS, one more with version 1.3. Then there's the request itself.

Call it three round trips to the first byte. For a visitor in Mumbai talking straight to your server, that's 600 milliseconds before the server has done anything. A warm signed-in roadmap request in this application takes about 72 milliseconds to produce.

flowchart TB
  D["DNS lookup"] --> T["TCP handshake: 1 round trip"]
  T --> S["TLS handshake: 1 round trip"]
  S --> R["the request: 1 round trip"]
  R --> A["only now does the application run"]
  A --> N["Mumbai: ~600ms before 72ms of work"]

Read those two numbers together. For a distant user, the server isn't the slow part and never was.

The payload matters, but less than you think

This application's responses are small, and they're compressed on the way out: the roadmap is about 50 KB gzipped when signed in and about 10 KB anonymous.

TCP doesn't send it all at once. Slow start means the first burst is roughly 14 KB, then it doubles. 10 KB fits in the first burst. 50 KB needs two more round trips: 400 milliseconds more from Mumbai, for a payload that takes a few milliseconds to transmit at any reasonable bandwidth.

That's the shape of performance work over long distances: round trips, not bytes. Halving a payload that already fits in one burst changes nothing.

Where this application is

It's one server in one region. config/deploy.yml names a single host through NOR_SERVER_IP, with one Postgres accessory beside it.

Cloudflare sits in front of it. A visitor's TCP and TLS handshakes end at a nearby Cloudflare edge, and slow start runs over that short hop too. Stylesheets and scripts are cached at the edge. The HTML isn't: pages are dynamic, and the edge forwards every page request to the one origin.

So the handshakes are cheap, and every page still pays the distance to that one place. Measured from Brazil on 28 September 2026, through Cloudflare's São Paulo edge, a fresh connection finished its handshakes in about 30 milliseconds. The anonymous roadmap's first byte arrived after about 280 milliseconds. The server's share of that was about 20 milliseconds, and nearly all the rest was the trip between the edge and the origin.

The rest of this course is about the three things you can do about that, and which of them are worth it here.

Key takeaways

• Round-trip time is a physical floor: from the eastern US, ~90 ms to Europe, ~120 ms to São Paulo and ~200 ms to Mumbai.
• A first request costs roughly three round trips before application code runs: ~600 ms from Mumbai.
• This application produces a warm signed-in roadmap in about 72 ms, so for distant users the server isn't the slow part.
• TCP slow start means payload size matters in round trips, not bytes: 10 KB fits the first burst, and 50 KB needs two more.
• This application runs one server in one region behind Cloudflare. The handshakes end at a nearby edge, but every page request still travels to the one origin.