0) You type the URL

1. UI & URL parse: The browser turns what you typed into a canonical URL (scheme,
host, port, path, query, fragment). If you typed [Link], it may assume
[Link]
2. HSTS upgrade: If the domain is on the browser’s HSTS list (or you visited it before
with HSTS), the browser forces HTTPS and refuses HTTP.
3. Service Worker check (navigation): If a registered Service Worker controls this scope,
it can intercept the request and serve from Cache Storage or decide to go to network.

1) Before hitting the network

4. HTTP cache lookup: Browser checks its memory/disk cache for a fresh response
matching the URL + method + Vary rules. If fresh, it uses it (done). If stale but
revalidatable (ETag/Last-Modified), it prepares a conditional request.
5. DNS cache & connection reuse: Browser checks: (a) open HTTP/2 or HTTP/3
connections to the same origin (connection coalescing may allow reuse across cert-
covered names), (b) connection pool, (c) DNS cache for the hostname.

2) Name resolution (DNS)

6. Which resolver & transport: The browser/OS stub resolver looks up the hostname via
your system DNS or a secure resolver (DoH/DoT) if configured.
7. Local shortcuts: Browser cache → OS cache → /etc/hosts/system hosts file.
8. Recursive resolution (at your resolver): If not cached, your resolver queries:
o Root servers (for TLD referral),
o TLD servers (e.g., .com),
o Authoritative DNS for the domain.
9. Records gathered: IPv4 A, IPv6 AAAA. Modern sites may also publish HTTPS/SVCB
records to advertise ALPN (h2/h3), preferred endpoints, and ECH (Encrypted Client
Hello) config.
10. DNSSEC (optional): Validates signatures to prevent tampering.
11. CDN & anycast: The authoritative DNS may return IPs for a nearby CDN edge, often
anycasted so you hit the closest POP.
12. EDNS Client Subnet (sometimes): Resolver may include a prefix of your IP so the
CDN can pick better nearby edges.

3) Getting to the server (routing & transport)

13. Choose IP & family: Browser picks IPv6/IPv4 using Happy Eyeballs (connect to both,
prefer the fastest).
 14. ARP/ND: Your machine resolves the next-hop MAC (ARP for IPv4, Neighbor
Discovery for IPv6).
15. NAT/firewall: Your router may NAT your private IP to a public one; local firewall rules
apply.
16. Path selection: Packets traverse ISPs and backbone networks; BGP determines inter-AS
routing.
17. MTU & PMTUD: Path MTU discovery ensures packets aren’t too large; fragmentation
is avoided when possible. ECN/DSCP may influence congestion/priority.

4) Connection setup
18. Protocol choice:

 If HTTP/3, the browser uses QUIC over UDP to the server/edge.

 Else, TCP for HTTP/1.1 or HTTP/2.

19. TCP handshake (if TCP): SYN → SYN/ACK → ACK (3-way handshake). Options
like MSS, window scaling, SACK negotiated.
20. QUIC handshake (if HTTP/3): QUIC integrates transport + crypto; the handshake is
combined with TLS 1.3 and can support 0-RTT resumption.

5) TLS (HTTPS) handshake

21. TLS version: Today typically TLS 1.3 (1.2 fallback if needed).
22. SNI/ECH: The client indicates the hostname via SNI so the right cert can be chosen.
With ECH, the SNI is encrypted (if supported) to protect privacy.
23. Certificates: Server sends its certificate chain (leaf + intermediates), possibly OCSP
stapled status and Certificate Transparency SCTs.
24. Verification: Browser validates the chain to a trusted root, checks hostname match,
validity period, revocation (OCSP/CRL), key usages, and policies.
25. Key exchange: Usually ECDHE for Perfect Forward Secrecy; both sides derive
symmetric keys.
26. ALPN: Application Layer Protocol Negotiation decides h2 (HTTP/2), http/1.1, or h3
(already implied with QUIC). Alt-Svc or HTTPS/SVCB may steer future connections to
h3.
27. Session resumption / 0-RTT: If you’ve connected recently, resumption can skip parts of
the handshake; 0-RTT may allow sending an early request (replay-safe semantics
required).

6) The HTTP request leaves your browser

