A medium built to surprise you
Every lesson in this series ended with a page that worked on your machine. That sentence is the problem. The web is the most variable delivery medium ever built: your page will run on devices you've never seen, over networks you can't imagine, in browsers with settings you didn't test, through extensions that rewrite your DOM, translators that wrap your text nodes, and assistive technology consuming a tree you can't see — owned along the way by DNS registrars, certificate authorities, CDNs, ad networks, and the user's phone plan. Shared ownership means no one party — including you — can promise the experience. You can only build with the grain, then watch.
And the ladder fails silently upward: the user who can't load, perceive, or use your page doesn't file a report. They leave. Their absence is invisible in every tool except measurement designed to catch it.
Lab versus field
Two kinds of knowing, and you need both:
- Lab: your machine, controlled conditions. DevTools, Lighthouse, axe, validators, the throttling and emulation you used all series. Reproducible, diagnostic, available before launch — and only ever describes the one environment you ran it in.
- Field: real users' sessions, measured from inside the page and beaconed home — real user monitoring (RUM). Messy, anonymous in aggregate, and the only source of truth about what actually happened. Chrome feeds field Core Web Vitals into the public CrUX dataset; your own beacons can capture far more.
The lab told you the fragile store could blank out when a script fails. Only the field tells you it blanked for 4% of Tuesday's visitors, all on one mobile carrier.
A signal for every rung
| Rung | Field signals | Lab checks |
|---|---|---|
| Is it there? | Uptime and synthetic probes from several regions; DNS and certificate expiry monitoring; error-rate alerts; 404 logs | Link checkers; dependency inventory |
| In time? | Field Core Web Vitals — LCP, CLS, INP — segmented by device, network, and geography; abandonment before first paint | Lighthouse; throttled loads; payload budgets in CI |
| Perceive and operate? | Partially resistant to automation — a11y is verified by testing with assistive tech and with disabled users. Field hints: keyboard-use patterns, zoom levels, reduced-motion share | axe and Lighthouse (they catch well under half); manual keyboard and screen reader passes |
| Read it? | Visitor language and locale distribution versus bounce rate; traffic arriving via translation services | The i18n lesson's translate-it-yourself drill |
| Use it? | Funnels and drop-off by step; task completion; form-error frequency; rage clicks; support tickets | Moderated usability tests — the hallway lab from the usability lesson |
| Want it? | Return rate, retention, refunds, review sentiment, survey scores — the slow metrics dark patterns flatter-then-poison | The acceptance lesson's cross-audience fit review |
The exercise: instrument the store
The series includes verify.js — a working, dependency-free field instrument small enough to read in one sitting. It observes navigation timing, LCP, CLS, slowest interaction, and JavaScript errors, then displays the beacon payload a real site would transmit.
- Add it to both availability demos:
<script src="verify.js" defer></script>. It sits in the same folder as the demos, so that path works as written. Either edit the hosted pages with DevTools Local Overrides (Sources → Overrides), or save each demo, its script, andverify.jsinto one folder and serve it. Reload, open the panel, click around. Compare reports. - Throttle to Slow 3G and reload each. Watch LCP tell the rung-two story in one number.
- Block
app.json the fragile store. Note what the panel shows — and the deeper catch: a page that never runs JavaScript never sends its own beacon. Discuss: how do you detect the visitors your instrument can't see? (Server logs. Synthetic probes. The other course.) - Read the source. Find the commented
navigator.sendBeacon("/collect", payload)line. Everything before it is this course; everything after — receiving, storing, aggregating, dashboarding, alerting — is the server-side and analytics course. Same payload, other side of the wire. - Closing discussion: which of the six rungs would each team member own at a real company — and who owns the ones nobody claimed? That unclaimed middle is the canyon from lesson one, seen from the operations side.
Closing the loop
The series began with a person typing a URL and a ladder of questions they never consciously ask. It ends with the discipline of listening for their answers. Build with the grain, at every rung — then verify, because the web's variability guarantees that somewhere, for someone, today, one of your rungs is failing. The difference between a professional and a hobbyist is not that the professional's pages never break. It's that the professional finds out.