The Problem Statement

Interviewer: "Walk me through what happens when you type https://example.com into your browser and press Enter. Be as detailed as you can."

This is the single most common interview question in all of system design and networking interviews. It shows up at every level, from new grad to staff engineer. The depth of your answer is how the interviewer calibrates your seniority.

The question tests four things at once: your understanding of networking fundamentals (DNS, TCP, TLS), your knowledge of how backend systems process requests (load balancers, app servers, databases), your awareness of browser internals (rendering pipeline, resource loading), and your ability to explain a complex multi-step process clearly.

I have seen candidates spend 90 seconds on this and stop at "the server sends back HTML." Strong candidates take 5 minutes, cover 7 distinct phases, and the interviewer has to stop them because they are running out of time in a good way.

Clarifying the Scenario

You: "Great question. I want to make sure I cover this at the right depth."

You: "Should I focus on the networking layers (DNS, TCP, TLS), the server-side processing, the browser rendering pipeline, or all of the above?"

Interviewer: "All of it. I want the full journey."

You: "OK. And should I assume HTTPS, HTTP/2, and a modern browser?"

Interviewer: "Yes, assume a modern setup."

You: "Perfect. I will walk through this in seven phases: DNS resolution, TCP handshake, TLS negotiation, HTTP request, server processing, response transmission, and browser rendering. I will call out the latency at each step so you can see where the time goes."

My Approach

I break this into seven sequential phases. Each phase must complete before the next can begin (with some pipelining exceptions in HTTP/2):

1. DNS resolution: Turn the hostname into an IP address
2. TCP handshake: Establish a reliable connection to that IP
3. TLS 1.3 handshake: Negotiate encryption on top of TCP
4. HTTP request: Send the actual request for the page
5. Server processing: Load balancer, app server, database queries, response generation
6. Response transmission: Server sends the response back over the encrypted connection
7. Browser rendering: Parse HTML, fetch sub-resources, build the render tree, paint pixels

The total time from keypress to first meaningful paint is typically 500ms to 3 seconds, depending on network conditions, server performance, and page complexity. I will annotate each phase with realistic latency numbers.

The Architecture

Here is the full walkthrough. When the user types a URL and presses Enter, the browser first parses the URL to extract the scheme (https), hostname (example.com), and path (/). It checks the HSTS (HTTP Strict Transport Security) preload list to confirm HTTPS is required. Then it checks its local DNS cache, the OS cache, and the router cache before reaching out to a recursive resolver.

The DNS resolution returns an IP address. The browser opens a TCP connection to that IP on port 443, negotiates TLS encryption, and then sends the HTTP request. The server processes the request and sends back an HTML document. The browser parses that document and kicks off the rendering pipeline.

Each of these phases has nuance that distinguishes a junior answer from a senior one. Let me go deep on the three most interesting parts.

DNS Resolution: From Hostname to IP Address

This is the first network operation that happens, and it is often the most underestimated in terms of latency impact.

