FUNDAMENTALS · MECHANISM WALKTHROUGH

URL to Page Load
What Really Happens, Step by Step

from hitting Enter to pixels on screen — DNS, TCP, TLS, HTTP, and render, in the order they actually occur.

PARSE URL→ CACHE CHECK→ DNS RESOLVE→ TCP HANDSHAKE→ TLS HANDSHAKE→ HTTP REQUEST→ SERVER PROCESSES→ HTTP RESPONSE→ PARSE + RENDER

01 The Full Sequence — Worked Example (https://example.com)

URL Parsing

The browser breaks the URL into its parts: scheme (https), host (example.com), path (/), and implied port (443 for https, 80 for http). This decides everything that follows — especially whether TLS is required.

Parse

Cache Checks Before Any Network Call

Browser cache, OS-level DNS resolver cache, and the local hosts file are all checked first. A DNS lookup costs a round trip, so nothing gets resolved over the network if a valid, unexpired answer already exists locally.

Cache

DNS Resolution

If nothing's cached, the OS resolver queries its configured DNS server over UDP/53. That server checks its own cache, and if empty, resolves recursively: root servers → .com TLD servers → example.com's authoritative nameserver, returning the A record: 93.184.216.34. Everything downstream now has a destination IP.

Checkpoint

TCP Three-Way Handshake

The browser opens a transport connection to 93.184.216.34:443: SYN → SYN-ACK → ACK. This establishes a reliable, ordered byte stream — with zero encryption and no awareness of HTTP yet.

TCP

TLS Handshake

ClientHello (supported cipher suites + SNI hostname, sent in cleartext) → ServerHello plus the server's certificate → the browser validates the certificate (chain of trust, expiry, hostname match) → key exchange derives shared session keys on both sides → Finished messages confirm it. From this point every byte on the connection is encrypted. (TLS 1.3 does this in one round trip; TLS 1.2 needed two.)

TLS

HTTP Request Sent

Now — and only now — the browser sends the actual request over the encrypted channel: GET / HTTP/1.1 (or an HTTP/2 frame), with headers like Host, User-Agent, Accept, and any cookies for that domain.

HTTP Request

Server-Side Processing

The request hits the web server (often behind a load balancer/reverse proxy first), gets routed to the application, which builds the response — a static file, a rendered template, or the result of a database query.

Server

HTTP Response Returned

Status line (200 OK), headers (Content-Type, Cache-Control, Set-Cookie), then the HTML body — streamed back over the same TLS-encrypted TCP connection.

HTTP Response

Browser Parses HTML

The browser starts building the DOM as bytes arrive — it doesn't wait for the whole response. As it parses, it discovers references to CSS, JS, images, and fonts.

Parse

Additional Resource Fetches

Each referenced resource is fetched — reused connections/multiplexing (HTTP/2) if it's the same domain, or a brand new DNS → TCP → TLS sequence if it's a different domain (e.g. a CDN or analytics script), all in parallel where possible.

Resources

Render Tree, Layout, Paint

DOM + CSSOM combine into a render tree, the browser computes layout (geometry/position of every element), then paints pixels to the screen. Parser-blocking <script> tags can pause this entirely until they finish executing.

Render

Page Becomes Interactive

DOMContentLoaded fires once HTML is fully parsed and the DOM exists — without waiting for images. load fires only once every resource has finished. The gap between the two is often where perceived speed and "actually done" diverge.

Interactive

02 How to Explain This in an Interview

Keep DNS, TCP, and TLS as three distinct, sequential handshakes. Conflating them (saying "it connects" as one step) is the fastest way to sound like you're summarizing rather than explaining.
Say why TLS validates the certificate, not just that it encrypts. Encryption alone doesn't stop you connecting to an impostor — the certificate chain is what proves you're actually talking to example.com.
Mention SNI if asked how one server can host multiple HTTPS sites on one IP. It's a small detail that signals real depth.
Call out that a different domain (CDN, analytics, fonts) means a fresh DNS/TCP/TLS sequence. This is the detail that connects the mechanism to real-world page-speed advice.
Close on DOMContentLoaded vs load. It's a clean, concrete way to end the walkthrough and shows you know the browser side, not just the network side.

03 Follow-Up / Gotcha Questions

Q What's the difference between the TCP handshake and the TLS handshake, and why are they separate?

A TCP establishes a reliable, ordered connection first (SYN/SYN-ACK/ACK) with zero encryption. TLS then runs on top of that already-established connection to negotiate encryption and authenticate the server — they're layered, which is why a connection can succeed at TCP but still fail at TLS.

Q What happens if the TLS certificate is expired or the hostname doesn't match?

A The browser hard-stops the handshake and shows a security warning instead of completing the connection — validation is deliberately a blocking step, because silently continuing would defeat the point of TLS entirely.

Q Why does the browser check multiple caches before doing a real DNS lookup?

A DNS resolution costs a network round trip. Browser cache, OS resolver cache, and the hosts file are checked first because most repeat visits are to names that haven't changed since the last lookup.

Q What is SNI and why does it matter?

A Server Name Indication — the hostname sent in cleartext during the ClientHello, so a server hosting multiple TLS certificates on one IP (common with cloud hosting/CDNs) knows which certificate to present before encryption is even established.

Q If a page loads images from a CDN on a different domain, does that need its own DNS/TCP/TLS?

A Yes — a different domain means a fresh DNS resolution, a new TCP connection, and a new TLS handshake, running in parallel with the main page's connection. It's exactly why fewer distinct third-party domains generally means a faster page.

Q What's the actual difference between DOMContentLoaded and load?

A DOMContentLoaded fires once the HTML is fully parsed and the DOM is built, without waiting for images or stylesheets still in flight. load fires only once every resource on the page has finished loading.

04 Quick-Fire Glossary

Term	Meaning
Recursive vs Authoritative DNS	A recursive resolver does the multi-hop lookup on your behalf; the authoritative server is the final source of truth for that domain
A / AAAA Record	DNS record mapping a hostname to an IPv4 (A) or IPv6 (AAAA) address
TCP 3-Way Handshake	SYN, SYN-ACK, ACK — establishes a reliable connection before any data is sent
SNI	Server Name Indication — hostname sent unencrypted in the TLS ClientHello so the right certificate can be selected
Certificate Chain of Trust	The link from a site's certificate up through intermediate CAs to a root CA the browser already trusts
HTTP/1.1 vs HTTP/2	HTTP/2 multiplexes many requests over a single TCP connection instead of opening one connection per resource
DOM	Document Object Model — the browser's in-memory tree representation of the parsed HTML
Render Tree	DOM combined with computed CSS, used to calculate layout and paint the page
DOMContentLoaded vs load	HTML parsed vs every resource (images, CSS, JS) fully loaded