What Happens When You Type a URL? The Full Request Lifecycle Explained

"What happens when you type a URL into your browser and press Enter?" is a classic interview question because the answer touches almost every layer of modern computing: networking, security, distributed systems, backend services and browser rendering. Understanding the journey also shows you exactly where latency comes from and where to optimize.

Let's follow a request to https://shop.example.com/products/42.

#Key takeaways

• The journey: URL parsing → DNS → TCP → TLS → HTTP request → CDN/load balancer → app server → database/cache → response → browser rendering.
• Each network round trip adds latency. Connection reuse, CDNs, HTTP/2 and HTTP/3 and caching all attack round trips.
• DNS and TLS can add noticeable time to the first request; later requests reuse the connection.
• On the server side, database queries and downstream calls usually dominate response time.
• In the browser, render-blocking resources and JavaScript often matter more than raw network speed.

#1. The browser parses the URL

texthttps://shop.example.com:443/products/42?ref=home#reviews
scheme   host             port path        query    fragment

The browser checks whether it's a URL or a search term, applies HSTS (if the domain requires HTTPS, it upgrades automatically), and checks its caches: maybe the page or resources can be served without the network at all.

#2. DNS resolution: name → IP address

Computers route packets to IP addresses, not names. The browser needs the IP for shop.example.com:

1. Browser cache → OS cache → configured resolver (your ISP's or a public resolver).
2. If uncached, the recursive resolver walks the DNS hierarchy:
   • A root server points to the .com TLD servers.
   • The TLD server points to example.com's authoritative name servers.
   • The authoritative server returns the record, often a CNAME to a CDN, which ultimately resolves to an IP near you.
3. Results are cached according to their TTL.

A cold DNS lookup can take tens of milliseconds or more; cached lookups are nearly instant. CDNs and global load balancers often use DNS (or anycast routing) to direct you to a nearby location.

#3. TCP connection: the handshake

For HTTP/1.1 and HTTP/2, the browser opens a TCP connection:

textClient → SYN       → Server
Client ← SYN-ACK   ← Server
Client → ACK       → Server     (1 round trip before data can flow)

TCP provides reliable, ordered delivery with retransmission and congestion control. Every round trip costs time, roughly proportional to physical distance. That's why serving users from nearby locations matters (what is a CDN).

#4. TLS handshake: making it secure

HTTPS wraps the connection in TLS:

• The server presents its certificate; the browser verifies it chains to a trusted certificate authority and matches the domain.
• Client and server agree on keys, using ephemeral key exchange for forward secrecy.
• TLS 1.3 needs one round trip for a full handshake (and can resume with zero round trips in some cases), compared with two for TLS 1.2.

After this, everything is encrypted and integrity-protected.

HTTP/3 runs over QUIC (on UDP), combining transport and TLS handshakes to reduce setup round trips, and avoiding TCP's head-of-line blocking when packets are lost.

#5. The HTTP request

httpGET /products/42?ref=home HTTP/2
Host: shop.example.com
Accept: text/html
Accept-Encoding: gzip, br
Cookie: session=abc123
User-Agent: Mozilla/5.0 ...

The fragment (#reviews) never leaves the browser. It's used client-side to scroll to an element.

#6. The edge: CDN, WAF and load balancer

The request typically lands at an edge location:

• The CDN checks its cache. For static assets, or cacheable HTML, it can answer immediately.
• A web application firewall (WAF) may filter malicious traffic, and rate limiting protects against abuse (rate limiting algorithms).
• On a cache miss, the request goes to the origin's load balancer, which picks a healthy application server (how load balancers work).

#7. The application server

Inside your backend:

1. Middleware parses the request, validates the session or token (authentication vs authorization) and applies routing.
2. The handler for /products/42 runs business logic.
3. It checks a cache such as Redis for product data (caching strategies).
4. On a miss, it queries the database, ideally hitting an index (how database indexes work).
5. It may call other services (pricing, inventory, recommendations) over the network.
6. It renders HTML (server-side rendering) or returns JSON for a client-side app.

This is usually where the most time goes: slow queries, N+1 query patterns and sequential downstream calls. Tracing makes it visible (observability explained).

#8. The response travels back

httpHTTP/2 200
Content-Type: text/html; charset=utf-8
Content-Encoding: br
Cache-Control: private, max-age=0

Compression (gzip or Brotli) shrinks the payload. Caching headers tell browsers and CDNs what they may store and for how long.

#9. The browser renders the page

Now the browser turns bytes into pixels:

1. Parse HTML → DOM. When it encounters CSS and JavaScript references, it fetches them (often over the same HTTP/2 or HTTP/3 connection).
2. Parse CSS → CSSOM. CSS is render-blocking: the browser won't paint until it knows the styles.
3. JavaScript can block parsing unless it's marked defer or async or loaded as a module.
4. Render tree → layout → paint → composite: compute positions and sizes, draw pixels and compose layers.
5. JavaScript frameworks may hydrate the page, attaching event handlers to server-rendered HTML.

User-perceived speed is captured by Core Web Vitals: LCP (loading), INP (responsiveness) and CLS (visual stability) (Core Web Vitals guide).

#Where the time goes: a rough budget

See latency numbers every engineer should know for the physics behind these costs.

#FAQ

#Why is the first visit to a site slower than later ones?

The first visit pays for DNS lookups, new connections, TLS handshakes and downloading all assets. Later visits reuse cached DNS, open connections and cached assets.

#What's the difference between HTTP/1.1, HTTP/2 and HTTP/3?

HTTP/1.1 handles one request at a time per connection. HTTP/2 multiplexes many requests over one TCP connection. HTTP/3 runs over QUIC on UDP, with faster connection setup and better performance when packets are lost.

#Does HTTPS make websites slower?

Modern TLS adds very little overhead, especially with TLS 1.3, connection reuse and session resumption. HTTPS is also required for HTTP/2 in browsers and for HTTP/3, which bring their own performance gains.

#What is a round-trip time (RTT)?

The time for a packet to travel from client to server and back. It's bounded by physical distance and network routing, which is why CDNs and regional deployments reduce latency.