The DNS lookup is a hierarchical resolution. The recursive resolver (your ISP's DNS, Google's 8.8.8.8, or Cloudflare's 1.1.1.1) does the heavy lifting. It walks down the DNS tree from root servers to TLD servers to the authoritative nameserver for the domain.

In practice, most of this is cached. The recursive resolver has seen example.com before and has the answer cached with its TTL. A fully cached lookup takes under 1ms. An uncached lookup requires 3-4 round trips and can take 50-200ms.

For your interview: say "DNS resolves the hostname through a hierarchy of root, TLD, and authoritative servers, but in practice most lookups are cache hits at the recursive resolver layer." That one sentence covers the fundamentals and shows production awareness.

What About DNS over HTTPS (DoH)?

Traditional DNS queries are sent in plaintext over UDP. Anyone on the network (ISPs, public WiFi operators) can see which domains you are resolving. DNS over HTTPS (DoH) encrypts DNS queries inside an HTTPS connection to the resolver (like Cloudflare's 1.1.1.1 or Google's 8.8.8.8).

The tradeoff: DoH adds the overhead of a TLS connection to the resolver, but this connection is typically reused across multiple lookups. The first DoH query is slower (needs its own TCP + TLS handshake to the resolver), but subsequent queries are fast because they reuse the encrypted channel. Firefox and Chrome support DoH by default with compatible resolvers.

I would not go deep on DoH unless the interviewer asks, but mentioning it briefly shows you are current on network security trends.

The AAAA Record and IPv6

If the domain has both an A record (IPv4) and an AAAA record (IPv6), the browser uses the Happy Eyeballs algorithm (RFC 8305). It starts both IPv4 and IPv6 connections simultaneously and uses whichever connects first. The losing connection is cancelled.

This is relevant because IPv6 adoption is growing (over 40% of Google traffic is IPv6), and some networks are IPv6-only with NAT64 translation. Mentioning Happy Eyeballs in an interview is a nice touch that shows depth, but only bring it up if the interviewer is going deep on DNS.

The TCP Three-Way Handshake

This step is straightforward but worth explaining clearly because it sets up the mental model for latency.

The browser initiates a TCP connection to the server's IP address on port 443 (HTTPS). TCP is a reliable, ordered, byte-stream protocol. Before any data can flow, the client and server must agree to communicate. This agreement is the three-way handshake:

1. SYN: The client sends a SYN (synchronize) packet with an initial sequence number.
2. SYN-ACK: The server responds with a SYN-ACK, acknowledging the client's sequence number and providing its own.
3. ACK: The client acknowledges the server's sequence number. The connection is now established.

This costs exactly one round trip. If the server is 50ms away, the handshake takes 50ms. If the server is on another continent (150ms), it takes 150ms. This is why geographic proximity matters so much for performance, and why CDNs place servers close to users.

With TCP Fast Open (TFO), the client can include data in the SYN packet on repeat connections, saving one round trip. However, TFO has limited adoption because of middlebox interference (firewalls and NATs that do not expect data in SYN packets). QUIC (used by HTTP/3) eliminates this problem entirely by combining connection establishment with encryption in a single round trip.

I would keep the TCP explanation to 2-3 sentences in most interviews: "TCP three-way handshake costs one round trip. The client and server exchange SYN/SYN-ACK/ACK to establish sequence numbers for reliable delivery."

The TLS 1.3 Handshake

After the TCP three-way handshake (SYN, SYN-ACK, ACK, costing 1 RTT), the browser and server negotiate encryption via TLS. TLS 1.3 reduced this to a single round trip, down from two in TLS 1.2.

Here is what makes TLS 1.3 faster than TLS 1.2. In TLS 1.2, the client and server first agree on cipher suites, then exchange keys in a separate round trip. TLS 1.3 combines these: the client guesses which key exchange algorithm the server will choose and sends its key share in the very first message. If the guess is right (it almost always is), the handshake completes in a single round trip.

The client also sends the Server Name Indication (SNI) in the ClientHello. This tells the server which domain the client wants to reach, which is critical when the server hosts multiple domains on the same IP. Without SNI, the server would not know which TLS certificate to present.

After the TLS handshake, the browser and server have a shared symmetric key. All subsequent data (the HTTP request and response) is encrypted with this key. The overhead of encryption on modern hardware (with AES-NI instructions) is negligible, typically less than 1% CPU overhead.

Certificate Chain Verification

One detail worth expanding on: when the server sends its certificate, the browser does not just check "is this certificate valid?" It verifies the entire chain of trust.

The server's certificate is signed by an intermediate Certificate Authority (CA). That intermediate CA's certificate is signed by a root CA. The browser has a built-in trust store of ~150 root CA certificates. It walks up the chain until it reaches a trusted root, checking each signature along the way.

The browser also checks: is the certificate expired? Does the domain in the certificate match the domain in the URL? Has the certificate been revoked (via CRL or OCSP)? OCSP stapling allows the server to include a pre-fetched OCSP response in the TLS handshake, avoiding an extra round trip to the CA.

In practice, certificate verification adds minimal latency because browsers cache OCSP responses and intermediate certificates. But a misconfigured certificate chain (missing intermediates) is one of the most common causes of TLS errors in production.

HTTP Request and Server Processing

After the encrypted channel is established, the browser sends the actual HTTP request. With HTTP/2, this is a binary-framed stream multiplexed over the single TCP connection.

The request includes: the method (GET), the path (/), the host header, cookies, accept-encoding (for gzip/brotli compression), and any other headers. HTTP/2 compresses these headers using HPACK, which reduces overhead for repeated requests to the same server.

On the server side, the request typically passes through several layers:

1. Load balancer (e.g., AWS ALB, Nginx, HAProxy): Terminates TLS (if not done earlier), routes the request based on path or host, and distributes traffic across backend instances. This adds 1-5ms.

2. Reverse proxy or API gateway: May handle authentication, rate limiting, request logging, and header manipulation. Another 1-5ms.

3. Application server: Executes the route handler, runs business logic, and assembles the response. This might involve:

HTTP/2 Multiplexing and Server Push

HTTP/2 fundamentally changes how the browser loads resources. In HTTP/1.1, the browser opened 6 parallel TCP connections to fetch resources concurrently. HTTP/2 multiplexes all requests over a single TCP connection using binary frames. Each request/response is a "stream" with a unique ID. Multiple streams interleave on the same connection without blocking each other.

HTTP/2 also introduced server push, where the server can proactively send resources to the browser before the browser requests them. For example, when the browser requests index.html, the server can push style.css and app.js because it knows the browser will need them. This saves the time the browser would spend parsing the HTML, discovering the resources, and requesting them.

In practice, server push has not been widely adopted because it is hard to avoid pushing resources the browser already has cached. Chrome has deprecated support for server push in favor of 103 Early Hints, which tells the browser to start preloading resources before the final response arrives. This achieves a similar latency benefit without the caching complexity.

- Checking a cache (Redis, Memcached) for a pre-computed response (1-5ms)

• Querying a database if the cache misses (5-50ms for a typical query)
• Calling other microservices if the architecture is distributed (5-100ms per call)

4. Response generation: The server serializes the response (HTML for a page, JSON for an API), compresses it with gzip or brotli, and sends it back through the load balancer.

The total server processing time varies wildly. A cache-hit response might take 5ms. A complex page requiring multiple database queries and service calls might take 200-500ms. This is where backend optimization (caching strategies, query optimization, connection pooling) has the biggest impact on user-perceived latency.

Response Compression

Modern servers compress responses before sending them. Two main algorithms are in use:

gzip has universal browser support and compresses HTML/CSS/JS by 70-80%. It is the safe default.

Brotli (br) is newer, achieves 15-20% better compression than gzip, and is supported by all modern browsers over HTTPS. Brotli is slower to compress (at high quality levels), so servers often use pre-compressed static files or lower quality levels for dynamic content.

The Accept-Encoding: gzip, br header in the request tells the server which algorithms the browser supports. The server picks the best one and indicates it in the Content-Encoding response header. This compression can reduce a 200KB HTML page to 40-50KB, saving significant transfer time on slow connections.

Browser Rendering Pipeline

This is the phase most backend engineers gloss over, but frontend-heavy companies (Meta, Google, Airbnb) go deep on this. The browser does not just "display the HTML." It runs a multi-stage pipeline to turn bytes into pixels.

The browser processes the HTML document as a stream. As bytes arrive, the tokenizer converts them into tokens (start tags, end tags, text content), which the tree builder assembles into the DOM (Document Object Model) tree.

When the parser encounters a <link> tag for a stylesheet, it kicks off a parallel download. The CSS parser builds the CSSOM (CSS Object Model) tree. Neither the DOM nor CSSOM alone is enough to render. The browser merges them into the render tree, which contains only visible elements (no <head>, no display: none elements).

The render tree drives the layout stage, where the browser calculates the exact position and size of every element using the CSS box model. After layout, the paint stage fills in the pixels (text rendering, background colors, borders, shadows). Finally, the compositor combines painted layers using the GPU and outputs the final frame.

One detail that catches candidates off guard: the browser does not wait for the entire HTML document to arrive before starting to parse. It processes the HTML as a stream. This is called incremental rendering, and it is why a page starts to appear before all assets have loaded. The browser may trigger multiple layout and paint cycles as new content arrives.

Sub-Resource Loading

The initial HTML response is just the beginning. As the browser parses the HTML, it discovers references to external resources: CSS files, JavaScript files, images, fonts, and more. Each of these triggers its own network request, and the browser has a priority system for deciding which resources to fetch first.

CSS files are highest priority because they block rendering. JavaScript files are high priority (they block parsing unless deferred). Images are lower priority. Fonts are medium priority (text renders in a fallback font until the custom font loads, causing a Flash of Unstyled Text, or FOUT).

Modern browsers use a preload scanner that runs ahead of the main HTML parser. While the parser is blocked waiting for a synchronous script to download and execute, the preload scanner continues scanning the HTML for resource URLs and starts fetching them in parallel. This is an optimization that can save hundreds of milliseconds on complex pages.

The <link rel="preload"> hint lets developers tell the browser about critical resources it has not discovered yet (like a font file referenced in CSS, or an API endpoint called by JavaScript). This moves resource discovery earlier, reducing the waterfall of sequential resource loads.

Key Web Vitals and This Pipeline

Google's Core Web Vitals map directly to this rendering pipeline:

• Largest Contentful Paint (LCP): The time until the largest visible element (hero image, heading) is painted. This is affected by everything: DNS, TCP, TLS, server processing, HTML parsing, CSS loading, and the rendering pipeline. Target: under 2.5 seconds.

• First Input Delay (FID) / Interaction to Next Paint (INP): How long until the page responds to user input. This is blocked by JavaScript execution. Long-running scripts on the main thread prevent the browser from processing click and keystroke events. Target: under 200ms.

• Cumulative Layout Shift (CLS): How much the page content shifts around as resources load. Images without explicit dimensions, dynamically injected content, and web fonts cause layout shifts. Target: under 0.1.

Understanding these metrics comes from understanding the rendering pipeline. LCP is slow because of render-blocking CSS. FID/INP is high because of parser-blocking JavaScript. CLS happens because of layout recalculations when late-loading content changes element sizes. Every optimization traces back to a specific stage in the pipeline.

The Tricky Parts

1. HTTP/2 multiplexing changes the mental model. With HTTP/1.1, the browser opened 6 parallel TCP connections to the same host to fetch resources concurrently. HTTP/2 uses a single TCP connection with multiplexed streams. This means one slow resource (like a large image) no longer blocks other resources from the same host. But it also means that one dropped TCP packet can cause head-of-line blocking for all streams, which is why HTTP/3 moved to QUIC (UDP-based). In an interview, I would say: "HTTP/2 solved application-level head-of-line blocking with multiplexing, but introduced TCP-level head-of-line blocking. HTTP/3 solves both by running over QUIC."

2. DNS prefetching and preconnect are invisible but impactful. Modern browsers scan the HTML for links to other domains and start DNS resolution and TCP/TLS handshakes before the page even references those resources. The <link rel="dns-prefetch"> and <link rel="preconnect"> hints let developers control this explicitly. Skipping this in your answer is fine, but mentioning it shows production web performance experience. Chrome's speculative preconnect can save 100-200ms on cross-origin requests.

3. The script tag placement matters more than you think. A <script> tag without async or defer stops DOM parsing entirely. The browser must download, parse, and execute the script before it can continue building the DOM. This is why best practice puts scripts at the bottom of <body> or uses defer (execute after DOM parsing) or async (execute as soon as downloaded, in any order). The difference between async and defer is subtle but important: async scripts execute in download-completion order (non-deterministic), while defer scripts execute in document order (deterministic). Use defer for scripts that depend on the DOM. Use async for independent analytics scripts.

4. Connection reuse changes performance characteristics. If the browser already has an open connection to the server (from a previous page visit or keep-alive), it skips the TCP handshake and TLS negotiation entirely. HTTP/2 connections can stay open for minutes. TLS 1.3 session resumption further reduces overhead. The "first visit" latency is dramatically different from subsequent visits. For repeat visitors, the effective latency is: send HTTP request on existing connection (0ms setup) + server processing + response transfer + render. This can be 10x faster than the first visit.

5. CDNs short-circuit most of the server-side processing. For cacheable resources (images, CSS, JS), the CDN edge server responds directly without reaching the origin server. The DNS resolution returns the CDN edge node's IP, not the origin server's. This means the "server processing" step is often a cache lookup at a POP 20ms away, not a round trip to an origin server 200ms away.

6. HSTS forces HTTPS before the request even leaves the browser. If a user types http://example.com, the browser needs to know to upgrade to HTTPS before making a network request. The HSTS preload list is built into the browser and contains domains that have opted in to always-HTTPS. If the domain is on the list, the browser rewrites the URL to HTTPS locally, avoiding an HTTP-to-HTTPS redirect that would cost an extra round trip. This is a security optimization that many candidates are not aware of.

7. Service workers intercept the network layer. Progressive Web Apps (PWAs) install a service worker that sits between the browser and the network. When the browser makes a request, the service worker intercepts it and can respond from its own cache without hitting the network at all. This means the entire DNS, TCP, TLS, server processing chain is bypassed for cached resources. For offline-capable apps, the service worker is the first line of defense against network failures.

Putting the Latency Budget Together

Here is a rough breakdown of where time goes on a first visit to a page served from an origin server 100ms away:

For a page served from a CDN edge 20ms away, the first four steps collapse to about 100ms total. This is why CDNs are the single most impactful optimization for web performance.

What Most People Get Wrong

How I Would Communicate This in an Interview

Here is how I would actually say this in 90 seconds:

"When you type a URL and press Enter, seven things happen in sequence.

First, DNS resolution. The browser needs to turn the hostname into an IP address. It checks its local cache, then the OS cache, then asks a recursive resolver. The resolver walks the DNS hierarchy from root servers to TLD servers to the authoritative nameserver. In practice, this is usually a cache hit and takes under 1ms, but a cold lookup can take 50-200ms.

Second, TCP handshake. The browser opens a TCP connection to the server's IP on port 443. This costs one round trip: SYN, SYN-ACK, ACK.

Third, TLS handshake. On top of TCP, the browser negotiates encryption. TLS 1.3 does this in a single round trip. The client sends its key share and supported ciphers, the server responds with its key share and certificate.

Fourth, the HTTP request. The browser sends an HTTP/2 GET request for the path, along with headers like cookies and accept-encoding.

Fifth, server processing. The request hits a load balancer, gets routed to an app server, which may hit a cache or database to generate the response.

Sixth, the response comes back over the encrypted connection. For a typical web page, this is 50-500KB of gzipped HTML.

Seventh, browser rendering. The browser parses the HTML into a DOM tree, parses CSS into a CSSOM tree, merges them into a render tree, calculates layout, and paints pixels to the screen. CSS is render-blocking, JavaScript is parser-blocking, and the compositor uses the GPU for the final frame.

The total time from keypress to first paint is typically 500ms to 2 seconds, with DNS, TCP, and TLS accounting for the first 100-400ms and server processing and rendering accounting for the rest."

Interview Cheat Sheet

• Trigger: "What happens when..." → Structure your answer in 7 phases: DNS, TCP, TLS, HTTP request, server processing, response, browser rendering.
• DNS depth: "DNS resolves through root → TLD → authoritative, but most lookups are cache hits at the recursive resolver."
• TCP cost: "TCP three-way handshake costs 1 RTT, typically 20-100ms depending on geographic distance."
• TLS version: "TLS 1.3 needs only 1 RTT, down from 2 in TLS 1.2. 0-RTT resumption exists but is vulnerable to replay attacks."
• HTTP/2 key insight: "HTTP/2 multiplexes multiple streams over a single TCP connection, eliminating head-of-line blocking at the HTTP layer."
• Server-side processing: "Request hits load balancer → app server → cache or database. Mention each layer to show production awareness."
• Rendering pipeline: "DOM + CSSOM → render tree → layout → paint → composite. CSS blocks rendering, JS blocks parsing."
• Performance signal: "Mention latency numbers at each phase. DNS is 0-200ms, TCP is 1 RTT, TLS is 1 RTT. This shows you think quantitatively."
• CDN shortcut: "For cacheable resources, the CDN edge responds directly. The server processing step becomes a cache hit 20ms away."
• Depth control: "Offer to go deeper: 'I can dive into TLS certificate verification or the rendering pipeline, whichever interests you more.'"

Test Your Understanding

---

---

---

---

---

---

---

Quick Recap

1. DNS resolution turns a hostname into an IP address through a hierarchy of root, TLD, and authoritative nameservers, with caching at every layer.
2. The TCP three-way handshake (SYN, SYN-ACK, ACK) costs one round trip and establishes a reliable byte-stream connection.
3. TLS 1.3 negotiates encryption in a single round trip by sending the key share in the ClientHello, compared to two round trips in TLS 1.2.
4. The HTTP/2 request is multiplexed over a single TCP connection, eliminating application-level head-of-line blocking.
5. Server-side processing involves a load balancer, app server, and typically a cache or database query before generating the response.
6. The browser rendering pipeline (DOM, CSSOM, render tree, layout, paint, composite) turns HTML bytes into pixels, with CSS blocking rendering and synchronous JS blocking parsing.
7. The total latency from keypress to first paint is 500ms to 3 seconds, with network round trips dominating on the first visit and the rendering pipeline dominating on cached visits.
8. CDNs dramatically reduce latency by serving cached content from edge nodes 20-50ms from the user, bypassing the origin server entirely.

Related Concepts

• How CDN cache invalidation works: The CDN layer that short-circuits most of the server-side processing in this flow. Understanding cache TTLs and purge strategies directly affects time-to-first-byte.
• How CORS works: Once the browser renders the page and JavaScript starts making cross-origin API calls, CORS preflight requests add additional round trips that follow the same DNS, TCP, TLS chain.
• How TLS certificates work: Deep dive into the certificate verification step of the TLS handshake, including certificate chains, root CAs, and certificate transparency logs.
• How HTTP/2 and HTTP/3 work: The protocol optimizations (multiplexing, header compression, QUIC) that reduce the number of round trips discussed in this article.