The Perfect Article

Same article for everyone. Build the best possible way to read it.

The brief

Everyone gets the same article. Your job is to build the best possible place to read it: typography, hierarchy, pacing, and the small interactions that make long-form reading feel effortless. There are no content decisions to hide behind. The reading experience is the product.

Fixed inputs

The attached article, the-latency-budget.md, is the exact content for every entry. Use all of it, word for word, including the code blocks and footnotes. You may not rewrite, cut, or extend it. It renders below the brief, and you can download it as a file to build against.

Required features

These are the floor. Hit all of them or you're not in the running.

Renders the supplied article in full, exactly as written
A table of contents and a reading progress indicator
Code blocks and footnotes rendered as first-class citizens, not afterthoughts
Text highlighting or annotation the reader can actually use
Fully keyboard navigable and accessible, on desktop and mobile

Bonus

The required list makes builds comparable. Everything above it is where you win.

Typography choices that make people screenshot a paragraph
Footnotes, references, or code that reveal in place instead of yanking the reader away
A detail nobody else thought of: time remaining, a margin for notes, print styles that actually work
Anything that makes a voter read the whole article twice

Constraints

Must be deployed to a public URL.
Repo must be public.
Built during the build window. Commit history is the receipt.

How it's judged

Community vote during the voting window. One upvote per submission. Top 3 take a trophy. Voters are asked to reward reading experience, typography, visual hierarchy, responsiveness, accessibility, interaction quality, and polish.

the-latency-budget.md3.1 KB

The Latency Budget

Every interface spends time the way a project spends money. Some of it buys real work: a query, a render, a network round trip. The rest is overhead the user feels but never sees itemized. Fast products are not the ones that spend nothing. They are the ones that know what they are buying.¹

Three thresholds

Human perception of delay is not linear. It has cliffs, and half a century of research keeps finding the same three.²

Threshold	What the user feels
100 ms	Instant. The interface feels like a direct extension of the hand.
1 second	A pause. Flow survives, but the user notices the seam.
10 seconds	A wait. Attention leaves and must be re-earned.

The practical rule: keep interactions under 100 milliseconds, keep transitions under a second, and never make anyone sit through ten seconds without something honest to look at.

Spending it badly

The classic mistake is spending latency where it shows and saving it where it does not. A search box that fires a request on every keystroke wastes its budget on work the user is about to invalidate:

input.addEventListener("input", (e) => {
  search(e.target.value); // fires eight times while typing "latency"
});

Debouncing does not make the network faster. It stops paying for results nobody will read:

let timer;
input.addEventListener("input", (e) => {
  clearTimeout(timer);
  timer = setTimeout(() => search(e.target.value), 150);
});

The 150 milliseconds is over the instant threshold on purpose. The wait is invisible because it overlaps with typing, which is the second half of the discipline: latency hidden inside the user's own activity is free.

Spending it well

The fastest request is the one you started before the user asked for it.

Optimistic UI is the same trade in the other direction. When the user acts, show the result immediately and reconcile in the background. The click costs nothing; the rare rollback costs an apology. For actions that succeed 99 percent of the time, that is a good price.³

The budget metaphor earns its keep in review. "This modal takes 400 milliseconds to open" is an observation. "This modal spends four times our interaction budget and buys nothing visible" is an argument, and arguments are what get fixed.

What to take home

Measure what the user feels, not what the server does. Put the spend where perception has cliffs. And when a delay cannot be removed, be honest about it: progress that moves, skeletons that match the layout, words that say what is happening. Users forgive slow. They do not forgive being lied to.

Footnotes

The framing borrows from performance budgets in build tooling, where a build fails if it ships more bytes than the budget allows. Time deserves the same discipline as bytes. ↩
The 0.1, 1, and 10 second thresholds trace back to Robert Miller's 1968 work on conversational transactions, later popularized by Jakob Nielsen in Usability Engineering (1993). ↩
The Doherty threshold, from a 1982 IBM paper, made a related economic case: below 400 milliseconds of system response, productivity rises faster than response time falls. ↩