What happens when you type a URL

Overview

This is the most common warm-up question in system design interviews. Typing https://shop.example.com/cart and pressing Enter triggers a chain: URL parsing, DNS resolution, a TCP connection, a TLS handshake, the HTTP request, server-side processing, the response, and finally the browser rendering HTML, CSS, and JavaScript, often making dozens of further requests.

A great answer walks through each stage, names what can be cached or skipped, and points out where latency comes from. It also shows you understand the systems behind the scenes: DNS resolvers, CDNs, load balancers, application servers, caches, and databases.

When to use it

• Interview warm-up questions about web fundamentals.
• Diagnosing slow page loads: which stage takes the time?
• Explaining where CDNs, load balancers, and caches sit in the path.
• Planning performance optimizations such as preconnect and HTTP/2.

Where it shows up in interviews

Where it is used in real software

Key terms

TTFB

Time to first byte: from sending the request to receiving the first response byte.

Critical rendering path

The steps the browser takes to turn HTML, CSS, and JS into pixels.

Keep-alive

Reusing a TCP/TLS connection for multiple requests.

HSTS

A header telling browsers to always use HTTPS for a domain.

The full request lifecycle

1. 1
   Parse the URL and check caches

   Scheme (https), host (shop.example.com), path (/cart). The browser checks HSTS and its HTTP cache; a fresh cached response may skip the network entirely.

2. 2
   Resolve DNS

   Browser cache, OS cache, then a recursive resolver, which may query root, TLD, and authoritative name servers to get the IP address.

3. 3
   Open a TCP connection

   Three-way handshake SYN, SYN-ACK, ACK: one round trip. With HTTP/3 this is QUIC over UDP instead.

4. 4
   TLS handshake

   Negotiate the cipher, verify the server certificate against trusted authorities, and derive session keys. TLS 1.3 needs one round trip.

5. 5
   Send the HTTP request

   GET /cart with headers like Host, Cookie, and Accept. It usually reaches a CDN or load balancer first.

6. 6
   Server processes the request

   Load balancer routes to an app server, which authenticates the session, reads caches or databases, and renders a response.

7. 7
   Browser renders

   Parse HTML into the DOM, fetch CSS and JS, build the render tree, lay out, and paint. Additional resources trigger more requests, reusing the connection.

Where the time goes on a first visit (100 ms RTT)

Cold visit, no cached DNS or connections, TLS 1.3, HTTP/2

Roughly 600-800 ms before first paint, mostly round trips rather than server work. That is why CDNs (shorter RTT), connection reuse, HTTP/3 (fewer handshakes), and inlining critical CSS matter so much.

Implementation

1# Break a request into its stages2curl -o /dev/null -s -w '3  dns:        %{time_namelookup}s4  tcp:        %{time_connect}s5  tls:        %{time_appconnect}s6  first byte: %{time_starttransfer}s7  total:      %{time_total}s8' https://example.com

Complexity and performance

Trade-offs

Variants and related techniques

Common mistakes

• Skipping DNS and TLS in the explanation.

  Fix: Interviewers expect each stage: DNS, TCP, TLS, HTTP, server, rendering.

• Forgetting redirects.

  Fix: http:// to https:// or example.com to www.example.com adds full round trips; HSTS preload avoids the first one.

• Treating the server as a single box.

  Fix: Mention CDN, load balancer, app servers, cache, and database.

Interview questions

Practice problems