What happens when you type a URL

1. Parse the URL

The browser splits the URL into a scheme (https), a host (example.com), an optional port (443 by default for https), a path (/search) and a query (q=café). Characters outside the safe ASCII set are percent-encoded as UTF-8 bytes, so the query becomes q=caf%C3%A9. If what you typed isn't a URL at all, the browser sends it to a search engine instead. It also checks the HSTS list: a site that has said "always use HTTPS" is never contacted over plain HTTP.

2. Resolve the name (DNS)

IP needs an address, not a name. The browser asks its own cache, then the operating system's, then a recursive resolver (your ISP's, your company's, or a public one). If the resolver doesn't have the answer cached, it walks the hierarchy: a root server points to the .com servers, which point to example.com's authoritative servers, which return the A (IPv4) or AAAA (IPv6) record. Each answer carries a TTL saying how long it may be cached. This usually takes a few milliseconds when cached and tens to hundreds when not; it normally runs over UDP, falling back to TCP for large answers, and increasingly over encrypted DNS (DoH, DoT).

3. Connect

With an address, the browser opens a TCP connection to port 443 (one round trip for the handshake, as the previous topic describes), or, if the server advertised HTTP/3, a QUIC connection over UDP that combines the transport and TLS handshakes.

4. Secure the connection (TLS)

In TLS 1.3 the client sends its supported ciphers and a key share; the server replies with its key share and its certificate, signed by a certificate authority the browser trusts. The browser checks that the certificate is valid, unexpired and issued for example.com, and both sides derive the session keys. That is one more round trip (zero on some resumed connections). From now on everything, including the path and the headers, is encrypted; only the host name is generally visible to the network.

5. Request and response (HTTP)

The browser sends something like:

1GET /search?q=caf%C3%A9 HTTP/1.12Host: example.com3Accept: text/html4Cookie: session=…

(HTTP/2 and HTTP/3 send the same information as binary frames.) The request may pass through a CDN, a load balancer and a reverse proxy before an application server builds the response: a status (200 OK, 301, 404, 500), headers such as Content-Type: text/html; charset=utf-8 and Cache-Control, and the body. The gap between sending the request and receiving the first byte (TTFB) is mostly server time.

6. Render

The browser parses the HTML into the DOM as it arrives. Stylesheets, scripts, images and fonts it references are new requests, often reusing the same connection. CSS is parsed into the CSSOM; scripts may run and change the DOM; layout computes where every box goes; paint and compositing draw pixels. A page is "loaded" in stages, and what users notice is when the main content appears and when they can interact.

Each step has its own cache: DNS answers, open connections, TLS session tickets, HTTP responses. A fast second visit is mostly the result of skipping steps, not making them quicker.