Skip to content

01. Internet Request Lifecycle — from URL bar to painted pixels

~14 min read. A simple page load hides many tiny network trips.

Built on the ELI5 in 00-eli5.md. The envelope — headers outside, data inside — travels through every step below.

1) See the actors before tracing the trip

One page load involves your browser, resolver, network, and server. Your browser holds cookies, cache entries, and rendering state already. The phone book may answer the hostname before any packet leaves. The post office chain forwards packets toward the edge or origin. ┌──────────┐ ask name ┌────────────┐ │ Browser │ ──────────────▶ │ DNS cache │ └────┬─────┘ └────┬───────┘ │ │ │ HTTPS request │ ▼ ▼ ┌──────────┐ many hops ┌────────────────┐ │ Wi-Fi/AP │ ───────────▶ │ routers / CDN │ └────┬─────┘ └────┬───────────┘ │ │ └──────────────▶ ┌─────────▼─────────┐ │ app server + HTML │ └───────────────────┘ The page feels instant only when several earlier answers are cached. Miss one cache, and extra round trips appear immediately.

2) The 14-step trip, with timing

Assume Delhi user, Mumbai CDN edge, and 24 ms round-trip time. Assume browser cache miss, DNS cache miss, and fresh HTTPS connection. 1. You type https://shop.example.com/cart?id=42 into the address bar. The browser parses scheme, hostname, path, and query parameters. Typical time: 0.1 ms. This step decides whether DNS and TLS are required. 2. The browser checks HSTS, service worker rules, and local caches. It asks, "Can I reuse something before touching the network?" Typical time: 0.4 ms. A warm cache can skip many later steps. 3. The browser asks the OS for shop.example.com resolution. The OS checks its own cache first. Typical time: 0.2 ms. This is the first phone book check. 4. The recursive resolver performs DNS lookup on a cache miss. It may contact root, TLD, and authoritative servers. Typical time: 18 ms. Now the hostname becomes an IP address. 5. The browser sends a TCP SYN toward the server IP. This opens a reliable path for ordered delivery. Typical time: 12 ms one way. Think of a registered-mail request entering the first post office. 6. The server replies with SYN-ACK. It agrees to the connection and advertises initial settings. Typical time: 12 ms back. Now both sides know sequence numbering will begin. 7. The browser sends the final ACK. The socket becomes established on both ends. Typical time: 12 ms one way. At this point, TCP is ready but traffic is still unencrypted. 8. The browser sends TLS ClientHello. It offers cipher suites, TLS version, and random bytes. Typical time: 12 ms one way. This is asking for a sealed envelope format. 9. The server returns ServerHello and certificate chain. It selects parameters and proves its claimed identity. Typical time: 12 ms back. The browser now starts trust verification. 10. The browser verifies the certificate and sends key-share data. It checks hostname match, dates, and issuing authority. Typical time: 8 ms CPU plus 12 ms send. Now both sides can derive a shared session key. 11. The server confirms TLS completion. Encrypted application data may now flow safely. Typical time: 12 ms back. The envelope can travel, but outsiders cannot read it. 12. The browser sends the HTTP GET request. Example: GET /cart?id=42 HTTP/1.1 with headers and cookies. Typical time: 1 ms to serialize, 12 ms on the wire. Now the request reaches CDN or origin logic. 13. The server processes the request and returns the first byte. Assume cache lookup, session check, and HTML generation. Typical time: 35 ms server work plus 12 ms return. This is measured as Time To First Byte, or TTFB. 14. The browser parses HTML, fetches critical assets, and paints. CSS blocks render; JavaScript may delay interactivity. Typical time: 28 ms for first paint in this simple example. The network trip ends, and the rendering trip begins.

3) Turn those steps into a timing budget

Here is one concrete timeline for the same page load. 0.0 ms: URL parsing starts. 0.5 ms: local checks finish. 18.7 ms: DNS answer returns. 30.7 ms: SYN reaches server. 42.7 ms: SYN-ACK returns. 54.7 ms: final ACK reaches server. 66.7 ms: ClientHello reaches server. 78.7 ms: ServerHello and certificate return. 98.7 ms: browser verification and key-share send complete. 110.7 ms: server Finished arrives. 123.0 ms: encrypted HTTP request reaches edge. 158.0 ms: server finishes work. 170.0 ms: first HTML byte reaches browser. 198.0 ms: first paint appears. So, a "fast" first page still needs roughly 198 ms. Now compare that with a reused connection and cached DNS. DNS can drop from 18 ms to almost zero. TCP and TLS can disappear with connection reuse. Then 198 ms can become nearly 60 ms. That is why repeat navigations often feel magically faster.

