What Happens When You Load a Web Page

The short answer

On a first visit to https://www.example.com/, the browser has to do four things before it sees any HTML, and each one costs at least one round trip, a message out and its answer back:

DNS turns the name into an IP address.
TCP opens a reliable connection to port 443 on that address.
TLS proves the server is really www.example.com and sets up encryption.
HTTP asks for the page and gets it back.

That is four round trips over TCP, or three over HTTP/3, which merges the connection and encryption steps. Distance matters more than bandwidth here: each round trip to a server across an ocean adds around 100 milliseconds or more, however fast the connection is.

Watch one page load

Each arrow below is one message, in the order it is sent. Time runs downwards. Press Play to send them one after another, use Next and Previous to go at your own pace, or pick any step from the list.

DNSBrowser → DNS resolverThe browser asks for the addressThe browser asks its recursive resolver for the A (IPv4) and AAAA (IPv6) records of www.example.com, over UDP port 53 or an encrypted transport such as DNS over HTTPS. If a fresh answer is already cached on the device, this phase is skipped.
DNSDNS resolver → BrowserThe resolver answersThe resolver returns the address, from its cache or after asking the root, TLD and authoritative name servers in turn. The answer carries a TTL that says how long it may be reused.
TCPBrowser → Web serverThe browser opens a TCP connectionThe browser sends a SYN to port 443 on 192.0.2.80, from a temporary port of its own, with a random starting sequence number.
TCPWeb server → BrowserThe server acceptsA web server is listening, so the server’s operating system replies SYN-ACK with its own sequence number and an acknowledgment of the browser’s.
TCPBrowser → Web serverThe connection is openThe browser acknowledges, and TCP is established one round trip after the SYN. The first TLS message leaves straight after this ACK, usually in the same instant.
TLSBrowser → Web serverTLS starts with ClientHelloThe browser offers TLS 1.3, names the site it wants (Server Name Indication), lists the HTTP versions it speaks (ALPN, such as h2 and http/1.1) and sends a key share so both sides can agree on keys right away.
TLSWeb server → BrowserThe server proves who it isThe server picks the cipher suite and sends its own key share. Everything after ServerHello is encrypted: the certificate chain, a signature that proves it holds the private key, and Finished. The browser checks that the certificate covers www.example.com and chains to a root it trusts.
TLSBrowser → Web serverThe browser finishes TLSThe browser sends its own Finished. The encrypted channel is ready after one round trip, where TLS 1.2 needed two.
HTTPBrowser → Web serverThe browser asks for the pageThe request follows Finished without waiting, encrypted. It carries the method, path and host, plus headers such as accepted formats, language and cookies. Over HTTP/2 it travels as a binary HEADERS frame rather than lines of text.
HTTPWeb server → BrowserThe server sends the pageThe server answers with a status code, headers such as Content-Type and Cache-Control, and the HTML. The browser starts parsing as the first bytes arrive and requests the stylesheets, scripts and images it finds over the same connection.

A first visit to an HTTPS site, one message per step. Press Play or Next to send each message in turn, or pick a step from the list.

The addresses are reserved documentation addresses, and real page loads involve more packets than shown: TCP acknowledges data as it arrives, a large page spans many segments, and the browser usually asks for the IPv4 and IPv6 addresses at the same time. The messages above are the ones that decide how long you wait.

The four protocols at a glance

Protocol	Its job in a page load	Runs over	Usual port	Defined in
DNS	Finds the server’s IP address from its name	UDP, or TCP, TLS, HTTPS or QUIC	53 (853 for DNS over TLS, 443 for DNS over HTTPS)	RFC 1034, RFC 1035
TCP	Delivers bytes reliably and in order	IP	443 for HTTPS, 80 for plain HTTP	RFC 9293
TLS 1.3	Authenticates the server and encrypts the connection	TCP (built into QUIC for HTTP/3)	Same port as the protocol it protects	RFC 8446
HTTP	Requests the page and returns it with a status code	TLS over TCP (HTTP/1.1, HTTP/2) or QUIC (HTTP/3)	443	RFC 9110, RFC 9113, RFC 9114

