What Happens When You Open a Web Page
Follow one request from typing a URL to seeing the page: DNS lookup, TCP and TLS handshakes, the load balancer, the app server, the database and back. Every later topic zooms into one of these steps.
In a nutshell
- A page load is a chain: DNS → TCP → TLS → HTTP request → load balancer → app → data → response.
- Several steps are network round trips; with distant servers, round trips dominate the time.
- Caching at each step (DNS cache, CDN, app cache) skips work on later requests.
- Knowing the chain lets you say exactly where a slow or failing request is stuck.
The whole journey
You type shop.example.com and press Enter. Within a few hundred milliseconds a page appears. Here is everything that happens in between, step by step.
From URL to page
All steps Press Play to follow one request. Steps 1 to 3 happen before the server sees anything.
- The browser needs an IP address for the name, so it asks a DNS resolver (unless the answer is already cached).
- The resolver returns the IP address of the site's entry point, here a load balancer.
- The browser opens a TCP connection and negotiates TLS encryption. Each handshake costs network round trips.
- Over the encrypted connection, the browser sends the HTTP request: GET /.
- The load balancer picks a healthy app server and forwards the request.
- The app server runs your code, which needs data, so it queries the database (or a cache first).
- The database returns rows.
- The app renders HTML and sends the response back through the load balancer to the browser.
Diagram as text
- The browser needs an IP address for the name, so it asks a DNS resolver (unless the answer is already cached).
- The resolver returns the IP address of the site's entry point, here a load balancer.
- The browser opens a TCP connection and negotiates TLS encryption. Each handshake costs network round trips.
- Over the encrypted connection, the browser sends the HTTP request: GET /.
- The load balancer picks a healthy app server and forwards the request.
- The app server runs your code, which needs data, so it queries the database (or a cache first).
- The database returns rows.
- The app renders HTML and sends the response back through the load balancer to the browser.
After the HTML arrives, the browser parses it and finds more resources: CSS, JavaScript, images, fonts. Each needs its own request, usually served from a CDN close to the user, and the page is drawn as they arrive.
Where the time goes
For a user far from the server, round trips dominate. With a 100 ms round-trip time (say, Mumbai to Frankfurt):
| Step | Round trips | Approx. time |
|---|---|---|
| DNS lookup (not cached) | 1 or more | 0–100+ ms |
| TCP handshake | 1 | 100 ms |
| TLS 1.3 handshake | 1 | 100 ms |
| HTTP request and response | 1 | 100 ms + server time |
| Server work (app + database) | inside the data centre | 20–200 ms |
That is roughly 400 ms before the first byte of HTML, and the server's own work is only part of it. This is why we reuse connections, cache DNS answers, use CDNs near users and newer protocols such as HTTP/3 that need fewer round trips.
Caches along the way
Every layer can answer early
Diagram as text
- Browser cache → CDN: miss
- CDN → Load balancer: miss
- Load balancer → App cache
- App cache → Database: miss
The browser caches files using HTTP cache headers; the CDN caches static files (and sometimes whole pages) near the user; the app caches query results in memory. The Caching module covers how to decide what to cache and for how long.
Debugging with the chain
When "the site is slow" or "the site is down", walk the chain and find the first step that misbehaves:
- Name does not resolve? DNS (a wrong record, an expired domain, a TTL still holding an old address).
- Connection refused or timing out? Network or load balancer (firewall rules, no healthy servers behind it).
- Certificate errors? TLS (expired certificate, wrong hostname).
- 502 or 504 from the load balancer? The app servers are down or too slow.
- Fast for simple pages, slow for some? Usually the database or an external API on those pages.
Common mistakes
- Optimising server code when most of the time is spent in round trips to a distant server.
- Opening a new connection for every request instead of reusing (keep-alive) connections.
- Forgetting that the HTML is only the first of dozens of requests a page makes.
Interview questions
Try answering out loud before you open each one.
What happens when you type a URL into a browser and press Enter?
The browser resolves the hostname to an IP with DNS (checking caches first), opens a TCP connection, negotiates TLS for HTTPS, and sends the HTTP request. A load balancer forwards it to an app server, which may read from caches and databases and returns a response. The browser parses the HTML, fetches CSS, JavaScript and images (often from a CDN), and renders the page. Mention caching at each layer and that round trips dominate for distant users.
A user on another continent says the site is slow but your server metrics look fine. What do you check?
The network part of the chain: round-trip time, number of round trips (DNS, TCP, TLS, redirects, many separate requests), and whether static files come from a CDN near them. Server metrics only cover time inside the data centre.
Check yourself
Related topics
Further reading
- What happens when… (a very detailed walk-through) Open source on GitHub
- How browsers work: Populating the page MDN Web Docs
Your notes
Saved in this browser as you type.
Finished this topic?
Mark it read to track your progress, then carry on with the next one.