From Enter Key to Pixels: What Happens When You Type a URL
DNS caches, TCP, TLS, HTTP, then HTML parsing, the render tree, layout and paint. Every stage is a place a page can be slow, and a place to fix it.
On this page
This is the classic interview question, and the reason it never dies is that it is the best map of web performance there is. Every millisecond a user waits belongs to one of about eight stages. Know the stages and “the site is slow” becomes a diagnosis instead of a complaint.
Stage 1 to 3: find the server and connect
- DNS lookup
The browser needs an IP address for the hostname. It checks its own cache, then the OS cache, then a local resolver or router, then the ISP resolver. If nothing has it, the resolver walks the hierarchy: root servers point to the top-level domain servers, which point to the domain’s authoritative servers, which return the answer. Each answer carries a TTL that says how long it may be cached.
- TCP connection
With an IP, the browser opens a TCP connection using the three-way handshake (SYN, SYN-ACK, ACK). That costs one round trip before any data moves.
- TLS handshake
For HTTPS, client and server then negotiate encryption: the server proves its identity with a certificate, both sides agree on keys, and the rest of the conversation is encrypted. Modern TLS adds roughly one more round trip.
Stage 4: request and response
The browser sends an HTTP request. The server processes it (this is where your backend, database and cache time lives) and returns a response, usually a 200 with HTML. The time until the first byte of that response arrives is the time to first byte, a combination of everything so far plus your server’s work.
Stage 5 to 8: turn bytes into pixels
A synchronous script can block HTML parsing, because it may modify the document. Scripts also wait for pending stylesheets. Use defer or async for non-critical scripts so parsing and rendering are not held hostage.
A stage-by-stage speed map
| Stage | Typical symptom | Common fix |
|---|---|---|
| DNS | Slow first visit only | Longer TTLs, DNS prefetch, a faster resolver |
| TCP + TLS | High latency to origin | CDN close to users, connection reuse, TLS 1.3, preconnect |
| Server time | Large time to first byte | Caching, query tuning, edge rendering |
| Download | Big HTML, CSS, JS | Compression, smaller bundles, HTTP/2 or HTTP/3 |
| CSSOM | Blank screen until styles load | Inline critical CSS, trim unused CSS |
| Scripts | Late interactivity | defer, code splitting, remove third-party bloat |
| Layout/paint | Jank on scroll or resize | Avoid layout thrash, animate transform and opacity |
Do
Measure which stage is slow before optimizing: look at the network waterfall and the performance panel, and fix the biggest block first.
Don't
Minify JavaScript while your time to first byte is two seconds. The page is waiting on your server, not your bundle.
Takeaway
A page load is a relay: name lookup, connection, encryption, request, response, parse, style, layout, paint. Each leg hands off to the next, and the user feels the sum. Learn to see which leg is slow and you know where to look.
Frequently asked questions
Why is the first request to a site slower than the next?
The first visit pays for DNS resolution, a TCP connection, and a TLS handshake before any HTTP byte moves. Later requests reuse cached DNS answers and often an open connection, so they skip most of that setup. That is why connection reuse and preconnect hints help real-world load times.
What is the difference between the DOM and the render tree?
The DOM is the tree of all elements parsed from HTML. The render tree combines the DOM with computed styles from the CSSOM and includes only what is actually displayed. Elements with display none are in the DOM but not in the render tree.
Why do render-blocking CSS and JavaScript slow the page?
The browser cannot paint until it has both the DOM and CSSOM, so stylesheets block rendering. A synchronous script can block HTML parsing itself, because it might change the document. Deferring scripts and inlining critical CSS shortens the time to first paint.
Where does DNS caching happen?
At several layers: the browser, the operating system, a local resolver or router, and the ISP's recursive resolver. Only if every layer misses does a recursive lookup go out through root, top-level domain and authoritative servers. Each answer carries a time-to-live that says how long it may be cached.
/* Comments */
Comments are offline right now — we reconnect automatically, nothing is lost.