The HTTP Request Lifecycle in Browsers
The problem
A page frequently needs to fetch additional data or resources after it has already loaded, without freezing the user interface while waiting — the browser needs a way to issue HTTP requests asynchronously and hand the eventual response back to JavaScript when it arrives.
Why now
HTTP fundamentals already defined the request/response protocol itself; this topic is where that protocol gets triggered from inside a running page, and it relies entirely on the event loop already covered to avoid blocking the page while the network round-trip is in flight.
Mental model
fetch() kicks off an HTTP request and immediately returns a Promise — the actual network round-trip happens off the main thread's timeline, and when the response arrives, its handling is queued through the exact same task-queue mechanism the event loop describes for any other async operation, not delivered instantly the moment bytes arrive.
Requires
- HTTP FundamentalsNetworking
The browser's request lifecycle is issuing and receiving exactly the HTTP requests/responses already defined; you need to know what's inside a request and response before tracing how the browser handles one.
- The Event LoopJavaScript Runtime
fetch() and XMLHttpRequest are asynchronous, resolving through the same event-loop task-queue mechanism as any other async operation — you need that model to explain why a response doesn't interrupt currently-running code.
Unlocks
Used in
- fetch() and XMLHttpRequest for all client-side network requests
- Single-page applications fetching data after initial page load (the entire premise of a SPA)
- Understanding CORS errors as a browser-enforced restriction on cross-origin requests
- Loading indicators and race conditions when multiple requests are in flight simultaneously
Projects
- Use fetch() to request data from an API, log the timing of each stage (request sent, response received, JSON parsed), and relate it back to the event loop
- Deliberately trigger and diagnose a CORS error, then explain what the browser is protecting against
Examples
- fetch('/api/user').then(r => r.json()) returns a Promise immediately; the actual data arrives later via the task queue
- A CORS error occurs when a page at one origin tries to fetch from another origin that hasn't explicitly allowed it via response headers
Resources
- MDN — Using Fetcharticle
Mastery checklist
- I can trace a fetch() call from invocation through Promise resolution to handling the response
- I can explain why an in-flight fetch doesn't block the rest of the page from running
- I can explain what CORS is and why browsers enforce it
- I can handle a race condition between multiple in-flight requests correctly