It's the classic interview question and, above all, the highest-leverage mental map in web development: every layer you understand is a whole class of bugs you can diagnose. Typing https://miguelacm.es and seeing the page within 300 milliseconds implies brutal orchestration between your device, dozens of intermediate servers and the site itself. Layer by layer, in real execution order.
1. Parsing the URL
Before touching the network, the browser decomposes what you typed:
https://miguelacm.es/blog/article?ref=tw#summary
└─┬─┘ └────┬─────┘└───┬────────┘ └┬──┘ └───┬──┘
scheme host path query fragment
The scheme decides the default port (443), the host identifies the destination, the fragment (#summary) never travels to the server — it stays in the browser for scroll positioning. Loose text ("miguelacm") first goes through search-bar or domain heuristics.
2. Resolving the name: DNS
The browser needs an IP. It checks its cache, then the OS's, then asks the configured resolver — which may answer from cache or start the full resolution chain: root servers → .es TLD → domain's authoritative nameserver. Typical result: an IPv4 (A record) or IPv6 (AAAA) address in 10-50 ms thanks to cascading caches.
Modern detail: even before DNS, if there's a cached HSTS record from a previous visit, the browser forces https:// without trying HTTP. And via Service Workers, a PWA could answer without touching the network at all — the point where this journey may end before starting.
3. Opening the connection: TCP (or QUIC)
With the IP in hand comes transport:
Classic TCP: three-way handshake — SYN, SYN-ACK, ACK. A full round trip just to open the conversation.
QUIC (HTTP/3): over UDP, negotiating transport and encryption together, cutting round-trips and eliminating TCP's head-of-line blocking (a lost packet delays only its stream, not everything).
The choice depends on server advertisement via Alt-Svc or HTTPS DNS records. On fresh connections and lossy networks HTTP/3 clearly wins; on warm reconnects the difference narrows.
4. Encrypting the channel: TLS
Over transport runs the TLS handshake: certificate verification against known authorities, ephemeral key agreement with ECDHE, establishment of the AES-GCM channel. In TLS 1.3 this adds one extra round trip (or zero with session resumption). From here, everything traveling is encrypted and integrity-checked.
5. The HTTP request
The browser sends its first real request:
GET /blog/article HTTP/1.1
Host: miguelacm.es
User-Agent: Mozilla/5.0 ...
Accept: text/html,...
Accept-Encoding: gzip, br
Cookie: session=...
The server (more often its CDN) responds with status, headers and compressed body:
HTTP/2 200
content-type: text/html; charset=utf-8
content-encoding: br
cache-control: public, max-age=3600
<!doctype html>...
If the resource is fresh in CDN cache, the edge answers in milliseconds; otherwise it travels to origin. There may be chained redirects (each one an extra request — why auditing redirect chains matters), authentication, rate limiting or any backend logic. Status rules are systematized in the HTTP status codes guide.
6. Rendering: bytes to pixels
With HTML arriving, the browser starts the critical rendering pipeline — where a "slow" page is truly decided:
- HTML parsing → DOM. External resources change strategy: CSS blocks first render (nobody wants unstyled content), JS blocks parsing by default unless
async/defer. - CSS → CSSOM, whose combination with the DOM yields the render tree.
- Layout: compute each node's geometry.
- Paint: rasterize layers.
- Composite: assemble on GPU.
Images discover dimensions upon download (no declared width/height = layout shift, CLS penalty), fonts may trigger FOUT/FOIT depending on font-display, and heavy JavaScript hogs the main thread freezing interactivity — the INP metric. The whole optimization ecosystem (preload, srcset, lazy loading) exists to manipulate this pipeline.
7. Secondary requests and continuous state
Initial HTML rarely ends things: fetch/XHR toward APIs, WebSockets for realtime, speculative prefetches. Every cross-origin call activates CORS machinery, every subresource inherits context security (mixed content blocked under HTTPS), and service workers can intercept it all for offline function.
Diagnosing your own sites
This map turns symptoms into causes: always slow → check DNS/TLS (fresh connection); sometimes slow → cache/CDN; broken only cross-origin → CORS; layout jumps → dimensionless images. Our web analyzer runs part of this audit automatically on any domain, and if you administer the server behind it, the self-hosting guide gives you control of every layer.
FAQ
How many layers can I debug from the browser? Almost all: Network tab shows per-phase DNS/waiting/TTFB, Security details certificate and negotiated protocol, Performance profiles rendering. Only inter-network routing stays invisible.
Why is the second load much faster? Confluence of caches: remembered DNS, reused TCP/TLS connection (keep-alive), resources in fresh max-age HTTP cache, plus parser-accelerated re-render.
Does HTTP/3 require app changes? No: transparent at application level. Benefits mobile and unstable networks especially; enabling it is server/CDN work.
Analyze any website's performance with our Web Analyzer, free and no sign-up.