Explain how a web product works, from browser to server
Follow a request from URL to database, read the Network tab, place an incident in the right layer, and map your own product.
Explain, with a diagram, what happens between a user's click and a page of your product appearing on screen: domain name and DNS, HTTPS, HTTP request and response, browser, CDN, frontend, backend, API, database, caches and environments. You learn to read your browser's Network tab, to place an incident in the right layer and to ask the technical team the right questions. You leave with an annotated diagram of a request's journey through your own product, reviewed by a developer.
What you will be able to do
- Describe the steps of a web request, from the typed address to the displayed page (URL, DNS resolution, encrypted connection, HTTP request and response, browser rendering).
- Read an HTTP exchange in the browser's Network tab (method, URL, status code, headers, cookies, duration) and draw a first diagnosis from it.
- Explain how responsibilities are split between browser, frontend, backend, API, database and third-party services, and place where a business rule must run.
- Explain the role of a CDN and of caches (browser, CDN, server) and anticipate their effects on speed, data freshness and releases.
- Tell apart local, preview, staging and production environments, and say what changes from one to another (configuration, data, secrets).
- Place a symptom (slowness, blank page, error, stale data) in the right layer and ask the technical team precise questions.
- Produce the annotated diagram of a request's journey through your own product and have it validated by a developer.
Prerequisites
- Use a web browser (Chrome, Edge, Firefox or Safari) and a digital product every day
- Have access to a web product to study, ideally your own, and to a developer who can review your diagram at the end of the course
- No coding knowledge is required. Two terminal commands are offered as options, always with an in-browser alternative.
- This course opens the AI Product Builder and Technical PM paths. It does not teach development: it aims at understanding, vocabulary and diagnosis.
Syllabus
What will I be able to explain by the end of this course, and in what order?
- Course overview2 steps
Objective · By the end of this overview, you will know what you will be able to explain (the full journey of a request through a web product), the deliverable you will produce on your own product and which five modules get you there.
What happens between the moment you type an address and the moment the page appears?
Objective · By the end of this lesson, you will be able to break down a URL and describe, in order, the six steps that lead from the typed address to the displayed page, stating what happens on the user's side and what happens on the servers.
Objective · By the end of this lesson, you will be able to explain how a domain name is translated into an IP address, read the main DNS records and the effect of their TTL, and say what an HTTPS connection guarantees, and what it does not.
What does an HTTP exchange contain, and how does the browser turn the response into a page?
Objective · By the end of this lesson, you will be able to open your browser's Network tab, read an HTTP request (method, URL, status code, headers, cookies, duration) and draw a first diagnosis to pass on to the team.
Objective · By the end of this lesson, you will be able to explain how the browser turns HTML, CSS and JavaScript into a displayed page, tell apart client-side, server-side and static rendering, and relate these choices to the Core Web Vitals.
Who does what in a web product, and where must each rule run?
Objective · By the end of this lesson, you will be able to split a feature's responsibilities between frontend, API and backend, read a JSON data exchange and justify that a business or security rule is checked on the server side.
Objective · By the end of this lesson, you will be able to describe what sits behind an API (database, file storage, third-party services, background jobs, logs) and choose, for a feature, what must happen during the request and what can happen in the background.
Why is the product fast, why does it sometimes show stale data, and why does a bug only appear in production?
Objective · By the end of this lesson, you will be able to explain the role of a CDN and of the three cache levels (browser, CDN, server), read a Cache-Control header and propose a way to keep displayed data from going stale.
Objective · By the end of this lesson, you will be able to tell apart a product's environments (local, preview, staging, production), list what changes from one to another (configuration, data, secrets, third-party services) and derive hypotheses when a problem only appears in one of them.
How do I use all of this to qualify an incident and describe my own product?
Objective · By the end of this lesson, you will be able to attach a symptom (slowness, blank page, error, stale data, action with no effect) to a likely layer of the journey, gather the useful evidence and write a report that lets the team act fast.
Objective · By the end of this lesson, you will be able to produce the annotated diagram of a request's journey through your own product (eight zones, five annotations per zone) and have it validated by a developer.
Objective · By the end of this lesson, you will have the course's templates, checklists and prompts, and you will have planned how to apply them to your product over 7 and 30 days.