Walk me through everything that happens when you type a URL into the browser and press enter.

Before anything touches the network

The browser first decides whether what you typed is a URL at all or a search term, then normalises it: scheme, host lowercased, IDN hostnames punycoded, default port filled in. Two lookups happen locally before any packet leaves the machine. The HSTS list, which combines a preloaded list shipped with the browser and entries learned from previous Strict-Transport-Security headers, can rewrite http:// to https:// so no cleartext request is ever made. Then the HTTP cache is consulted: if a stored response for that URL is still fresh by its Cache-Control lifetime, the browser serves it and the rest of this answer never happens. If a service worker is registered for the scope, its fetch handler intercepts ahead of even that.

Saying this part out loud matters, because the most common real-world answer to "why was this request fast" is that there was no request.

DNS resolution

The hostname has to become an IP address, and there is a stack of caches to get through. The browser keeps its own small DNS cache. Below it the OS stub resolver has one, backed by systemd-resolved or nscd on Linux and the DNS Client service on Windows, and it consults the hosts file first. Only on a miss does a query go onto the wire.

That query is a single recursive query to the configured resolver: your ISP's, your router's, or a public one like 1.1.1.1. The resolver does the actual work, which is iterative. It asks a root server, which does not know the answer but returns a referral to the .com nameservers. It asks those, which refer it to the authoritative nameservers for the zone. It asks one of those, which returns the A or AAAA record. Every step is cached at the resolver under the record's TTL, and because root and TLD data is cached almost permanently in practice, a real cold lookup is usually one or two round trips from the resolver rather than three. The client sees only one round trip to the resolver plus however long the resolver takes.

Getting the recursive-versus-iterative distinction the wrong way round is the single most common factual slip in this answer. The candidate is recursive to their resolver; the resolver is iterative to the world.

TCP and TLS

With an address, the browser opens a TCP connection: SYN, SYN-ACK, ACK. Application data can ride the third packet, so treat TCP setup as one round trip of latency.

Then TLS. In TLS 1.3 the client's first flight already carries a key share for its guessed group, the server replies with its own key share, certificate and Finished, and the client can send the HTTP request immediately after verifying. That is one round trip. TLS 1.2 needed two, because ClientHello and ServerHello only negotiated parameters and the key exchange happened in a second flight. So a fresh HTTPS connection costs two round trips before the request over TLS 1.3, and three over TLS 1.2. Attributing the saving to "modern TLS" without naming 1.3 is what interviewers listen for here.

Count the arrows after the address is known: one round trip for TCP, one for TLS 1.3, and only then a request.

sequenceDiagram
    participant B as Browser
    participant R as Resolver
    participant N as Authoritative nameserver
    participant S as Server
    B->>R: One recursive query
    R->>N: Iterative walk from root and TLD
    N-->>R: A or AAAA record
    R-->>B: Address
    B->>S: SYN, SYN-ACK, ACK - one RTT
    B->>S: ClientHello with key share
    S-->>B: ServerHello, certificate, Finished - one RTT
    B->>S: GET with host and cookies
    S-->>B: Streamed response, parsed as it arrives

ALPN is negotiated inside that handshake, which is how the browser and server agree on HTTP/1.1 or HTTP/2 without spending a round trip on it, and SNI is what lets one IP serve certificates for many hostnames. TLS 1.3 session resumption with a pre-shared key allows 0-RTT early data, but that data is replayable by an on-path attacker, so browsers only use it for requests they consider safe to retry.

The request and the response

The request is a method, path and headers: Host in HTTP/1.1, the :authority pseudo-header in HTTP/2 and HTTP/3, cookies scoped by domain and path, Accept-Encoding, and any validators like If-None-Match for a cached-but-stale entry, which the server can answer with a bodyless 304.

The response arrives as a stream, and the browser does not wait for it to finish. The HTML parser builds the DOM incrementally while a preload scanner runs ahead of it, spotting subresource URLs and starting those fetches early. A synchronous <script> without defer or async blocks the parser, because the script could call document.write. A stylesheet does not block parsing but does block rendering, since the render tree needs the CSSOM. Layout, paint and compositing then produce pixels. A 3xx restarts the whole sequence at the new URL, and if it points at a different origin, at DNS.

Where HTTP/3 changes the picture

QUIC (RFC 9000) runs over UDP and merges the transport handshake with the TLS 1.3 cryptographic handshake into a single exchange. That is where the removed round trip comes from: not a faster TLS, but the elimination of a separate TCP handshake underneath it.

TCP + TLS 1.2   SYN/SYN-ACK  +  2 RTT handshake   = 3 RTT to first byte of request
TCP + TLS 1.3   SYN/SYN-ACK  +  1 RTT handshake   = 2 RTT
QUIC + HTTP/3   combined transport+crypto         = 1 RTT (0 on resumption)

The second change is head-of-line blocking, and the levels have to be kept straight. HTTP/1.1 blocked at the application layer: one outstanding request per connection, responses in order, which is why browsers opened six connections per origin. HTTP/2 fixed that with multiplexed streams, but it multiplexes them over one TCP connection, and TCP delivers a single in-order byte stream. One lost segment therefore stalls every stream sharing that connection, even streams whose own bytes have already arrived. QUIC tracks delivery per stream, so a lost packet only blocks the stream whose data it carried. QPACK, HTTP/3's header compression, was deliberately designed so the encoder can avoid cross-stream references that would reintroduce the dependency.

The overclaim to avoid

The tempting summary is "HTTP/3 is a round trip faster, so the page you just typed loads faster". Usually it is not, on that first request. The browser has no way to know an origin speaks HTTP/3 until it is told, either by an Alt-Svc header on an earlier HTTP/1.1 or HTTP/2 response or by an HTTPS/SVCB DNS record advertising alpn="h3". So the very first connection to an unfamiliar origin typically goes over TCP and TLS, HTTP/3 gets used on subsequent connections, and browsers will race QUIC against TCP rather than gamble on UDP being reachable. The per-stream loss recovery is also worth most on lossy or high-latency paths; on a clean wired link the difference against HTTP/2 is small. Claiming a universal win is how a strong answer turns into a rehearsed one.

Count the round trips explicitly and say which protocol version buys each saving. "TCP plus TLS 1.3 is two round trips, QUIC is one because it fuses them" is a better answer than any amount of description, because it shows you know where the latency actually goes.