1 00:00:01,200 --> 00:00:03,694 Every bridge has a load rating. 2 00:00:03,905 --> 00:00:08,466 Every elevator has a weight limit posted by the door. 3 00:00:08,666 --> 00:00:17,093 Engineers write the limit down before they build, because a limit is what lets them say yes or no to a design. 4 00:00:17,293 --> 00:00:20,275 Web developers skip that step all the time. 5 00:00:20,300 --> 00:00:22,841 We say the site should be fast. 6 00:00:22,866 --> 00:00:27,670 But fast is an adjective, and you can't test an adjective. 7 00:00:27,870 --> 00:00:32,442 To build for a network you don't control, you need numbers. 8 00:00:32,584 --> 00:00:36,808 Google's RAIL model is one good set of them. 9 00:00:37,508 --> 00:00:40,258 RAIL's numbers don't come from servers. 10 00:00:40,283 --> 00:00:42,545 They come from people. 11 00:00:42,745 --> 00:00:49,082 Motion needs a new frame about every 16 ms, or it stutters. 12 00:00:49,282 --> 00:00:53,262 A response within 100 ms feels instant. 13 00:00:53,345 --> 00:00:58,870 Up to a second still feels like the task is flowing. 14 00:00:59,070 --> 00:01:02,447 After about a second, attention wanders. 15 00:01:02,530 --> 00:01:06,522 After ten, many people give up and leave. 16 00:01:06,722 --> 00:01:11,666 Those limits are the same on your laptop and on a five-year-old phone. 17 00:01:12,063 --> 00:01:13,942 The hardware isn't. 18 00:01:14,642 --> 00:01:22,140 Response: when someone taps or types, show a visible result within 100 ms. 19 00:01:22,340 --> 00:01:27,272 RAIL asks you to finish handling the input in 50 ms. 20 00:01:27,669 --> 00:01:36,061 The other half is slack, because the main thread may already be busy when the tap arrives. 21 00:01:36,261 --> 00:01:39,616 If the real work takes longer, respond anyway. 22 00:01:39,616 --> 00:01:44,409 Press the button down, show progress, say what's happening. 23 00:01:45,109 --> 00:01:50,099 Animation: produce each frame in 10 ms. 24 00:01:50,300 --> 00:02:00,886 At sixty frames a second, a frame lasts about 16 ms, and the browser needs roughly six of those for its own work. 25 00:02:00,912 --> 00:02:03,046 That leaves you ten. 26 00:02:03,246 --> 00:02:09,908 That budget covers scrolling and dragging too, not just the things you animate on purpose. 27 00:02:10,608 --> 00:02:17,920 Idle: use quiet moments for deferred work, in chunks of 50 ms or less. 28 00:02:18,120 --> 00:02:24,736 Small chunks keep the main thread free, so the next tap still gets its answer on time. 29 00:02:24,936 --> 00:02:29,834 Load what the person needs first, and fetch the rest while they read. 30 00:02:30,534 --> 00:02:41,515 Load: be usable within five seconds on a first visit, measured on a mid-range phone over a slow 3G connection. 31 00:02:41,715 --> 00:02:48,935 Repeat visits get two seconds, because by then something useful should be cached. 32 00:02:49,134 --> 00:02:51,015 Notice the test device. 33 00:02:51,015 --> 00:02:53,544 Not your laptop on campus Wi-Fi. 34 00:02:53,755 --> 00:03:00,394 A mid-range phone on a slow network, which is much closer to a typical visitor. 35 00:03:01,094 --> 00:03:03,356 RAIL is a starting point. 36 00:03:03,381 --> 00:03:06,549 Your budget should come from your own visitors. 37 00:03:06,749 --> 00:03:10,996 Who uses your site, on what devices and networks? 38 00:03:11,021 --> 00:03:19,402 Turn that into limits: how much the page may weigh, how much JavaScript it may run, how long it may take. 39 00:03:19,602 --> 00:03:23,188 The persona tool in this course shows the arithmetic. 40 00:03:23,271 --> 00:03:28,679 Pick a visitor, set a page weight, and see how many seconds it costs them. 41 00:03:28,879 --> 00:03:30,038 Then measure. 42 00:03:30,342 --> 00:03:36,435 Test in the lab with throttling, and in the field with data from real visits. 43 00:03:36,576 --> 00:03:40,325 A budget you never check is only a wish. 44 00:03:40,525 --> 00:03:49,091 This is the performance law in practice: send less data, less often, from nearby, and only when needed. 45 00:03:49,791 --> 00:03:53,272 RAIL was last updated in 2020. 46 00:03:53,355 --> 00:04:01,562 Today, Google points developers to Core Web Vitals, which measure the same concerns from real visits. 47 00:04:01,762 --> 00:04:08,111 Largest Contentful Paint, or LCP, asks when the main content showed up. 48 00:04:08,252 --> 00:04:11,768 Good is within 2.5 seconds. 49 00:04:11,968 --> 00:04:19,199 Interaction to Next Paint, or INP, asks how quickly the page responds to input. 50 00:04:19,410 --> 00:04:24,017 Good is 200 ms or less. 51 00:04:24,217 --> 00:04:31,483 Cumulative Layout Shift, or CLS, asks whether things jump around while you read. 52 00:04:31,880 --> 00:04:35,663 Good is 0.1 or less. 53 00:04:35,863 --> 00:04:41,945 Each is judged at the 75th percentile, so a good typical visit isn't enough. 54 00:04:42,156 --> 00:04:45,683 Three out of four visits have to meet the mark. 55 00:04:45,883 --> 00:04:47,530 The names changed. 56 00:04:47,555 --> 00:04:53,010 The idea didn't: pick numbers that match people, then check them. 57 00:04:53,709 --> 00:04:58,212 RAIL gives us a quantitative view of time and performance. 58 00:04:58,295 --> 00:05:01,068 There's a qualitative view as well. 59 00:05:01,268 --> 00:05:03,739 The Greeks had two words for it. 60 00:05:04,043 --> 00:05:08,580 Chronos is clock time, the kind a stopwatch measures. 61 00:05:08,884 --> 00:05:12,946 Kairos is time as you live it. 62 00:05:13,146 --> 00:05:18,229 If this film feels slow to you, you already understand kairos. 63 00:05:18,429 --> 00:05:22,131 User experience is never purely objective. 64 00:05:22,272 --> 00:05:30,385 Clock time can be slow and still leave someone satisfied, or fast and still leave them frustrated. 65 00:05:30,586 --> 00:05:32,848 Don't use that as an excuse, though. 66 00:05:33,059 --> 00:05:37,388 Engineers need clarity, and RAIL gives it to us. 67 00:05:38,087 --> 00:05:40,488 Start with RAIL as the goal. 68 00:05:40,572 --> 00:05:46,235 Use its hard numbers to drive the details and to define a budget. 69 00:05:46,436 --> 00:05:51,902 A budget turns an argument about taste into a question with an answer. 70 00:05:52,299 --> 00:05:55,513 Does this feature fit, or not? 71 00:05:55,713 --> 00:05:58,521 Sometimes the answer is to cut something. 72 00:05:58,662 --> 00:06:01,040 Sometimes it's to build it differently. 73 00:06:01,251 --> 00:06:04,744 Either way, you decide on purpose. 74 00:06:04,944 --> 00:06:07,264 Your visitors will never see your budget. 75 00:06:07,347 --> 00:06:10,538 They'll just notice that the page kept up with them.