# A Budget for Patience — narration script

Runtime 6:15. Timecodes are when each chapter starts; the film's animation is keyed to these cue times, so a recorded voice-over should keep each line near its timecode.

## 0:00 · Fast is not a number

- `0:01` Every bridge has a load rating. Every elevator has a weight limit posted by the door.
- `0:08` Engineers write the limit down before they build, because a limit is what lets them say yes or no to a design.
- `0:17` Web developers skip that step all the time. We say the site should be fast. But fast is an adjective, and you can't test an adjective.
- `0:27` To build for a network you don't control, you need numbers. Google's RAIL model is one good set of them.

## 0:37 · People set the clock

- `0:37` RAIL's numbers don't come from servers. They come from people.
- `0:42` Motion needs a new frame about every 16 ms, or it stutters.
- `0:49` A response within 100 ms feels instant. Up to a second still feels like the task is flowing.
- `0:59` After about a second, attention wanders. After ten, many people give up and leave.
- `1:06` Those limits are the same on your laptop and on a five-year-old phone. The hardware isn't.

## 1:14 · R is for Response

- `1:14` Response: when someone taps or types, show a visible result within 100 ms.
- `1:22` RAIL asks you to finish handling the input in 50 ms. The other half is slack, because the main thread may already be busy when the tap arrives.
- `1:36` If the real work takes longer, respond anyway. Press the button down, show progress, say what's happening.

## 1:44 · A is for Animation

- `1:45` Animation: produce each frame in 10 ms.
- `1:50` At sixty frames a second, a frame lasts about 16 ms, and the browser needs roughly six of those for its own work. That leaves you ten.
- `2:03` That budget covers scrolling and dragging too, not just the things you animate on purpose.

## 2:10 · I is for Idle

- `2:10` Idle: use quiet moments for deferred work, in chunks of 50 ms or less.
- `2:18` Small chunks keep the main thread free, so the next tap still gets its answer on time.
- `2:24` Load what the person needs first, and fetch the rest while they read.

## 2:30 · L is for Load

- `2:30` Load: be usable within five seconds on a first visit, measured on a mid-range phone over a slow 3G connection.
- `2:41` Repeat visits get two seconds, because by then something useful should be cached.
- `2:49` Notice the test device. Not your laptop on campus Wi-Fi. A mid-range phone on a slow network, which is much closer to a typical visitor.

## 3:00 · Make the numbers yours

- `3:01` RAIL is a starting point. Your budget should come from your own visitors.
- `3:06` Who uses your site, on what devices and networks? Turn that into limits: how much the page may weigh, how much JavaScript it may run, how long it may take.
- `3:19` The persona tool in this course shows the arithmetic. Pick a visitor, set a page weight, and see how many seconds it costs them.
- `3:28` Then measure. Test in the lab with throttling, and in the field with data from real visits. A budget you never check is only a wish.
- `3:40` This is the performance law in practice: send less data, less often, from nearby, and only when needed.

## 3:49 · Today's scoreboard

- `3:49` RAIL was last updated in 2020. Today, Google points developers to Core Web Vitals, which measure the same concerns from real visits.
- `4:01` Largest Contentful Paint, or LCP, asks when the main content showed up. Good is within 2.5 seconds.
- `4:11` Interaction to Next Paint, or INP, asks how quickly the page responds to input. Good is 200 ms or less.
- `4:24` Cumulative Layout Shift, or CLS, asks whether things jump around while you read. Good is 0.1 or less.
- `4:35` Each is judged at the 75th percentile, so a good typical visit isn't enough. Three out of four visits have to meet the mark.
- `4:45` The names changed. The idea didn't: pick numbers that match people, then check them.

## 4:53 · Yet the score doesn't matter?

- `4:53` RAIL gives us a quantitative view of time and performance. There's a qualitative view as well.
- `5:01` The Greeks had two words for it. Chronos is clock time, the kind a stopwatch measures. Kairos is time as you live it.
- `5:13` If this film feels slow to you, you already understand kairos.
- `5:18` User experience is never purely objective. Clock time can be slow and still leave someone satisfied, or fast and still leave them frustrated.
- `5:30` Don't use that as an excuse, though. Engineers need clarity, and RAIL gives it to us.

## 5:37 · Constraints bring clarity

- `5:38` Start with RAIL as the goal. Use its hard numbers to drive the details and to define a budget.
- `5:46` A budget turns an argument about taste into a question with an answer. Does this feature fit, or not?
- `5:55` Sometimes the answer is to cut something. Sometimes it's to build it differently. Either way, you decide on purpose.
- `6:04` Your visitors will never see your budget. They'll just notice that the page kept up with them.