CSE 134B

Rungs 1 and 2

Availability

Rungs one and two: is it there at all, and did it arrive while the user still cared?

Rung one: can they reach it?

Before a single byte of your careful markup matters, a chain of unglamorous things must all go right. Each is a way to be simply, totally gone:

  • The name. DNS must resolve. Domains expire, records get fat-fingered, resolvers differ by network and country. A domain renewal reminder in spam has taken down larger sites than yours.
  • The lock. TLS certificates expire on a schedule that does not care about your weekend. An expired certificate is a full-screen browser warning most users correctly refuse to click through. Mixed content — an http:// script on an https:// page — gets silently blocked, taking whatever depended on it.
  • The server. Hosting lapses, deploys break, databases fall over, 404s accumulate as content moves without redirects. Link rot is availability failure in slow motion.
  • The strangers. Every third-party dependency — CDN, font host, analytics, tag manager — is another organization you have authorized to take your page down. If their outage can blank your page, your availability is the product of everyone's uptime.
  • The middle. Corporate proxies, national firewalls, DNS filters, captive portals. You don't control these; resilient construction decides how gracefully you degrade when they interfere.

Rung two: did it arrive in time?

Availability has a clock on it. A page that technically responds but needs thirty seconds on a hotel connection is, for that user, down — they left. Perceived availability is decided by construction choices:

  • Weight. Bytes are time. Unoptimized images, megabyte JavaScript bundles, and six font weights are a tax every visitor pays, priced in their bandwidth, not yours. Much of the world is on capped mobile data; your payload has a literal cost.
  • Blocking. A synchronous <script> in <head> halts parsing until it downloads and runs. A slow third party there holds your entire page hostage.
  • The client-rendering bet. A page whose HTML is an empty shell exists only after hundreds of kilobytes of JavaScript download, parse, and execute without error — on every device, every network, every time. That is a bet against availability, placed for developer convenience. HTML that arrives with content in it has already won.
  • Fragile cleverness. Anti-flash hacks like hiding <body> until a script reveals it convert any script failure into a permanently blank page. The cure guarantees the disease.

The exercise: break it yourself

Two versions of the Terra Outfitters landing page. Same appearance on a good connection. Open DevTools and play saboteur — you are simulating an ordinary Tuesday on the real web:

  1. Open the fragile store and the resilient store in two tabs. Both look fine. View source on each: one contains a store, the other contains an empty shell and a prayer.
  2. Kill one file. DevTools → Network tab → reload → right-click each page's one script (app.js on the fragile store, enhance.js on the resilient one) → Block request URL → reload both. The fragile page is now blank, permanently: its content lived in the script and its anti-flash hack hides the body forever. The resilient page loses only its cart counter enhancement.
  3. Slow the world. Unblock, then set throttling to Slow 3G. Watch when each page first shows content, and imagine holding the phone.
  4. Go dark. Set throttling to Offline and reload. Both fail — availability has layers you don't own. Note which failure message the user gets, and that the browser's, not yours, is all they see.
  5. Count the fragile page's external dependencies. Each one is a stranger holding a plug.
What the fragile page bets, line by line
Construction choiceThe betWhen it loses
Blocking third-party script in <head>Their servers are always fastPage hangs white while a stranger's DNS times out
Empty <body>, JS-rendered contentThe script always arrives and runsBlocked, cached-stale, errored, or slow script = no page
body { opacity: 0 } until JS revealsThe reveal always executesAny failure above = blank page even if content existed
No <noscript>, no fallbackEveryone runs JS, alwaysThe user gets nothing and no explanation

Then read the resilient page's source and notice what it cost: nothing. Content in the HTML, one deferred enhancement, system fonts. Resilience was the cheaper option.

Next rung

The page is there and it arrived. Now it meets a person — possibly one who cannot see it, hear it, or hold a mouse. Continue to Accessibility: can they perceive and operate it?