How fast is fast enough.

Picture a rider on a commuter train with Cobbleway open on a mid-range phone. She taps Add to basket on a chain. If the basket badge changes before her thumb has left the glass, the shop feels like an object she is handling. If nothing moves for half a second she wonders whether the tap registered, and often taps again. If the category page takes three seconds to show resin pads after she picks the filter, she has already glanced out of the window, and part of her attention has to find its way back.

Those three moments sit on three different limits of human perception, and they have been remarkably stable for half a century. Robert Miller analysed how long people tolerate a terminal's reply in 1968; Card, Robertson and Mackinlay built on perception research for their 1991 information workspace; Jakob Nielsen folded both into three round numbers in 1993: about 0.1 s, about 1 s and about 10 s. Google's RAIL model later restated them for browsers. The numbers are approximate, and they are about people, not networks: a fibre connection does not make a person notice delays any later.

The design consequence is the useful part. Each limit tells you what the interface owes the person while the work is still running. Inside 100 ms the result itself can be the feedback. Up to a second the screen must at least admit the request was heard. Beyond that it must show that progress is happening, and beyond ten seconds it must let the person do something else. So a performance requirement does not say "the product page is fast". It lists the interactions and gives each a band.

Interactions are not equal, and the person's expectation depends on what they think they did. Touching a control is direct manipulation: the rider expects the thing under her finger to react as a physical switch would, so it belongs to the 100 ms band, and anything that moves under her finger belongs to the frame. Asking for something new, a page, a filtered list, a search, is a request: she knows the shop has to go and get it, so the 1 s band applies, as long as the screen admits the request at once. Work she knows is heavy, paying, uploading, generating a report, is a job: the 10 s band applies, and past it the interface has to stop holding her hostage.

Most real interactions are a mix. Add to basket is a tap (the button must react in 100 ms) that starts a request (the basket must be right within a second or so). Writing the two halves down separately is what makes the requirement testable: "the button shows it was pressed in the next frame" and "the basket badge shows the new count within 1 s at p75" are two different promises, measured from the same tap.

The screen only changes when the browser paints a frame. At 60 Hz a frame comes every 1000 / 60 = 16.7 ms; on the 120 Hz screens now common on phones it is 1000 / 120 = 8.3 ms. The browser needs part of each frame for style, layout and paint, so MDN and RAIL both suggest your own work per frame stays near 10 ms on a 60 Hz screen. How the event loop picks when to paint is taught in the browser-rendering topic on the frame and the event loop; here it matters for two reasons.

First, the 100 ms limit is about six frames at 60 Hz. RAIL turns that into a rule of thumb: finish handling input within 50 ms, so that, together with whatever task was already running when the tap arrived, the change still reaches the screen inside 100 ms. Second, while something moves, the budget is the frame itself, not 100 ms: a drag that lags by three frames feels like dragging through mud even though 50 ms sounds fast.

Measured time runs from the tap to the moment the work is truly done. Perceived time runs from the tap to the moment the rider believes it is done, or at least believes it is under way. The two can differ by most of a second, and the gap is a design choice, not an accident. Three levers widen it in your favour.

• Optimistic update: show the expected result at once and reconcile when the server answers. It fits writes that almost always succeed and are cheap to undo, like a basket line or a like. The snapshot, reconcile and rollback machinery belongs to the data-retrieval topic on mutations; what matters here is that it moves a request-sized wait into the 100 ms band.
• Placeholders that hold the shape: a skeleton, or the previous content kept on screen but dimmed. The rider sees where the answer will appear and keeps her place. A skeleton must reserve exactly the space of the real content, or the swap becomes a layout shift.
• Progressive rendering: show the first useful part (the product title, price and photo) before the rest (reviews, related parts). The page enters the 1 s band for what matters even if the whole page takes longer.

None of these make the network faster, and none of them excuse a slow server: an optimistic basket that is wrong one time in twenty feels broken, and a skeleton shown for five seconds is still a five-second wait. They decide which band the rider experiences while the real work catches up.

List the interactions a rider actually performs on the three pages that matter, home, category and product, plus checkout. For each, write the band, the target and how it is measured (at p75 on the reference device, a mid-range Android phone on 4G, chosen in the device topic), and the feedback the screen shows inside the 100 ms limit whatever the network does. The page-load numbers themselves are Core Web Vitals and live in that topic; this table covers what happens after the page is up.