What Happens When You Load a Web Page

October 6, 2026•6 min read•

Web Development Networking Browsers HTTP

You type an address, press enter, and a page appears. It feels instant, and most of the time it finishes in well under a second. In that gap your computer runs a sequence of carefully designed steps that involve name lookups, a handshake or two, some cryptography, and a conversation with a server that might be thousands of miles away. Understanding that sequence is one of the most useful things a web developer can do, because almost every performance problem and every strange bug lives somewhere inside it.

Step one: the browser reads the URL

Before anything travels across the network, the browser parses what you typed. A URL has parts, and each one tells the browser something different.

https://www.example.com:443/articles?page=2#top

The scheme (https) says which protocol to use. The host (www.example.com) names the server. The port (443, implied for HTTPS) says which door to knock on. The path (/articles) names the resource, the query string (?page=2) passes parameters, and the fragment (#top) is handled entirely in the browser and never sent to the server^[1]. The browser also checks a few local things first, including its cache and a preloaded list of sites that must always use HTTPS.

Step two: turning a name into an address

Computers do not route traffic using names like example.com. They use IP addresses. The system that translates between the two is DNS, the Domain Name System^[2], and it works like a chain of questions.

Your browser first checks its own cache, then asks your operating system, which asks a recursive resolver, usually run by your internet provider or a service like Cloudflare or Google. If the resolver does not already know the answer, it walks the hierarchy. It asks a root server which machines handle .com, asks one of those which machines are authoritative for example.com, and asks that authoritative server for the actual address. The answer comes back and gets cached at every level for a set amount of time, so the next person asking gets it much faster.

This whole dance usually finishes in a few milliseconds because of caching, but on a cold lookup it can add real delay, which is why DNS performance is worth paying attention to.

Step three: opening a connection

Now the browser has an IP address and needs a reliable channel to the server. For most traffic that means TCP, which guarantees that bytes arrive in order and nothing is silently lost.

TCP opens with a three-way handshake^[3]. Your computer sends a SYN packet, the server replies with a SYN-ACK, and your computer answers with an ACK. After those three messages the connection is established and both sides agree they can talk. That is one full round trip before any real data moves, which matters when the server is far away and each round trip costs tens or hundreds of milliseconds.

Step four: securing the connection

If the address uses HTTPS, there is another negotiation on top of TCP: the TLS handshake. Its job is to agree on encryption keys and to prove the server is who it claims to be.

The server presents a certificate signed by a trusted authority^[4], the two sides agree on a shared secret using public-key cryptography, and from that point on everything is encrypted. Older versions of TLS needed two round trips for this. TLS 1.3, the current version, trimmed it to one^[5], and can sometimes resume a previous session with none at all. The details of certificates and trust deserve their own article, but the short version is that this step is what turns a readable connection into a private one.

Step five: the HTTP request and response

With a secure connection open, the browser finally asks for the page. It sends an HTTP request, which is mostly plain text describing what it wants.

GET /articles?page=2 HTTP/2
Host: www.example.com
Accept: text/html
User-Agent: Mozilla/5.0 ...

The server does its work, which might mean reading a file, running application code, or querying a database, and sends back a response. The response starts with a status code that tells the browser how things went: 200 for success, 301 or 302 for a redirect, 404 when the resource does not exist^[6], 500 when the server hit an error. After the status comes a set of headers and then the body, which for a web page is the HTML document.

Step six: the handoff to rendering

The HTML almost never arrives alone. As the browser reads it, it finds references to other resources: stylesheets, scripts, images, fonts. Each of those is another request, though the browser reuses the connection it already opened and fetches many of them in parallel.

This is where loading becomes rendering. The browser parses the HTML into a document model, applies the CSS, runs the JavaScript, and paints pixels to the screen. That process, the critical rendering path, is its own detailed subject and determines how quickly the page actually becomes useful rather than merely downloaded.

Why the whole chain matters

Every step here adds time, and the slow parts are usually not the ones people blame. A cold DNS lookup, a far-away server that costs a long round trip, a TLS handshake, and a dozen render-blocking resources can each cost more than the actual page content. When a site feels slow, the answer is almost always somewhere in this sequence: a name that took too long to resolve, a connection that was reopened when it did not need to be, or a server that sat thinking before it replied.

The reason this journey feels instant is that decades of engineering went into hiding its cost. Caches at every layer, connections that stay open and get reused, protocols redesigned to cut round trips, and servers placed physically closer to users through content delivery networks^[7] all exist to shrink the gap between pressing enter and seeing the page. Knowing what actually happens in that gap is the difference between guessing at performance and fixing it.

Sources (7)