What Happens When You Type a URL
The evergreen interview question — answered layer by layer, from keystroke to pixels.
The Whole Journey at a Glance
This one question touches every guide in this pillar. The strong answer names the stages in order and can zoom into any of them on request:
Before the Network: Parse & Cache Checks
The browser first decides is this a URL or a search?, normalizes it (adds https://, punycodes unicode hosts), then races through caches before touching the wire: HSTS list (force HTTPS?), browser DNS cache, OS cache, even the HTTP cache — a fresh cached page can skip the network entirely.
Cache-Control: max-age plus a valid cached copy means steps 2-7 simply don’t happen.On the Server Side
Your packet rarely hits “the server”. It lands on a load balancer (which terminated TLS, often), gets routed to one of many app instances, which consults caches (Redis), then the database, renders or serializes a response, and hands it back. Every arrow here is another network hop with its own latency budget.
| Hop | Typical latency |
|---|---|
| CDN edge cache hit | ~10–30 ms total — origin never touched |
| LB → app server | <1 ms (same datacenter) |
| App → Redis | ~0.5 ms |
| App → SQL database | 1–10 ms per query |
| Cross-region origin call | 50–150 ms |
Rendering: Bytes to Pixels
The browser parses HTML into the DOM, CSS into the CSSOM, combines them into the render tree, computes layout, and paints. Parsing pauses on synchronous <script> tags (they can mutate the DOM), which is why scripts go at the bottom or carry defer. Subresources (CSS, JS, images) each restart the journey — DNS, TCP, TLS, HTTP — though usually reusing the warm connection.
A complete answer ends here: “…and the page paints. Want me to zoom into DNS, TLS, the server side, or rendering?” — showing you know the map and the territory.
Interview Questions
Give the 30-second version.
Parse the URL → resolve the name via DNS (caches first) → TCP three-way handshake to port 443 → TLS handshake, certificate verified → send the HTTP request → server (LB, app, cache, DB) builds a response → browser parses HTML, fetches subresources, lays out and paints.
Where can this be slow, and how do you find out?
Each stage has a signature: slow DNS (first visit only), slow TLS/TCP (high RTT — move closer via CDN), slow TTFB (server/DB work), slow render (huge JS). Browser devtools’ network waterfall breaks a request into exactly these phases.
What changes on the second visit?
Warm caches everywhere: DNS cached, connection possibly kept alive (skip TCP+TLS), HTTP cache may serve 304 or skip the request entirely, and HTTP/3 0-RTT can send data in the first flight.
Why port 443 and who decided that?
The scheme implies the default port: https→443, http→80. IANA assigns well-known ports; the URL can override with an explicit :port.