In layer terms, IP moves packets between machines, TCP and UDP move data between programs on those machines, and DNS, TLS and HTTP sit on top. The OSI and TCP/IP models guide explains the layers.

Step 1: finding the server with DNS

The browser first checks whether it already knows the address. It looks in its own cache, then asks the operating system, which has a cache of its own and the hosts file. Only if neither has a fresh answer does a query go out to the recursive resolver, usually run by your network or internet provider, or a public service you chose.

The resolver answers from its cache if it can. Otherwise it walks the tree: a root server points it to the .com servers, which point it to example.com’s authoritative name servers, which give the address. Each answer has a TTL, so the next visitor gets it from cache. DNS TTL and caching covers how long answers are kept.

Browsers usually ask for A (IPv4) and AAAA (IPv6) records together and, if both come back, race connections to both and keep whichever works first, a technique called Happy Eyeballs. Many also ask for the HTTPS record, which can say that the site speaks HTTP/3.

If this step fails, nothing else happens: the browser shows a “server not found” error such as DNS_PROBE_FINISHED_NXDOMAIN without ever contacting the site. You can look up a domain’s live records with Domain Visualizer.

Step 2: opening a TCP connection

With an address in hand, the browser opens a TCP connection to port 443 with the three-way handshake: SYN, SYN-ACK, ACK. It takes one round trip, and the server’s operating system completes it before the web server program sees anything. The TCP handshakes and port states guide explains what happens when the port is closed or filtered instead.

TCP is what makes the rest dependable. It numbers every byte, resends what gets lost and slows down when the network is congested, so HTTP never has to deal with missing or out-of-order data. The cost is that one lost packet holds up everything behind it on that connection until it is resent.

The TCP Port Check tests this step on its own: it connects to a host and port and tells you whether the handshake completed and how long it took.

Step 3: securing it with TLS

TLS turns the TCP connection into an encrypted one and, just as importantly, proves the browser is talking to the real site. TLS 1.3, used by most HTTPS traffic today, does it in one round trip:

ClientHello: the browser lists the cipher suites it supports, sends a key share, names the site with Server Name Indication (SNI) so a server hosting many sites knows which certificate to use, and offers HTTP versions through ALPN.
ServerHello and the rest: the server picks the options and sends its own key share. From here on everything is encrypted, including the server’s certificate chain, a signature made with the certificate’s private key, and a Finished message that confirms nothing was tampered with.
Finished: the browser checks the certificate is valid, unexpired and issued for www.example.com by an authority it trusts, then sends its own Finished.

TLS 1.2 needed two round trips for the same thing. If the certificate check fails, the browser stops and shows a full-page warning, and no HTTP request is sent. On Security Posture, the TLS and Certificates card checks which certificate authorities may issue for a domain (CAA) and any DANE records, and the Website card checks HTTPS, the redirect from HTTP and HSTS.

Step 4: asking for the page with HTTP

Only now does the browser send the request it wanted all along. A request names a method, a path and the host, and adds headers:

Part	Example	What it does
Method and path	GET /	Fetch the home page. Forms often use POST.
Host	www.example.com	Says which site is wanted, since one IP address can host thousands.
Accept, Accept-Language	text/html, en-US	Formats and languages the browser prefers.
Cookie	session=…	Sends back anything the site stored earlier, such as a login.

The response starts with a status code, such as 200 for success, 301 for a permanent redirect or 404 when the page doesn’t exist; HTTP status codes explained lists them all. Headers such as Content-Type and Cache-Control follow, then the HTML itself.

The page isn’t finished when the HTML arrives. As the browser parses it, it finds stylesheets, scripts, fonts and images and requests each one. HTTP/2 sends all of them over the one connection at the same time, which is why a second handshake is rarely needed. Files on other domains, such as a CDN or an analytics service, need their own DNS lookup and connection.

How HTTP/3 and QUIC save a round trip

HTTP/3 runs over QUIC, a transport built on UDP that includes TLS 1.3 inside its own handshake. The connection and the encryption are set up by the same messages, so the separate TCP round trip disappears. Step through the same page load over QUIC:

