What Happens After You Type a URL? DNS, TLS, HTTP, and Rendering

A URL is an instruction, not an IP address. The browser first parses https://shop.example/products/42 into a scheme (https), authority (shop.example), and path (/products/42). It may satisfy the navigation from an HTTP cache or let a Service Worker intercept it; otherwise, it needs a network route to an origin that can answer for that hostname.

The network path then performs six jobs. Name: resolve the hostname. Connect: establish a transport path. Secure: authenticate the server and derive encryption keys. Request: send HTTP semantics to the selected origin. Compute: let CDN, load balancer, application, cache, and database produce a representation. Render: parse the returned bytes into pixels and discover more resources.

These jobs can overlap or disappear on a warm navigation. DNS answers, TLS sessions, HTTP responses, and connections may already be cached or reusable. The sequence is therefore a mental model, not a guarantee that every navigation creates every exchange from scratch.

Domain Name System (DNS) maps names to records. For our URL, the browser ultimately needs an address record (A for IPv4 or AAAA for IPv6), possibly after following a CNAME alias. It checks available caches first: browser, operating system, and recursive resolver. On a miss, the recursive resolver follows the DNS hierarchy toward an authoritative name server and returns a record with a TTL that controls how long that answer may be cached.

The resolver answer is not necessarily the application server. It often points to a CDN or edge load balancer selected by geography, health, or traffic policy. DNS chooses a destination address; it does not prove that the destination is healthy, that its TLS certificate matches, or that /products/42 exists.

This distinction explains the failure we will create later. If shop.example changes from old origin 192.0.2.10 to new origin 198.51.100.20, resolvers may legally keep the old answer until its TTL expires. Deploying the new server and changing DNS are separate operations with separate clocks.

With an address selected, the browser needs a transport. A common HTTP/2 path establishes a TCP connection using the three-way handshake, then performs a TLS handshake. TLS authenticates the server certificate for shop.example, negotiates protocol parameters (including HTTP/2 through ALPN when supported), and derives keys that protect confidentiality and integrity before application data flows.

HTTP/3 changes the lower layers: it runs over QUIC, which uses UDP and incorporates the TLS 1.3 handshake into the transport. So “every HTTPS request does DNS → TCP → TLS” is not universally true. The stable idea is: resolve a destination, establish an authenticated encrypted transport, then exchange HTTP semantics over the negotiated protocol.

A certificate error stops the navigation before the application sees GET /products/42. Common causes are an expired certificate, a hostname missing from the certificate, an untrusted issuer, or the client clock being wrong. Retrying application code cannot repair a failed identity check.

Once the secure transport exists, the browser sends an HTTP request expressing intent: method GET, target /products/42, authority shop.example, and headers describing accepted representations, cookies, cache validators, and browser policy. RFC 9110 defines those semantics independently of whether the bytes travel over HTTP/1.1, HTTP/2, or HTTP/3.

The public address may terminate at a CDN. A fresh cached response can end the path there. On a miss, the request travels through a load balancer or reverse proxy to the application. The app validates the route, authenticates any session, loads product 42 from a cache or database, and returns a status, headers, and representation. A 200 means the server fulfilled the request; a 304 tells the browser to reuse its cached representation; a 404 is an application-level answer and is completely different from DNS NXDOMAIN.

Security boundaries accumulate along this path. TLS protects the hop to the terminating edge, while cookies and authorization determine user identity. The CDN or proxy must forward only trusted headers, and the app must authorize access to object 42 rather than assuming that possession of the URL is permission.

The first response is usually HTML, not a finished screen. The renderer parses HTML incrementally into the DOM and CSS into the CSSOM. It combines visible nodes and computed styles into a render tree, calculates geometry during layout, paints drawing commands, and composites layers into the pixels you see.

Parsing also discovers more work: stylesheets, fonts, images, modules, and scripts each become resource requests with their own cache and timing path. CSS can block rendering because the browser needs styles to construct the render tree. A classic script can block HTML parsing unless it is deferred, asynchronous, or a module with appropriate behavior. The page can therefore receive the main HTML quickly and still show content late.

JavaScript may then mutate the DOM, trigger more network requests, or cause additional layout and paint. DOMContentLoaded means the document has been parsed and deferred scripts have run; it is not the same as “the user can see the main product” or “every image has loaded.” Use paint and interaction metrics for user experience, not only the load event.

Trigger. The team deploys product version 2 to 198.51.100.20 and changes the A record, but the previous record had a one-hour TTL. One recursive resolver still returns old origin 192.0.2.10, where version 1 remains healthy. Symptom: some users see stale product data with HTTP 200; others see version 2. Application dashboards for the new origin look healthy because affected traffic never arrives there.

Root mechanism. DNS caches are allowed to reuse the old record until TTL expiry. This is not eventual consistency inside the product database, and retrying the same resolver may return the same cached address. The decisive evidence is disagreement between DNS answers plus the remote_ip that served the response.

Recovery and prevention. Confirm the authoritative record, compare recursive resolvers, and use curl --resolve to test each origin while preserving the hostname for TLS and HTTP routing. Keep the old origin compatible until the previous TTL window has passed; if emergency risk justifies it, restore service there or revert the authoritative record. Before planned migrations, lower TTL far enough in advance for the old TTL to expire—lowering it at cutover does not shorten answers already cached.

Debugging becomes simpler when every symptom is assigned to the earliest stage that can produce it. NXDOMAIN is naming. A certificate warning is TLS identity. A 404 is an HTTP application response. A long wait before response headers is often server or network time to first byte; a fast response followed by a blank or janky screen belongs to rendering or JavaScript.

Start with browser DevTools Network: preserve the log, reload, inspect the main document, and record DNS/connect/TLS timing when exposed, status, protocol, remote address, cache source, TTFB, and download. Then reproduce outside the browser with curl; inspect DNS with dig; inspect certificates with openssl; and correlate the response request ID through edge and application logs.

Do not optimize the largest-looking box without representative measurements. DNS time can be zero because of cache reuse. Connection time can be zero because the browser reused a socket. TTFB combines network and server work. Compare cold and warm navigations, representative regions, and realistic devices before changing architecture.