This isn't about DNS record types — we've covered A records, MX records and the rest separately in DNS records explained, and the caching mechanics behind "why hasn't my change shown up yet" get their own dedicated treatment in DNS TTL and propagation explained. This article assumes you're not currently mid-migration and just want to understand the whole trip — the four layers a browser works through, in order, every single time it loads a page, well before either of those specific topics becomes relevant.
The four layers, in order
Every one of these steps depends on the one before it finishing successfully. There's no skipping ahead — a browser can't negotiate encryption before it has a connection, and it can't open a connection before it knows where to send the packets.
DNS lookup — turning a name into an address
The browser needs an IP address before it can connect to anything, and a domain name isn't one. It asks a DNS resolver (usually your ISP's, or a public one like 1.1.1.1 or 8.8.8.8 if you've configured one) to translate the domain into an IP address. If the answer is already cached somewhere in the chain, this step can be near-instant; if not, the resolver has to ask around until it finds the authoritative answer. Either way, the browser now has a number to connect to instead of a name.
TCP handshake — opening a reliable connection
With an IP address in hand, the browser opens a connection to the server using TCP (Transmission Control Protocol), which guarantees data arrives complete and in order. This starts with the well-known three-way handshake: the client sends a SYN packet, the server replies with SYN-ACK, and the client sends back ACK. Only once all three have been exchanged does a connection actually exist. No page data has moved yet — this step is purely about establishing that both ends are ready and reachable.
TLS handshake — negotiating encryption
For an HTTPS site (which is effectively all of them now), the next step happens on top of the TCP connection, before any HTTP request is sent: a TLS handshake. The client sends a ClientHello listing the encryption methods it supports; the server replies with a ServerHello, its certificate, and its choice of method. The client verifies the certificate is valid and actually belongs to the domain it's trying to reach, then both sides derive session keys used to encrypt everything from this point on. Modern TLS (1.3) does this in a single round trip; older versions needed two. Either way, by the end of this step the connection is private and the server's identity has been cryptographically verified — not just claimed.
HTTP request and response — actually asking for the page
Only now does the browser send anything resembling "give me the page." It issues an HTTP request — method, path, headers, maybe a body — over the now-encrypted connection. The server processes it and sends back a response: a status code, response headers, and the actual content, whether that's HTML, an image, JSON from an API, or anything else. The browser starts rendering as data arrives, and for a typical page, this whole sequence repeats dozens of times for every additional resource — stylesheets, scripts, images, fonts — each one a request and response of its own.
The short version: find the address (DNS), open a connection (TCP), make it private and verified (TLS), then actually ask for something (HTTP). Four distinct jobs, done by four different mechanisms, stacked on top of each other in a fixed order.
Why the first request feels slower than the rest
This is the part that explains a genuinely common piece of everyday experience: the very first request to a site you haven't visited before often feels a beat slower than everything that follows. That's not your imagination or a slow server — it's the full cost of all four steps landing on a single request, with nothing to reuse.
- DNS gets cached after the first lookup, so subsequent requests to the same domain often skip straight past it.
- The TCP connection often stays open (HTTP "keep-alive") and gets reused for multiple requests to the same server, avoiding a fresh three-way handshake for every single resource.
- TLS sessions can be resumed using previously negotiated parameters, skipping the full handshake on a reconnect.
None of this is magic — it's deliberate reuse, and it's why a page's second and third resource load noticeably faster than the first, even from the same server over the same connection quality.
Worth knowing if you're diagnosing "the site feels slow": a genuinely slow DNS lookup, a distant server adding latency to the TCP and TLS round trips, and a slow application generating the actual HTTP response are three completely different problems with three completely different fixes. Browser developer tools (the Network tab) will show you the time spent in each phase separately, which is usually the fastest way to work out which layer is actually the bottleneck before assuming it's "just slow hosting."
Where things commonly go wrong at each layer
| Layer | Typical failure | What it looks like |
|---|---|---|
| DNS | Record missing, wrong, or pointing at an old server | "This site can't be reached" before a connection is even attempted |
| TCP | Firewall blocking the port, server not listening, network path down | Connection timeout — the browser waits, then gives up |
| TLS | Expired or mismatched certificate, unsupported protocol version | A prominent browser security warning, connection refused before any content loads |
| HTTP | Application error, missing resource, slow backend processing | A 4xx/5xx status code, or a connection that succeeds but the page is slow or broken |
Knowing which layer you're actually looking at is most of the battle when something's not working. A certificate warning is a TLS-layer problem and has nothing to do with your application code. A page that loads but shows an error is an HTTP-layer problem and has nothing to do with DNS. Matching the symptom to the right layer saves a lot of time spent investigating the wrong thing.
Chasing down a connection issue and not sure which layer it's actually failing at? Get in touch — send through what you're seeing and we'll help narrow it down.
Get in touch →Frequently asked questions
What happens between typing a web address and the page loading?
Four things happen in order: DNS lookup for the IP address, a TCP three-way handshake to open a connection, a TLS handshake to negotiate encryption, then an HTTP request and response carrying the actual page content. Each step depends on the one before it.
What is the TCP three-way handshake?
The process of establishing a reliable connection before data is sent: SYN from the client, SYN-ACK from the server, ACK back from the client. Only once all three have been exchanged does the connection exist.
What does the TLS handshake actually negotiate?
Which encryption method both sides will use, verification of the server's identity via its certificate, and the session keys used to encrypt everything that follows — all on top of the already-open TCP connection, before any HTTP request is sent.
Why does the first request to a new website feel slower than later ones?
The first request pays for DNS lookup, TCP handshake, and TLS handshake in full. Later requests to the same site can reuse the cached DNS answer, the open connection, and the negotiated encryption session, skipping straight to the HTTP request.