Beyond the Click: What Happens When You Open a Website?

When you enter https://example.com/ in a browser, it does not immediately download a finished page from a single computer. It may resolve a hostname, reuse an existing connection or establish a new encrypted one, exchange HTTP messages, and retrieve more resources as the document is parsed.

Those steps matter when a site feels slow or fails to load. A DNS problem, a connection failure, a long wait for the first byte, and a slow download are different problems. You can observe much of the distinction in your browser's Network panel.

This article follows one illustrative HTTPS navigation from the address bar to the response. The path is not identical on every visit: caching, proxies, service workers, redirects, CDNs, and HTTP versions can change or skip steps.

First, separate the URL from the network address

Consider the URL https://example.com/guide:

• https is the scheme: it tells the browser to use HTTP over a secure transport.
• example.com is the hostname: it identifies the site the client wants to reach.
• /guide is the path: it identifies a resource to request after the client has reached an HTTP endpoint.

The hostname is not an IP address, and DNS does not look up the /guide path. DNS resolves names to records. An A record provides an IPv4 address; an AAAA record provides an IPv6 address. Other record types and aliases may be involved.

A browser or operating system may already have a usable answer cached. Otherwise a recursive DNS resolver can return a cached record or obtain an answer through the DNS hierarchy. The result is not necessarily the IP address of the machine that runs the application's backend. With a content delivery network (CDN) or reverse proxy, it may lead to an edge server that accepts the connection on the site's behalf.

The practical point: DNS tells the client where it can connect; HTTP tells that endpoint which resource it wants. See Cloudflare's explanation of DNS resolvers and its A/AAAA record reference.

Next, the browser needs a usable connection

After resolving a destination, the browser needs transport and security before it can exchange a protected HTTP request. There is no single universal handshake for every modern website.

For a new HTTP/1.1 or HTTP/2 connection over HTTPS, the common path is:

1. Establish a TCP connection to the destination (or to a configured proxy).
2. Negotiate TLS, including verification of the server's certificate and agreement on cryptographic keys.
3. Send HTTP requests and receive responses over the protected connection.

HTTP/3 is different. It carries HTTP over QUIC, which runs over UDP and provides its own reliable streams and cryptographic handshake. Saying that all web requests use TCP is therefore incorrect. HTTP/2 can multiplex multiple request/response streams over one connection, while HTTP/3 uses QUIC streams. RFC 9114 specifies HTTP/3.

TLS protects the confidentiality and integrity of data in transit and authenticates the server to the client. It does not mean that every detail about a connection, including its destination IP address, is concealed from the network. For the security model, see MDN's TLS overview.

A connection may already exist when you navigate. When the browser reuses it, there may be no new DNS, TCP, or TLS phase visible for that particular request. Redirects, alternative endpoints, and network changes can make the sequence longer.

HTTP asks for a resource, not an entire rendered page

Once the connection is ready, the client sends an HTTP request. For example, an HTTP/1.1 request for the illustrative /guide path might look like this:

GET /guide HTTP/1.1
Host: example.com
Accept: text/html

This is illustrative request syntax, not a captured request or proof that example.com/guide exists. HTTP/2 and HTTP/3 encode equivalent request semantics differently; they do not send this exact HTTP/1.1 text on the wire.

The responding endpoint could be a CDN edge, a reverse proxy, or an application server. It may return an HTML document, generate a response using application logic, fetch data from another service, serve cached content, or redirect the browser somewhere else.

The status code changes what happens next:

Even after the initial HTML arrives, the browser may request stylesheets, scripts, images, fonts, or API data. Those resources can have separate domains, connections, caching rules, and delays. For an introduction to request/response behavior, consult MDN's HTTP overview and HTTP caching guide.

Where do packets and routers fit?

Network traffic is divided into smaller units for transmission. At the IP layer, packets contain routing information including source and destination IP addresses; routers use destination information and routing tables to forward them toward the next hop.

It is important not to collapse every layer into one imaginary "packet envelope":

• IP addresses and forwards packets, but does not itself guarantee that they arrive.
• TCP provides an ordered, reliable byte stream for connections that use TCP. Its sequence numbers and retransmission behavior are not generic fields supplied by IP.
• QUIC provides reliable streams over UDP for HTTP/3, so TCP is not the mechanism that recovers a lost HTTP/3 stream's data.
• HTTP defines request and response semantics above those transport details.

Packets do not need to follow a dedicated end-to-end wire. Traffic may cross home equipment, an ISP, transit or peering networks, and a CDN before reaching an endpoint. Different packets can encounter different paths, but you should not assume that each packet necessarily takes a different route.

Packet switching helps networks share capacity among many flows. It does not make failures free: packet loss, congestion, retransmissions, and extra network round trips can still delay the response. The web is a service built on top of this networking infrastructure; it is not synonymous with the entire Internet.

Trace the journey in Chrome DevTools

Here is the most useful difference between understanding the terms and being able to diagnose a page load.

1. Open a website in Chrome, open DevTools, and select Network.
2. Enable Preserve log if you want to keep navigation redirects visible. Reload the page to capture the navigation.
3. Select the main document request, usually the top-level HTML navigation, rather than an image or analytics request.
4. Open Headers to inspect the request URL, status, and response headers. Open Timing for the phases the browser recorded.
5. Compare a normal reload with Disable cache enabled while DevTools is open. Treat these as different test conditions, not interchangeable performance results.

A fresh connection might show DNS lookup, initial connection, and security negotiation before the request is sent. A reused connection may show no new setup phases. A service worker or cached response can take another path entirely.

Use the following as diagnostic clues, not one-to-one proofs:

Chrome documents these fields in its Network timing reference. The waterfall can also show that an apparently slow document was preceded by a redirect or that a late-starting asset, rather than the initial HTML, is holding up the page.

One common mistake: turning on Disable cache and then using the resulting timing to describe the normal repeat-visit experience. That setting is useful for isolating network requests, but it changes the scenario you are measuring.

A command-line view with curl

You can inspect an HTTPS transfer without a browser. The following example requests the reserved demonstration domain's root document, discards the body, and prints timing milestones:

curl --http1.1 --silent --show-error --output /dev/null \
  --write-out 'DNS: %{time_namelookup}s\nTCP: %{time_connect}s\nTLS: %{time_appconnect}s\nFirst byte: %{time_starttransfer}s\nTotal: %{time_total}s\n' \
  https://example.com/

On Windows PowerShell, invoke curl.exe explicitly if curl is mapped to a PowerShell command.

The values are elapsed timestamps from the start of the transfer, not five separate durations to add together. For example, time_starttransfer includes earlier connection work; it is not "server execution time." The request is explicitly limited to HTTP/1.1 for a simpler comparison. A proxy, local DNS cache, or network policy can change the output, and curl is not a substitute for observing the browser's rendering or resource waterfall. The curl write-out documentation defines each field.

What happens after the first response?

Receiving the initial HTML document is only one milestone. The browser must parse markup, discover and fetch dependent resources, calculate layout, and paint the page. JavaScript can introduce additional requests or delay rendering. A successful network response therefore does not imply that the user can already see or interact with the complete page.

Those browser-side stages are covered separately in From URL to UI: How Browsers Render a Web Page. Keeping the two models separate makes debugging easier: first identify whether the delay is in name resolution, connection setup, request/response exchange, or resource delivery; then examine rendering and main-thread work.

The next time a page seems slow, inspect a single document request before blaming "the internet." Its timing and headers will not answer every question, but they can tell you which part of the journey to investigate next.