DNSBrowser → DNS resolverThe browser asks for the address and optionsAlongside A and AAAA, many browsers ask for the HTTPS record, which can advertise that the site speaks HTTP/3. A browser that visited before may already know from the Alt-Svc header the server sent last time.
DNSDNS resolver → BrowserThe resolver answersThe answer gives the address and, in the HTTPS record, the protocols the site supports. h3 means HTTP/3 over QUIC is available on UDP port 443.
QUICBrowser → Web serverOne packet starts transport and TLSThe browser sends a QUIC Initial packet to UDP port 443. It carries the TLS 1.3 ClientHello, so setting up the connection and setting up encryption happen together.
QUICWeb server → BrowserThe server answers both at onceThe server replies with ServerHello and then, encrypted, its certificate chain and Finished. The browser checks the certificate exactly as it would over TCP.
HTTP/3Browser → Web serverThe request rides with FinishedThe browser’s Finished and its HTTP/3 request usually leave in the same UDP datagram. Each request gets its own QUIC stream, so one lost packet does not hold up the others.
HTTP/3Web server → BrowserThe page arrives one round trip soonerThe response comes back after three round trips instead of four. On a repeat visit, 0-RTT resumption can let the browser send a request in its very first packet.

QUIC runs over UDP and builds TLS 1.3 into its own handshake, so the separate TCP round trip disappears.

QUIC also gives each request its own stream, so a lost packet only delays the file it belongs to, not every file on the connection as it would over TCP. Browsers fall back to HTTP/2 over TCP when UDP port 443 is blocked, which some corporate firewalls still do. The TCP vs UDP guide compares the two transports.

What makes a page load faster

Because each step waits for the one before it, the biggest wins come from skipping steps or shortening the distance:

Caching DNS answers. A cached answer skips step 1 entirely. Sensible TTLs keep answers in caches without making changes slow to take effect.
Reusing connections. Browsers keep connections open for a while, so the next page on the same site skips steps 1 to 3 and goes straight to HTTP.
Session resumption and 0-RTT. A browser that connected recently can resume TLS with a shorter exchange, and with 0-RTT can send its first request in its very first message.
Moving closer. A CDN answers from a nearby location, so each round trip is a few milliseconds instead of a hundred. How CDNs use DNS shows how visitors are sent to the closest one.
Fewer domains. Every additional domain a page loads from adds its own DNS lookup, handshake and TLS setup.

To see how far away a server is in time, Ping measures the round trip from probes around the world.

Time each step yourself

curl can report when each phase finished, measured from the start of the request:

System	Command
macOS and Linux	curl -so /dev/null -w "dns %{time_namelookup} tcp %{time_connect} tls %{time_appconnect} first byte %{time_starttransfer} total %{time_total}\n" https://example.com/
Windows PowerShell	curl.exe -so NUL -w "dns %{time_namelookup} tcp %{time_connect} tls %{time_appconnect} first byte %{time_starttransfer} total %{time_total}\n" https://example.com/

Each number is in seconds from the start, so subtract the one before it to get the time for that phase. Run it twice: the second run is often faster at the DNS stage because the answer is now cached.

In a browser, open the developer tools, go to the Network tab, reload and select the page’s first request. Its Timing view splits the request into the same phases: DNS lookup, initial connection, SSL (the TLS handshake) and waiting for the server’s response.

FAQ

Why does the second page on a site load faster?

Most of the work is already done. The address is cached, the browser usually still has the connection open, so it skips the DNS, TCP and TLS steps, and stylesheets, scripts and images often come from the browser cache.

Does HTTPS make websites slower?

Barely. TLS 1.3 adds one round trip when a connection opens and none for requests on a connection that is already open. Browsers only use HTTP/2 and HTTP/3 over encrypted connections, and those are usually faster than plain HTTP/1.1.

Why does the browser send the site name more than once?

One IP address can host thousands of sites. The name goes in the TLS ClientHello (SNI) so the server can choose the right certificate, and in the HTTP request (the Host header, or :authority in HTTP/2 and HTTP/3) so it can serve the right site.

Can someone on my network see which sites I visit?

Often, yes, even over HTTPS. They can see the IP addresses you connect to, plain DNS queries unless you use encrypted DNS, and the site name in the TLS ClientHello unless the site supports Encrypted Client Hello. They cannot see the pages, form data or cookies, which are encrypted.