What Happens When You Type a URL and Press Enter?
The classic interview question, actually answered end to end — DNS, TCP, TLS, HTTP, and rendering, in the order they really happen.
This question gets asked because a real answer touches almost every layer of how the web works, and a memorized one-liner ('it loads the page') makes that obvious immediately. Here's the actual sequence, in order.
1. DNS resolution — turning a name into an address
The browser needs an IP address for `sahildurgia.dev`, not the name itself. It checks its own cache, then the OS cache, then queries a DNS resolver (usually your ISP's or a public one like 1.1.1.1), which walks the DNS hierarchy — root servers, then `.dev`'s TLD servers, then the domain's own nameservers — until it gets back an IP address.
2. TCP connection — a reliable pipe
The browser opens a TCP connection to that IP via a three-way handshake (SYN, SYN-ACK, ACK) — establishing a reliable, ordered byte stream before any actual content is exchanged.
3. TLS handshake — for HTTPS
For an HTTPS site (which should be all of them — next post covers why), a TLS handshake happens on top of that TCP connection: the server presents a certificate, the browser verifies it against a trusted certificate authority, and both sides negotiate a shared encryption key for the session.
4. The HTTP request and response
Now the browser actually sends an HTTP request — method, path, headers — and the server responds with a status code, headers, and a body (HTML, in the case of a page load).
5. Parsing and rendering
The browser parses the HTML into the DOM, the CSS into the CSSOM, combines them into a render tree, computes layout, and paints pixels — the exact mechanism the next-but-one post in this series covers in depth. Along the way, the parser hits `<script>` and `<link>` tags, triggering more requests (through the same DNS → TCP → TLS → HTTP sequence, potentially to different servers) for JavaScript, CSS, images, and fonts.
Why this question is actually a good one
A strong answer demonstrates you understand that a page load isn't one thing — it's a stack of protocols and processes, each with its own real cost (DNS lookup time, TLS handshake round-trips, render-blocking resources), and that performance work at any single layer (a CDN reducing DNS/connection latency, HTTP/2 multiplexing requests, deferring non-critical JS) is targeting a specific, nameable stage of this exact sequence.