28. Request line: e.g., GET /path?query HTTP/2.
 29. Headers assembled: Host, User-Agent, Accept*, Accept-Encoding, Accept-
Language, Referer/Referrer-Policy, Cookie, Sec-* hints, Cache-Control, If-
None-Match/If-Modified-Since if revalidating, Origin for CORS, Purpose,
Priority/Priority-CH, etc.
30. Body (if any): For POST/PUT etc. Encodings may be JSON, form, multipart.
31. Compression negotiation: Browser advertises support (gzip, br, zstd increasingly).
32. Proxies (if configured): Requests may go via a corporate forward proxy or PAC script
rules; CONNECT tunneling for HTTPS.

7) On the wire
33. HTTP/2 multiplexing: Many streams over one TCP connection; HPACK header
compression; stream priorities.
34. HTTP/3 multiplexing: Streams over QUIC; QPACK header compression; no head-of-
line blocking at transport level.
35. Congestion control: CUBIC/BBR/etc. ramp up throughput; loss/latency managed.

8) Edge & origin infrastructure receive it

36. Edge first (often): CDN POP or reverse proxy (e.g., Cloudflare, Fastly, Nginx, Envoy)
terminates TLS and applies:

 WAF rules (SQLi/XSS detection), bot filtering, DDoS mitigation, rate limiting.
 Cache lookup: If the resource is cacheable and present, the edge returns it immediately.

37. Cache miss → origin: The edge forwards to your origin through a keep-alive
connection, possibly via:

 Load balancer (L4/L7), picking a healthy server (round-robin/least-conn) and a zone.

 Service mesh (mTLS, retries, circuit breaking).

38. App tier: A web server (Nginx/Apache/Caddy) may reverse-proxy to an app server
(Node/Express, Django/Gunicorn, Rails/Puma, Go, Java/Spring, PHP-FPM, etc.) running
in a VM/container/serverless function.
39. Auth/session: Cookies (Secure, HttpOnly, SameSite) or headers (JWT/OAuth) are
validated; CSRF tokens checked for state-changing requests.
40. Business logic: Controllers/handlers run your code, call services, and query caches
(Redis/Memcached) and databases.
41. DB & storage: SQL/NoSQL queries execute; ORM may add caching; object storage
(images/video) may be fetched or signed URLs generated.
42. Templates/SSR/Site generation: Framework renders HTML (server-side rendering), or
returns JSON for SPAs, or serves prebuilt static files.
43. Response is prepared: Status line (e.g., 200/301/302/304/401/403/404/500), headers
(Content-Type, Content-Length or Transfer-Encoding: chunked, Cache-Control,
 ETag, Last-Modified, Set-Cookie, Strict-Transport-Security, Content-
Security-Policy, Cross-Origin-Embedder-Policy, Cross-Origin-Resource-
Policy, Permissions-Policy, Referrer-Policy, Alt-Svc, etc.), and the body.
44. Compression & transforms: Server/edge compresses (br/gzip/zstd), resizes images
(AVIF/WebP), minifies, or inlines small assets if configured.
45. Caching headers: Cache-Control/Expires, Surrogate-Control for CDNs, Vary to
key caches (e.g., Vary: Accept-Encoding, Accept-Language).

9) The response back to you

46. Transport back: Data streams over the established connection.
47. TLS record layer: Encrypted application data is decrypted at your browser.
48. HTTP/2 or /3 framing: Frames are reassembled per stream; header blocks
decompressed.

10) Browser receives the first HTML bytes

49. HTTP cache store: The browser stores according to caching headers and policies.
50. HTML parsing starts immediately: The parser tokenizes and builds the DOM
incrementally.
51. Preload scanner: In parallel, it scans for <link rel=preload>, CSS, JS, images, fonts;
kicks off high-priority fetches; honors <link rel=dns-prefetch>, preconnect,
prefetch.
52. CSS fetch & CSSOM: CSS files are fetched and parsed into the CSSOM. Render-
blocking: until CSSOM is ready, first paint is blocked.
53. JS execution:

 Classic <script> blocks parsing; defer waits until after HTML parse; async runs when
ready.
 Module scripts are deferred by default; import graphs can trigger more fetches.
 CORS rules apply for cross-origin module/worker fetches; SRI (integrity) may verify
content.

