How a URL Works: What Really Happens When You Press Enter

You type waypoint-app-blue.vercel.app and press Enter.

In the next 200 milliseconds, your computer will exchange messages with at least three different servers, traverse perhaps thousands of kilometres of fibre optic cable, and receive enough data to reconstruct a complete web page. By the time you've registered that the key has been pressed, it's largely done.

Here is what actually happens.

Step One: DNS — Translating the Name

Your browser doesn't know where waypoint-app-blue.vercel.app is. No computer does, intrinsically — domain names are human inventions, not network addresses. What the internet actually uses are IP addresses: numbers like 76.76.21.21 that identify specific machines.

So first, your browser asks: "What's the IP address for this domain?"

It sends this question to a DNS resolver — typically one operated by your internet provider, or a public one like Cloudflare's 1.1.1.1 or Google's 8.8.8.8. The resolver looks up the answer (checking its own cache first, then querying the global DNS hierarchy if needed) and sends back the IP address.

This takes 10–30 milliseconds. You don't notice it. It happens on every new domain you visit.

Step Two: TCP — Establishing the Connection

Now your browser has the IP address. But before it can ask for the page, it needs to establish a connection.

TCP (Transmission Control Protocol) does this with a "handshake" — three messages:

1. Your browser: "Hello, I'd like to connect." (SYN)
2. Server: "Hello, I'm listening." (SYN-ACK)
3. Your browser: "Great, let's go." (ACK)

This three-way exchange takes one round trip — whatever the physical distance between you and the server dictates. London to New York is about 70ms of pure physics. Sydney to New York is about 170ms. You can't make electrons travel faster.

For HTTPS (which is almost everything today), there's an additional TLS handshake to negotiate encryption — another round trip or so. These milliseconds add up.

Step Three: HTTP — The Request

Connection established. Now your browser sends an HTTP GET request:

GET /waypoint/speed-of-light HTTP/2
Host: waypoint-app-blue.vercel.app
Accept: text/html

This is a plain-text message saying: "Please send me the page at this path."

The server receives it, finds the right page (or generates it), and sends back an HTTP response:

HTTP/2 200 OK
Content-Type: text/html
Content-Length: 42819
...
[the actual HTML follows]

Status code 200 means success. The HTML then follows.

The CDN Shortcut

Here's what usually actually happens — and why it's faster than the above might suggest.

For popular websites, the server you're talking to probably isn't in a distant data centre. It's a CDN edge server — a machine operated by a company like Cloudflare, sitting in or near your city.

CDN edge servers store cached copies of websites. When you request a page, your request goes to the nearest edge server first. If it has a fresh copy, it sends it immediately — no origin server involved. No transatlantic cable. No round trip to California.

This is why loading BBC News from Australia is nearly as fast as loading it from London. The CDN has a copy in Sydney. The origin server in London barely knows you exist.

For this Waypoint app, Vercel operates a global CDN. When you load a page, you're talking to a Vercel edge server in your region. The Next.js pages are pre-generated and cached there, waiting for you.

What Happens Inside the HTML

The HTML that arrives isn't the complete page. It's a blueprint that references more things.

The browser reads it and finds: link tags pointing to CSS files, script tags pointing to JavaScript files, image tags pointing to image files, and font references. For each one, it makes another HTTP request. A typical news homepage makes 50–100 requests before fully loading.

Your browser doesn't wait for each one sequentially — it fires many in parallel, filling in the page as pieces arrive. This is why modern pages often appear partially rendered before they're done: the browser is showing you what it has while fetching the rest.

What "200ms" Means

A simple, well-optimised page from a nearby CDN can fully load in 100–300ms. Where does that time go?

• DNS: ~15ms
• TCP handshake: ~20ms (if edge server is close)
• TLS handshake: ~20ms
• HTTP request + response: ~30ms
• Parsing and rendering HTML: ~50ms
• Loading additional assets (CSS, JS): ~50ms

Total: ~185ms. Roughly a fifth of a second. The physics of light through fibre limits how much faster you can go.

For a page served from a distant origin with no CDN, each round trip could be 150–300ms instead of 20ms, and multiple round trips cascade. A page that loads in 200ms from a CDN might take 3–4 seconds without one.

This is why CDN infrastructure is worth billions of dollars, and why companies like Cloudflare and Akamai exist. Milliseconds, at scale, matter enormously.