Walk through everything from the keystroke to pixels on screen. This is the classic 'do you understand the whole stack' question.
Whether you can narrate the full pipeline: DNS → TCP/TLS → HTTP → parse → render.
(1) URL parsing — the browser splits scheme, host, path; if it's not a valid URL it hands the text to the default search engine. (2) DNS resolution — the hostname is resolved to an IP, checking browser cache → OS cache → router → recursive resolver. (3) TCP handshake — a connection opens (SYN/SYN-ACK/ACK); HTTPS adds a TLS handshake to negotiate keys and verify the certificate. (4) HTTP request — the browser sends GET with headers (cookies, Accept, User-Agent); the server responds with status, headers, and the HTML body. (5) Parsing & render — the HTML is parsed into the DOM; CSS into the CSSOM; the two combine into the render tree; then layout computes geometry and paint fills pixels, composited into layers on screen. Along the way the preload scanner fetches subresources (CSS, JS, images) in parallel; render-blocking CSS and synchronous JS pause parsing. Modern answers also mention HTTP caching, connection reuse (keep-alive/HTTP/2 multiplexing), and that a service worker may intercept the request entirely. The interviewer is probing breadth — hit each stage and mention one detail per stage.
System-level interview warm-up; also the mental map for diagnosing where a slow page loses time.
URL parse → DNS lookup → TCP + TLS handshake → HTTP request/response
→ parse HTML (DOM) + CSS (CSSOM) → render tree → layout → paint → composite
(preload scanner fetches CSS/JS/images in parallel; a Service Worker may intercept)