4) Know what rides inside the request envelope

A real request carries more than a path string. It includes method, headers, cookies, and sometimes a body. The response also carries headers, status, and payload bytes. ┌────────────────────────────────────────────┐ │ IP header │ TCP header │ TLS │ HTTP │ HTML │ └────────────────────────────────────────────┘ Outer headers help routing across the network. Inner protocol fields help reliability and security. Application data sits deepest, like the letter inside layers. Worked example with concrete sizes helps memory. IP header: 20 bytes. TCP header: 20 bytes without options. TLS record overhead: roughly 20-30 bytes, depending on mode. HTTP request headers: maybe 700 bytes with cookies. HTML payload: maybe 14 KB for a simple landing page. So one visible click often creates several small and large packets. Large responses get split into many envelopes automatically.

5) What usually makes this trip slower

DNS misses add lookup latency immediately. Long-distance RTT multiplies handshake cost painfully. TLS certificate chains can add CPU verification time. Redirects create a full second request lifecycle. Render-blocking CSS delays first paint after network completion. Huge JavaScript delays interaction after first paint. Example with numbers makes the pain obvious. Add one 301 redirect at 170 ms, and total jumps near 340 ms. Add an origin trip instead of edge cache, and 35 ms becomes 120 ms. Add packet loss, and retransmissions can cost one more RTT. So system design answers should separate network delay from server delay. That separation shows where the real bottleneck lives. A second worked example helps in interviews. Warm DNS cache: 0 ms. Reused TCP connection: 0 ms. Reused TLS session: 0-5 ms. HTTP request serialization: 1 ms. Edge cache hit: 8 ms. Response travel back: 12 ms. HTML parse and first paint: 20 ms. Total can land near 41-46 ms. That feels instant on a human timescale. So two pages from the same site can feel wildly different. The first visit pays discovery and trust costs. Later visits mostly pay application and rendering costs. That framing makes waterfall charts easier to explain. Always separate cold path and warm path in answers.

Where this lives in the wild

  1. Amazon frontend engineer measures TTFB, DNS, and TLS during checkout flows. Fast first byte protects cart conversion on expensive purchase journeys.
  2. Cloudflare edge engineer reduces round trips by terminating TLS near users. Closer edges shrink handshake cost for every first request.
  3. Flipkart mobile web engineer fights render-blocking CSS during festival traffic spikes. Network completion alone does not guarantee visible pixels.
  4. Google Chrome performance engineer studies connection reuse and preconnect hints. Small browser decisions remove entire handshake phases.
  5. Razorpay platform engineer tracks redirects and certificate issues on payment pages. A single extra handshake can hurt payment completion rates.

Pause and recall

  1. Which step turns a hostname into a numeric destination?
  2. Why can repeated visits skip TCP and TLS setup entirely?
  3. What metric ends when the browser receives the first response byte?
  4. Why might users still wait after a fast TTFB?

Interview Q&A

Q1. What happens after a user types a URL and presses Enter? Start with parsing, cache checks, DNS, TCP, TLS, HTTP, server work, and render. Then mention concrete timing buckets for each network round trip. Common wrong answer to avoid: "Browser directly calls the server and gets HTML." Q2. Why does distance matter even for tiny requests? Each handshake consumes round trips, not just payload transfer time. Higher RTT multiplies DNS, TCP, TLS, and retransmission costs. Common wrong answer to avoid: "Only large responses care about distance." Q3. Why can a CDN improve the request lifecycle? It moves the responding server closer to the user. That reduces RTT, often avoids origin work, and lowers TTFB. Common wrong answer to avoid: "CDN only helps static images, not HTML." Q4. What should you optimize first on a slow first page? Break total time into DNS, connect, TLS, TTFB, and render. Then attack the largest bucket with measurements, not guesses. Common wrong answer to avoid: "Compress the HTML first, without measuring anything."

Apply now (5 min)

Open any shopping site in browser DevTools, Network tab. Pick the main HTML document, not an image or script. Write down DNS time, connect time, SSL time, and TTFB. Now explain each number using the 14-step model above. If DNS is zero, say which earlier cache probably answered. If SSL is zero, say which connection was likely reused. Sketch from memory Draw browser, resolver, routers, CDN, and origin boxes. Label where DNS ends and TCP begins. Label where TLS ends and HTTP begins. Then write the four largest timing buckets beside the diagram.

Bridge. The first big mystery in that journey is name resolution. Before packets move, someone must translate a human name into a numeric destination. → 02-dns-deep-dive.md