54. Font loads: @font-face triggers font fetches; font-display controls FOIT/FOUT
behavior.
55. Security checks: CSP may block inline scripts/styles, mixed content is blocked (HTTP
assets on HTTPS pages), X-Frame-Options/frame-ancestors affects embedding.
56. Layout & style: DOM + CSSOM → render tree → layout (box sizes/positions) → paint
→ composite. GPU may rasterize layers; compositing merges them for display.
57. Images & media: Deferred/lazy loading (loading=lazy) and decoding
(decoding=async) improve responsiveness; video may use MSE/EME for
streaming/DRM.
58. Event loop: The JS main thread runs tasks; microtasks (Promises) run after each task;
RAF (requestAnimationFrame) coordinates 60fps paints when possible.
 59. Storage: The page can use Cookies, localStorage, sessionStorage, IndexedDB, Cache
Storage (via Service Worker).

11) More network activity after the first page

60. Additional requests: CSS/JS/images/fonts fetch over the same connection(s),
multiplexed. Priority hints may reorder downloads.
61. SPAs & APIs: Single-page apps request JSON via fetch(); CORS preflights
(OPTIONS) happen for non-simple cross-origin requests; responses subject to same-
origin policies.
62. Push/Server events: WebSockets upgrade (101 Switching Protocols), Server-Sent
Events streams, or HTTP/3 datagrams if used.
63. Keep-alive & reuse: Connections are kept open for future navigations; HTTP/2/3
multiplex future requests.

12) Caching & revalidation on future visits

64. Fresh hit: If cache entry is fresh per Cache-Control, it serves instantly.
65. Conditional GET: Browser sends If-None-Match/If-Modified-Since; origin may
return 304 Not Modified with no body.
66. Service Worker (offline-first): Can serve from Cache Storage, fall back to network, or
use stale-while-revalidate patterns.

13) Redirects & special cases

67. Redirects: 301/308 (permanent), 302/303/307 (temporary or method-preserving). Chains
add latency; HSTS can eliminate HTTP→HTTPS redirect.
68. Alternate protocols: Alt-Svc may move future traffic to HTTP/3 without another DNS
lookup.
69. Captive portal: Some networks hijack DNS/HTTP until you sign in.
70. Certificate errors: If validation fails, the browser shows an interstitial and (by default)
blocks.
71. Error statuses: 4xx (client), 5xx (server), 421 (misdirected request in HTTP/2), 429
(rate limit).

14) Performance levers (what makes it feel

fast)
72. Preconnect/dns-prefetch: Warm up DNS/TLS/QUIC early.
73. Critical CSS & defer JS: Reduce render-blocking work; ship less JS.
74. HTTP/3 + TLS 1.3 + resumption: Fewer round trips; 0-RTT when safe.
 75. CDN edge caching: Shorter physical distance, smarter routing.
76. Optimized assets: Brotli/zstd, AVIF/WebP, responsive images (srcset), code-splitting,
tree-shaking.
77. Good caching headers: max-age, stale-while-revalidate, correct Vary, immutable
hashed filenames.

TL;DR flow
URL → (HSTS/Service Worker/Cache?) → DNS → (TCP or QUIC) → TLS → HTTP
request → CDN/WAF → Origin app → DB/cache → HTTP response (compressed,
cacheable) → Browser parses (DOM/CSSOM/JS) → layout/paint → further asset/API
fetches → interactive.

If you want, I can tailor this to a specific site and show which of these steps it actually uses
(HTTP/2 vs HTTP/3, CDN, caching headers, CSP, etc.) by inspecting its headers.

 Type a URL in the Browser

 Browser Checks Cache / Service Worker

 DNS Lookup (Find Server’s IP Address)

 Browser Connects to Server (TCP/QUIC Handshake)

 Secure Connection Setup (TLS/HTTPS Handshake)

 Browser Sends HTTP Request

 Server (or CDN) Processes Request

 Server Sends HTTP Response

 Browser Receives and Parses HTML

 Browser Loads CSS, JS, Images, Fonts

 Page Rendering (DOM + CSSOM → Layout → Paint)

 JavaScript Runs and Page Becomes Interactive

 Further Requests (APIs, Assets, User Actions)

 Caching for Faster Future Visits