What Happens When You Type abc.com

Browser, DNS, network, edge, origin and render

Follow one page load end to end: the browser checks its caches, DNS turns the name into an address, packets leave through the router and the ISP, TCP and TLS (or QUIC) set up a connection to the nearest CDN edge, the request reaches the load balancer, app servers, cache and database on a miss, and the response is parsed, laid out and painted.

Overview

"What happens when you type a URL and press Enter?" is asked at every level, from new graduates to staff engineers, because there is no bottom to it. A good answer is not a list of acronyms. It is a chain of layers in the order they actually run, where each layer answers one question: is this already cached, where is the server, how do packets get there, how do we get a secure connection, who answers, and how does the answer become pixels.

The order matters and is where many answers slip. The browser looks in its own caches before touching the network. DNS runs before any TCP connection, and the DNS query is itself a UDP packet, so the routing table and ARP for the default gateway are used before DNS, not after TLS. The answer for a large site is usually a CDN edge near you, not the company's own servers, and most page loads end there.

This topic uses abc.com as a stand-in for any site served over HTTPS behind a CDN. The records, addresses and timings are examples (addresses from the documentation ranges), not any real site's.

In the interview: - Walk the layers in order: browser, DNS, network path, connection, edge, origin, response, render. - At each layer, name its cache and what makes it miss. - Give a latency budget in round trips and milliseconds, with stated assumptions. - Say what fails at each layer and how you would see it. - Finish with how each layer scales: DNS and anycast, edge caching, connection reuse, stateless app servers, caches and read replicas.

Key concepts

HSTS
HTTP cache and service worker
Stub and recursive resolvers
Root, TLD and authoritative servers
TTL
GeoDNS and anycast
NAT
BGP
TCP handshake
TLS 1.3, SNI and ALPN
QUIC and HTTP/3
CDN edge cache
L4 vs L7 load balancing
Reverse proxy
Cache-Control
Critical rendering path
TTFB, LCP and INP

Functional requirements

Turn what the user typed into a URL: scheme, host, port and path, or a search if it is not a URL
Serve the page from a browser cache or a service worker when a fresh copy exists
Resolve abc.com to an address near the user
Set up an encrypted connection to that address and send an HTTP request
Answer from the CDN edge when it has a fresh copy; otherwise forward to the origin
At the origin, route the request, run the handler, read from the cache and the database, and build the response
Return the response with a status code and caching headers, and render it in the browser

Non-functional requirements

Time to first byte under 800 ms at the 75th percentile, the web.dev "good" threshold
Largest Contentful Paint under 2.5 s and Interaction to Next Paint under 200 ms at the 75th percentile (web.dev thresholds)
HTTPS only; a downgrade to plain HTTP is never possible after the first visit (HSTS)
No single server, zone or edge location whose loss takes the site down
Bursts of traffic and attacks are absorbed at the edge before they reach the origin
Every layer is observable: DNS answers, connection times, cache hit ratio, origin latency and errors

Interview questions

What happens, layer by layer, when you type abc.com and press Enter?
Why does the DNS lookup need ARP and the routing table?
How does the browser know which certificate to trust, and what does it check?
What does HTTP/3 change, and when is it not used?
Where is the page actually served from?
Users in one country report that the site is slow. How do you find the layer?
What do 502 and 504 mean, and who sends them?
How would you make the page load faster?