Library
Articles
10 min read

What happens when you type a URL

Published

You type swiggy.com into Chrome on your phone and press Enter. About a second later you are looking at restaurants. In that second, your request touched a dozen systems on several continents' worth of infrastructure, and almost every topic in system design made an appearance.

This question is asked at every level because it has no bottom. A fresher names DNS and HTTP. A senior engineer can go three levels deeper at any step the interviewer points at. The skill is giving a clean overview first and then going deep where you are asked.

Your answer

Before reading: list the steps from pressing Enter to seeing the page, in order. How many can you name, and which one do you think takes the longest?

The whole trip#

Press play, or step through it.

1/8 Before any network: the browser decides you typed a URL, not a search, adds https:// (the domain is on the HSTS preload list, so plain HTTP is never even tried), and checks its own caches and any service worker. A cached page can render with zero network.
Figure 1. One page load, from keystroke to pixels. A CDN hit ends the trip at the edge, a few milliseconds from you. Only a miss travels to the origin.

DNS, one level deeper#

When nothing is cached, your phone asks a recursive resolver (your ISP's, or a public one like 8.8.8.8 or 1.1.1.1), which does the legwork:

1/8 swiggy.com?

The TTL is the trade off you control. A long TTL means fewer lookups and slower failover; a short one (60 seconds) lets you move traffic quickly away from a broken region, at the cost of more queries. Traffic steering by DNS (latency based or geo routing in Route 53 or Cloudflare) works by answering with different IPs for different users.

Where the time goes#

A first visit, on a phone in Patna
40 ms
30 ms
180 ms
600 ms
DNS30 ms
TCP + TLS 1.3 handshakes2 x 40 = 80 ms
Request to the edge and back, plus origin work40 + 180 = 220 ms
Time to first byte330 ms
Rendering600 ms
0.93 s
until the page is usable

The browser's own work is the biggest slice, which is typical. Less JavaScript and smaller images usually beat any backend tuning for perceived speed.

In the interview#

Interviewer
What happens when you type google.com and press Enter?
Start with a thirty second overview. Do not spend five minutes on the keyboard interrupt.
You
At a high level: the browser checks its caches and HSTS, resolves the name with DNS, opens a connection to the nearest edge, TCP and TLS or QUIC, sends the HTTP request, which a CDN either answers or forwards to a load balancer and an app server that may hit caches and databases, then the HTML comes back and the browser parses, fetches subresources, runs JavaScript and renders. Which part would you like me to go deeper on?
A full map first, then an offer. The interviewer steers to what they care about.
Interviewer
Go deeper on how the browser knows it is really talking to Google.
You
During the TLS handshake the server sends its certificate chain. The browser checks it chains up to a root CA in its trust store, that the name matches google.com, that it is in its validity period and not revoked, and that it appears in certificate transparency logs. Then the server proves it holds the private key by signing the handshake. Only then are the session keys trusted.
Places they often push

DNS caching and TTLs. Why the CDN is close to you (anycast). The TLS handshake and certificates. What the load balancer does when a server dies. Why the second visit is faster (DNS, connections, HTTP cache, service worker). Critical rendering path: why a script tag in the head blocks rendering. Pick two of these to know cold.

Why is the second visit faster?
DNS
The connection
JS, CSS and images
The whole page offline

Checkpoint#

Checkpoint

1. What does the DNS TTL control?

2. Why does a request from Patna reach a server in Mumbai rather than in the US?

3. On a typical page, where does most of the time to a usable page go?

Worth memorising
  • Order: caches and HSTS, DNS, connect (TCP + TLS or QUIC), CDN, load balancer, app, data, response, render.
  • DNS: recursive resolver, root, TLD, authoritative. TTL trades load for agility.
  • TLS proves identity with a certificate chain and a signature.
  • CDN edges are near you because of DNS steering or anycast.
  • Give the overview first, then ask where to go deep.
Say this in 60 seconds

When I press Enter, the browser first decides it is a URL, upgrades to HTTPS because of HSTS, and checks its HTTP cache and any service worker. Then DNS resolves the name, usually from a cache, otherwise via a recursive resolver walking from the root to the TLD to the domain's authoritative servers, with a TTL governing caching. The answer points at a nearby CDN edge chosen by DNS or anycast. The browser opens a connection there, TCP plus TLS 1.3 or QUIC, and the certificate chain plus a signature prove it is the real site. The edge serves static assets itself and forwards the dynamic request over a warm connection to the origin load balancer, which picks a healthy app server, which reads from caches and the database. The HTML streams back compressed, and the browser builds the DOM and CSSOM, fetches subresources in parallel, runs JavaScript, lays out and paints. On phones, rendering and JavaScript are often the largest slice.

Next: L4 vs L7 load balancingRelated: TCP vs UDP vs QUIC