How the Web Works
Follow a request from typing a URL to seeing a page — the big picture every developer needs
Before any framework, there's the web itself: clients asking servers for resources over a network. Understanding this request–response cycle makes everything above it — HTML, APIs, caching, deploys — click into place.
Clients and Servers
The web runs on a simple relationship:
- A client (your browser) requests resources.
- A server responds with them — HTML, images, JSON, whatever.
The client always initiates. Servers don't push pages at you unprompted; they wait for requests and answer. Everything else is detail on top of this.
Client (browser) ──── request ───▶ Server
◀─── response ────
What Happens When You Enter a URL
Type https://example.com/about and press Enter. Roughly this sequence fires:
1. DNS lookup example.com → 93.184.216.34 (find the server's address)
2. TCP connection browser opens a connection to that IP
3. TLS handshake https → negotiate encryption
4. HTTP request GET /about → sent to the server
5. Server responds 200 OK + HTML
6. Browser renders parses HTML, requests CSS/JS/images, paints the page
Each step is its own topic in this track — DNS, TLS, HTTP, and rendering all get their own lesson. Right now, just hold the shape of the whole journey.
That single page load triggers many requests: one for the HTML, then more for each stylesheet, script, font, and image the HTML references. A typical page makes dozens of requests.
Anatomy of a URL
A URL (Uniform Resource Locator) is an address with structured parts:
https://api.example.com:443/users?page=2#top
└─┬─┘ └──────┬──────┘ └┬┘ └─┬──┘ └─┬──┘ └┬┘
scheme host port path query fragment
| Part | Example | Meaning |
|---|---|---|
| Scheme | https | Protocol to use |
| Host | api.example.com | Which server (resolved via DNS) |
| Port | 443 | Which "door" on the server (443 = HTTPS default) |
| Path | /users | Which resource |
| Query | ?page=2 | Parameters for the request |
| Fragment | #top | A spot within the page (never sent to the server) |
Stateless by Design
HTTP is stateless: each request stands alone, and the server doesn't inherently remember previous ones. That's why mechanisms like cookies and tokens exist — they re-attach identity to each otherwise-independent request. Statelessness is what lets the web scale to billions of requests across many servers.
Frontend and backend are two halves of one conversation
Everything you build — a React app, an API, a database query — is ultimately serving or making requests in this cycle. Keeping the request–response model in mind is the fastest way to reason about bugs.