A familiar action with many moving parts
You enter https://example.com/articles and press Enter. The browser must find a destination, establish a secure channel, request the resource, and turn the response into something you can see. Some steps may already be satisfied by caches or existing connections, so there is no single mandatory sequence of fresh network operations for every visit.
Start by separating three ideas: a URL names a resource, DNS helps translate a hostname into network addresses, and HTTP describes how clients and servers exchange requests and responses. The internet underneath carries packets between networks; it does not inherently understand pages or articles.
1. Interpret the URL
The browser parses the scheme (https), host (example.com), optional port, path, query, and fragment. A fragment such as #details usually identifies a location within the page and is not sent as part of the HTTP request target.
Browser policies may upgrade an HTTP URL to HTTPS, and a service worker or a fresh cache entry may serve the request without contacting the origin. Otherwise, the browser needs an appropriate connection to a server or intermediary.
2. Find an address with DNS
The browser and operating system check available DNS caches. If a suitable answer is absent, a resolver performs or arranges a lookup. A recursive resolver may consult root, top-level-domain, and authoritative DNS servers to find the record, though cached answers often eliminate some of those steps.
An A record holds an IPv4 address; an AAAA record holds an IPv6 address. DNS can return multiple addresses or aliases, and a CDN may direct different users to different endpoints. Record time-to-live values influence cache freshness. Changing DNS does not instantly update every cached answer across the internet.
DNS identifies an address; it does not itself fetch the page. The hostname also remains important after lookup because multiple websites can share infrastructure.
3. Establish transport and encryption
For HTTP/1.1 and typical HTTP/2 connections, the browser uses TCP, which provides an ordered, reliable byte stream. A TCP handshake establishes the connection, then TLS negotiates a secure session for HTTPS. HTTP/3 uses QUIC over UDP, integrating transport and TLS differently to reduce some connection and multiplexing costs.
During TLS setup, the server presents a certificate. The browser checks the hostname, validity period, trusted certificate chain, and other relevant policies. Negotiation establishes encryption keys. HTTPS protects data in transit and helps authenticate the server; it does not prove that the website's business is trustworthy.
Connections can be reused, and TLS resumption can reduce later setup work. Measuring one cold request may therefore give a different picture from normal repeated navigation.
4. Send the HTTP request
A simplified request looks like this:
GET /articles HTTP/1.1
Host: example.com
Accept: text/html
Real browsers send more headers, and HTTP/2 and HTTP/3 encode messages differently. Cookies may accompany a request when their scope and browser rules allow it. The server sees the method, target, headers, and any body.
A CDN, reverse proxy, or load balancer may receive the request first. It can serve a cached response, route traffic to an application instance, apply limits, or terminate TLS. The application may then query a database, call another service, or render HTML.
5. Receive a response
HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Cache-Control: max-age=300
<!doctype html>...
The status code describes the result. A redirect such as 301 or 302 can lead to another request. A 304 response can tell the browser to reuse a stored representation after a conditional request. Cache rules depend on headers, request properties, and whether the response is suitable for private or shared caching.
Compression reduces transfer size, while streaming can let the browser start processing before the entire response arrives. Time to first byte measures only one part of the experience; a quickly delivered HTML shell can still take a long time to become usable.
6. Render the page and fetch dependencies
The browser parses HTML into the document object model and CSS into styling information. It computes layout, paints visible content, and composites layers. Images, fonts, scripts, and stylesheets can trigger additional requests.
JavaScript may block parsing, change the document, or fetch more data. Script placement and attributes such as defer affect execution timing. Large images, expensive JavaScript, layout shifts, and third-party scripts can dominate page performance even when the server is fast.
The same-origin policy limits how scripts interact with other origins. CORS is a mechanism by which a server permits certain cross-origin access; it is not user authentication and does not stop every kind of request from being sent.
Where to look when a page feels slow
| Symptom | Investigate |
|---|---|
| Long wait before connection | DNS, network path, connection setup |
| Long wait for first byte | Server work, upstream dependencies, cache misses |
| Large download | Images, fonts, compression, unused assets |
| Slow interaction after load | JavaScript execution, rendering, third-party code |
Use the browser's Network and Performance panels to inspect timing and dependencies. Test cold and warm loads, mobile networks, and real user experience. The request travels through several independently managed systems; useful diagnosis begins by locating the slow stage instead of calling everything “the internet.”