You type a web address into your browser, hit enter, and a fraction of a second later a page appears. It feels instant and it feels simple. It is neither — a genuinely remarkable sequence of handoffs happens in that fraction of a second, involving multiple systems around the world working in a precise order.
Here’s what actually happens, in plain English, from the moment you hit enter to the moment the page renders.
Step 1: The Browser Checks Its Own Memory First
Before doing anything over the network, your browser checks whether it already knows how to find the site you’re requesting. Browsers keep a local cache of recent DNS lookups (more on DNS in a moment) and, sometimes, cached copies of the page itself from a previous visit. If everything needed is already sitting in local cache and hasn’t expired, the browser can skip straight to rendering — which is why revisiting a site you were just on often feels instant.
Assuming this is a fresh request, the real journey begins.
Step 2: DNS Lookup — Translating the Name Into an Address
Computers don’t navigate the internet by domain name. They navigate by IP address — a numerical identifier like 104.21.44.58. The domain name you typed is a human-friendly label that has to be translated into that number before anything else can happen. This translation is handled by DNS — the Domain Name System.
Your browser asks a DNS resolver (usually provided by your internet service provider, or a public one like Google’s or Cloudflare’s if you’ve configured it) to look up the domain. That resolver checks its own cache first, and if it doesn’t have a fresh answer, it queries a chain of authoritative servers — starting at the root, then the domain’s specific nameservers — until it gets the actual IP address for the server that hosts the site.
This entire process typically takes somewhere between a few milliseconds and a couple hundred milliseconds, depending on caching and network conditions.
Step 3: Establishing a Connection — the TCP Handshake
Now that your browser has an IP address, it needs to establish a reliable connection to the server at that address. This happens over TCP (Transmission Control Protocol), and it starts with what’s called a three-way handshake:
- Your browser sends a SYN (synchronize) packet to the server, essentially saying “I’d like to start a connection.”
- The server responds with a SYN-ACK, acknowledging the request and proposing its own connection parameters.
- Your browser sends an ACK back, confirming. The connection is now established.
This handshake happens before a single byte of the actual webpage is transferred — it’s purely about setting up a reliable communication channel first.
From keystroke to rendered page — the full sequence
Step 4: TLS Negotiation — Setting Up Encryption
If the site uses HTTPS — which nearly all modern sites do, and which we covered in detail in our SSL post — the next step is the TLS handshake. This is where your browser and the server agree on an encryption method and exchange the cryptographic information needed to scramble everything that follows.
The server presents its SSL certificate during this exchange, which your browser verifies against trusted Certificate Authorities. If everything checks out, an encrypted channel is established, and every subsequent piece of data traveling between your browser and the server is unreadable to anyone intercepting it along the way.
Step 5: The HTTP Request — Actually Asking for the Page
With a secure connection established, your browser finally sends the actual request: an HTTP GET request asking specifically for the page at that URL. This request includes headers with information like what browser you’re using, what content types you can accept, and any cookies associated with the site.
The server receives this request and gets to work generating a response. For a static HTML file, this is nearly instant. For a dynamic site like WordPress, the server has to execute PHP code, query the database, assemble the page from templates and content, and generate the final HTML — which is exactly the process that caching plugins bypass for repeat visitors.
Step 6: The Response Travels Back and the Browser Renders
The server sends back an HTTP response — a status code (200 for success, and a range of others for various conditions), headers, and the actual content: HTML, followed by references to additional resources like CSS, JavaScript, images, and fonts that the browser then requests separately.
As these pieces arrive, your browser’s rendering engine gets to work: parsing the HTML into a structure, applying CSS to determine layout and appearance, executing JavaScript, and painting pixels to your screen. Modern browsers do much of this incrementally, showing content as it becomes available rather than waiting for everything to finish — which is why you often see a page’s text appear before its images finish loading.
Why This Matters Beyond Curiosity
Every step in this sequence is a place where time gets spent, and understanding it helps explain why certain things affect your site’s speed:
- DNS matters. A slow or distant DNS resolver adds delay before anything else can even start.
- TCP and TLS overhead is why HTTP/2 matters — it reduces the number of separate connections needed, which is part of why we run it on every account, as covered in our server optimization post.
- Server response time (TTFB) is entirely about Step 5 — how fast the server can generate and start sending the response. This is squarely in the host’s control and is exactly what caching, database tuning, and PHP configuration all target.
- Everything after TTFB — the rendering and additional resource loading — is mostly about what’s actually on the page, which is why image optimization and plugin bloat matter so much for the total experience even when server response time is fast.
The whole sequence — DNS, TCP, TLS, HTTP request, response, render — typically completes in a fraction of a second. It’s easy to take that for granted. It’s a genuinely intricate system working exactly as designed, every single time you load a page.