CSE 134B Web Client Languages
  1. Foundations
  2. Request Lifecycle
  3. The Life of a Page Load, From the User's Point of View

Series

The Life of a Page Load, From the User's Point of View

Every technical choice you make lands on a person. This series follows one page — the Terra Outfitters store — down a ladder of user needs, and shows which of your choices hold each rung up.

Two stories about the same second

When someone opens your page, two stories run at once.

The technical story runs bottom-up: type a URL, resolve DNS, open a connection, negotiate TLS, send a request, receive a response, parse HTML into a DOM, fetch and apply CSS, execute JavaScript, lay out, paint, and finally respond to input. Developers live here. Every course in this sequence touches a stage of it.

The user's story runs top-down, as a chain of questions. Each question only gets asked if the one before it was answered yes:

  1. Is it there? Availability. The URL resolves, the server answers, nothing in between blocks it. Fail here and nothing else you built exists.
  2. Did it arrive in time? Loadability. A page that needs thirty seconds on a slow connection is, for that user, down. Page construction and performance live on this rung.
  3. Can I perceive and operate it? Accessibility. It reached the device — can it reach the person? Eyes, ears, hands, and the assistive technology between them and your markup.
  4. Can I read it? Internationalization. The page is perceivable — is it in a language and in conventions the reader understands, or can the browser get it there?
  5. Can I use it? Usability. The reader perceives and understands the words — can they accomplish the task they came for? Conventions, feedback, logic, and expectations.
  6. Do I want it? Acceptance. The task is possible — is the experience one they'd choose again? Trust, satisfaction, personal and cultural fit.

Wrapped around all six: how would we know? Verification. The web is a highly variable, shared-ownership medium; even a page built right fails somewhere, for someone, today. Monitoring is where the client-side story hands off to the server-side one.

Where your choices meet their questions

User rung → technical stages and choices that decide it
User questionPipeline stagesChoices that hold it up — or drop it
Is it there?URL → DNS → connection → TLS → responseDomain and certificate upkeep, hosting, link hygiene, every third-party dependency you let block the page
In time?Response → parse → renderPayload weight, render-blocking resources, client-side rendering bets, image and font strategy
Can I perceive and operate it?Parse → accessibility tree → assistive techSemantic elements, alt text, labels, keyboard support, focus, contrast, honoring user preferences
Can I read it?DOM text nodes → translation layerlang, real text, complete phrases, logical properties, unambiguous values
Can I use it?Interaction → application logicConventions, feedback, error handling, task flow, predictability
Do I want it?The whole experience, over timeTone, craft, honesty, cultural awareness, respect for the person's time and attention
How would we know?Beacons → collection → analysisField measurement, error reporting, analytics — the bridge to the server-side course

The canyon

The gap between developer experience and user experience is a Grand Canyon of online failure. Choices made for the builder's comfort — a framework that renders nothing until its bundle executes, a component library that emits <div> soup, a build pipeline that ships four megabytes because it was easy — fail users on rungs the builder never tests. The build works on the builder's machine, on the builder's fiber, in the builder's language, with the builder's eyes and hands. Almost nobody else is that user.

This series exists to make the canyon visible. Each lesson pairs the concept with a demo you can break with your own hands: the same store, built with the grain and against it, viewed through one rung at a time.

The series

  1. PrequelVague but Exciting

    Start here. A seven-minute narrated film on where the web came from: CERN in 1989, the three inventions every page still rests on (URL, HTML, HTTP), and what the web was built to be.

  2. IntroWho Fell Off the Ladder?

    A six-minute narrated film: eight people open the same store in the same second, and the ladder decides who gets to buy the fleece.

  3. FilmThe Localhost Effect

    A twelve-minute narrated film on the client-server model: who asks, what the network does, what the server sends back, and why your own laptop is the least representative place to test.

  4. FilmBefore the First Byte

    A seven-minute narrated film: the round trips a page pays before its first byte arrives. The address-bar guess, DNS, the route, the TCP and TLS handshakes, the request and its redirect, and how each step fails.

  5. ShortWho Reads Which Part?

    A three-minute aside: each part of a URL has a different reader, from the browser and DNS to the server, and the fragment never leaves your machine.

  6. FilmOne URL, Seventy Requests

    A nine-minute narrated film: a page is a tree of URLs, each fetched over HTTP and labelled with a MIME type, and the shape of that tree decides how the page loads.

  7. Short304

    A two-minute aside on the request the browser makes only to ask whether its copy is still good, and the three answers a response can give to “keep it?”.

  8. FilmThree Things In, Three Things Out

    A seven-minute narrated film that goes deeper: every request and response is a first line, headers, and a body. Who writes the Content-Type label, what happens when it is wrong, and how to add a type or a scheme of your own.

  9. FilmEverything You Embed

    A six-minute narrated film: what a page takes on when it loads someone else's file. Slow, blocked, missing, watching and hostile resources on Demo Company's pages, and the line or two of HTML that answers each.

  10. 01Availability: is it there, and did it arrive in time?

    Rungs one and two, with a fragile and a resilient store you can sabotage in DevTools, and the films A Budget for Patience and Engineering for the Extreme?.

  11. 02Accessibility: can they perceive and operate it?

    A failure catalog organized by ability, with broken and fixed stores to test by keyboard, emulator, and screen reader.

  12. 03Internationalization: can they read it?

    What the browser's translator can and can't reach, a store to translate into German and Arabic before and after the fix, and how to opt out honestly.

  13. 04Usability: can they use it?

    Where a technically flawless page still fails the task.

  14. 05Acceptance: do they want it?

    Trust, satisfaction, and cultural fit at the top of the ladder.

  15. 06Verification: how would we know?

    Monitoring the whole ladder, and the hand-off to the server-side and analytics course.