What Happens When You Type a URL
AdvancedThe classic interview question: typing "https://google.com" triggers a precise sequence spanning DNS resolution, TCP connection, TLS handshake, HTTP request, server processing, and browser rendering — touching nearly every layer of the network stack.
Overview
This question is a favourite in system design and backend interviews because it tests breadth across DNS, TCP/IP, TLS, HTTP, CDN, server-side rendering, and browser parsing. A strong answer covers all layers, mentions optimisations at each step (DNS caching, TLS session resumption, HTTP/2 multiplexing, CDN edge hits), and shows awareness of failure scenarios. The depth you go determines whether you land a junior, mid, or senior role.
Step 1: URL Parsing & HSTS Check
The browser first parses the URL into scheme, host, path, and query. It checks the HSTS (HTTP Strict Transport Security) preload list — if the domain is on the list, the browser upgrades to HTTPS even if "http://" was typed, before any network request is made.
// URL parsed into components:
// https://www.google.com/search?q=aicancode
// └──┬──┘ └──────┬──────┘└──┬──┘└────┬────┘
// scheme host path query
// HSTS Preload List check (browser-internal):
// Is "google.com" in chrome://net-internals/#hsts ?
// YES → force HTTPS regardless of typed scheme
// This check happens BEFORE any DNS or TCP — pure in-browser
// Default port resolution:
// https → 443, http → 80, ftp → 21
// Explicit override: https://example.com:8443/pathStep 2: DNS Resolution
The browser needs to convert "www.google.com" to an IP address. It checks its own cache, then the OS cache, then the local resolver (usually your router or ISP). If not cached anywhere, the resolver performs a full recursive lookup: Root → .com TLD → google.com authoritative nameserver.
// DNS resolution chain (cache miss at every level):
// Browser DNS cache (chrome://net-internals/#dns)
// ↓ miss
// OS DNS cache (/etc/hosts, systemd-resolved, nscd)
// ↓ miss
// Recursive Resolver (8.8.8.8 or ISP resolver)
// ↓ miss → begins iterative resolution
// → Root NS: "I don't know google.com, ask .com TLD at 192.5.6.30"
// → .com TLD NS: "I don't know, ask google.com NS at 216.239.32.10"
// → google.com authoritative NS: "www.google.com → 142.250.80.36"
// Resolver caches result per TTL, returns to OS, OS returns to browser
// Result: IP address 142.250.80.36, TTL=300s
// Browser caches for min(TTL, browser-max-TTL)Step 3: TCP Connection & TLS Handshake
With the IP resolved, the browser opens a TCP connection (3-way handshake: SYN → SYN-ACK → ACK). For HTTPS, a TLS 1.3 handshake follows in 1 round-trip. The browser validates the server's certificate chain. Total cost: ~2 RTTs (1 TCP + 1 TLS).
// TCP 3-way handshake:
// Client → Server: SYN (seq=100)
// Server → Client: SYN-ACK (seq=200, ack=101)
// Client → Server: ACK (seq=101, ack=201)
// Connection established — 1 RTT
// TLS 1.3 handshake (1 RTT):
// Client → Server: ClientHello (key_share, supported_ciphers, TLS versions)
// Server → Client: ServerHello + {Certificate} + {CertificateVerify} + {Finished}
// Client → Server: {Finished}
// Application data begins — total: 2 RTTs from scratch
// Optimisations that skip steps:
// Connection reuse (Keep-Alive): skip TCP + TLS for same origin
// HTTP/2 multiplexing: one TCP conn for all resources on same origin
// TLS 1.3 session resumption (PSK): 0-RTT for returning clients
// DNS pre-resolve / TCP pre-connect (<link rel="preconnect">)Step 4: HTTP Request & Server Processing
The browser sends an HTTP GET request. For Google, the request likely hits a CDN edge first. On a cache miss the edge fetches from origin. The server (or CDN) returns an HTTP response with the HTML body, status code, and cache/security headers.
// HTTP/2 GET request (binary framing, compressed headers via HPACK):
GET /search?q=aicancode HTTP/2
Host: www.google.com
Accept: text/html,application/xhtml+xml
Accept-Encoding: gzip, deflate, br
Cookie: CONSENT=YES+...; NID=...
User-Agent: Mozilla/5.0 ...
// Server processing (simplified Google search):
// 1. Load balancer (Maglev) routes to nearest data centre
// 2. Frontend server handles HTTP, checks CDN cache
// 3. Cache miss → query index servers (distributed inverted index)
// 4. Rank results (PageRank + ML signals)
// 5. Assemble HTML response
// 6. Return 200 OK + gzipped HTML
// Response headers:
HTTP/2 200 OK
Content-Type: text/html; charset=UTF-8
Content-Encoding: gzip
Cache-Control: private, max-age=0
Strict-Transport-Security: max-age=31536000
X-Frame-Options: SAMEORIGINStep 5: Browser Rendering
The browser receives the HTML and begins parsing — building the DOM. When it encounters CSS, it fetches and builds the CSSOM. JavaScript blocks parsing unless async/defer. The browser merges DOM + CSSOM into a Render Tree, calculates layout, paints pixels, and composites layers onto screen.
// Critical Rendering Path:
// HTML bytes → Tokenise → DOM
// CSS bytes → Tokenise → CSSOM
// DOM + CSSOM → Render Tree (only visible nodes)
// → Layout (calculate geometry: x, y, width, height)
// → Paint (fill pixels: text, colours, images)
// → Composite (GPU layers, transform/opacity)
// Render-blocking resources:
// <link rel="stylesheet"> — blocks rendering until CSSOM complete
// <script> (no async/defer) — blocks DOM parsing + rendering
// Performance metrics measured here:
// FCP (First Contentful Paint): first DOM content painted
// LCP (Largest Contentful Paint): largest image or text block visible
// TTI (Time to Interactive): JS parsed and main thread idle
// Sub-resource requests (parallel, HTTP/2 multiplexed):
// main.css, app.js, hero.jpg, fonts.woff2, analytics.js
// HTTP/2: all over single TCP connection
// Browser sends prefetch/preload hints: <link rel="preload" as="script">Key Points to Remember
- 1The full sequence: HSTS check → DNS resolve → TCP handshake → TLS handshake → HTTP request → server process → browser render.
- 2DNS adds latency only on cache miss; TTL controls how long results are cached at each level.
- 3TCP + TLS 1.3 cost 2 RTTs total for a new connection; HTTP Keep-Alive and multiplexing (HTTP/2) amortise this across requests.
- 4CDN cache hit skips origin entirely — serves from edge in ~5ms vs 100ms+ to distant origin.
- 5Browser rendering is blocked by CSS (CSSOM) and synchronous JS — async/defer and preload hints are critical for performance.
Interview Questions
Sign in to ask AriaWalk me through exactly what happens when you type https://google.com and press Enter.
At which step does a CDN intercept the request and what is the benefit?
How many round-trips does it take to load the first byte of an HTTPS page on a new connection?
What is the Critical Rendering Path and which resources block it?
What optimisations reduce the time from typing the URL to first paint?
Ask Aria about What Happens When You Type a URL
Your personal AI tutor — ask anything about this concept
Revision Status
Personal Notes
Sign in to save personal notes for this topic.
Discussion
Sign in to join the discussion.