WEBVTT 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.