The request/response loop
Almost everything on the web is one machine politely asking another machine for a thing.
The web has one core move, repeated billions of times a second: a client asks for something, a server answers. That is it. Everything else (frameworks, databases, caches, deploy pipelines) is scaffolding around that one exchange.
- Click
The browser decides a new URL is needed. - Resolve
The name (example.com) is turned into a numeric address. - Connect
A secure channel is opened to that address. - Request
The browser sends a method, a path, and some headers. - Respond
The server sends a status code, headers, and a body. - Render
The browser turns the body into pixels, fetching more as it goes.
Notice that steps two through five involve machines you do not own and cannot see. When someone says "the site is slow", they have told you nothing about which of those six steps is slow. Learning to ask "slow where?" is most of debugging.
The four parts of a request
- A method: the verb. GET means "give me", POST means "here, take this".
- A path: which thing, like /courses/databases.
- Headers: metadata about the request, like who you are and what formats you accept.
- A body: the payload, only present on requests that are sending something.
A response has almost the same shape: a status code instead of a method, then headers, then a body. When you read a network tab or a server log, you are reading these four things over and over. They are the vocabulary.
When my app fetches data, is that a separate request from the one that loaded the page?
It usually is, and that is why a page can appear instantly and then sit there with a spinner. Two requests, two chances to be slow.
What to remember
- Client asks, server answers. Everything else is decoration on that.
- Requests are stateless by default, so memory has to be added on purpose.
- A request is a method, a path, headers, and maybe a body.
Terms in this lesson
Field notes
Loaded from a deliberately slow source. The lesson above was already readable while this was still travelling. That is streaming, and it is the same trick a chat interface uses.
The bug was three caches deep
A team spent two days on a "deploy that did not work". The deploy was fine. A CDN rule was caching the HTML document itself for an hour, so every visitor kept getting the previous build. The fix was one header; finding it needed knowing the copies existed.
Reported by a solo founder, 2024
Nobody had opened the empty state
A product launched with a dashboard that looked superb with demo data and completely blank on day one. Every new signup saw an empty white rectangle and assumed the app was broken. Signup-to-activation doubled after a two-hour fix.
Common enough to be a cliché
resolved in 899ms · region iad1
Hide field notes toggles a search param the loader reads. With it off, the slow promise is never created, so nothing streams.