1 00:00:01,200 --> 00:00:05,029 Imagine opening your web app from Antarctica. 2 00:00:05,229 --> 00:00:07,249 An IT worker for the U.S. 3 00:00:07,249 --> 00:00:18,811 Antarctic Program, who writes online as brr, spent fourteen months there: first at McMurdo Station on the coast, then at the South Pole. 4 00:00:19,011 --> 00:00:29,203 Afterward, brr wrote about what the internet is like at the bottom of the world, and what our software does to the people who use it there. 5 00:00:29,403 --> 00:00:34,486 This film follows that article, Engineering for Slow Internet. 6 00:00:34,697 --> 00:00:38,341 The stories and the numbers are theirs. 7 00:00:39,041 --> 00:00:51,694 At McMurdo, nearly a thousand people, plus science projects and station operations, shared links with a combined speed of a few dozen megabits per second. 8 00:00:51,894 --> 00:00:57,442 That's less than many single homes have, split a thousand ways. 9 00:00:57,641 --> 00:01:00,379 Every request travels by satellite. 10 00:01:00,683 --> 00:01:06,010 A round trip to the United States takes about 750 ms. 11 00:01:06,407 --> 00:01:10,991 On home fiber, a nearby server answers in a few. 12 00:01:11,191 --> 00:01:20,547 Speeds at a single laptop ranged from a couple of kilobits per second to 2 Mbps on a really good day. 13 00:01:20,747 --> 00:01:31,217 At the Pole, the internet exists only while the satellites are above the horizon, and that window moves about four minutes earlier every day. 14 00:01:31,417 --> 00:01:38,265 Add heavy packet loss, and sometimes a complete fifteen-second dropout every few minutes. 15 00:01:38,965 --> 00:01:42,736 You might think this is a problem for a few hundred scientists. 16 00:01:42,761 --> 00:01:44,188 It isn't. 17 00:01:44,388 --> 00:02:04,610 Ships at sea, remote research sites, rural customers with poor wireless service, concertgoers at a venue with 10s of thousands of people hitting the same cell towers, people still forced to settle for dial-up, all these folks live with some version of brr's link. 18 00:02:04,811 --> 00:02:09,221 Remember Ana on crowded hotel Wi-Fi, from the ladder film? 19 00:02:09,618 --> 00:02:15,235 Same problem; fortunately, hers is just temporary. 20 00:02:15,935 --> 00:02:24,316 One enterprise collaboration app needed nearly 20 MB of JavaScript just to show its main screen. 21 00:02:24,515 --> 00:02:27,369 Worse, it had a built-in deadline. 22 00:02:27,580 --> 00:02:34,707 If loading didn't finish in time, the app gave up and sent the user to an error page. 23 00:02:34,907 --> 00:02:37,192 It took hours of retries. 24 00:02:37,496 --> 00:02:48,071 The load that finally worked made 809 requests and moved 51.4 MB over twenty-six and a half minutes. 25 00:02:48,271 --> 00:03:00,645 All of it so that brr could send one message: a 1.8 KB request carrying six bytes of text. 26 00:03:00,845 --> 00:03:09,318 The app worked fine on its developers' machines in their world; out in the harsh real world, it failed. 27 00:03:10,018 --> 00:03:13,813 Many apps assume every request finishes quickly. 28 00:03:14,209 --> 00:03:19,838 One chat app gave its connection ten seconds to set up. 29 00:03:20,039 --> 00:03:25,552 Over a congested satellite link, the handshakes alone could take longer than that. 30 00:03:25,693 --> 00:03:33,481 So the app failed, waited, and failed again, while the network was up the whole time. 31 00:03:33,681 --> 00:03:36,477 A competing chat app kept working. 32 00:03:36,688 --> 00:03:46,659 It tried more than one way to connect, reused its connections, and stretched its timeouts to fit the network it actually had. 33 00:03:47,359 --> 00:03:49,702 Then there are updates. 34 00:03:49,844 --> 00:03:55,902 Minor operating system patches ran from half a gigabyte to one and a half. 35 00:03:56,206 --> 00:03:59,548 Major upgrades could top six. 36 00:03:59,748 --> 00:04:06,875 Many built-in downloaders had no pause button, no progress number, and no way to resume. 37 00:04:07,178 --> 00:04:12,680 Lose the connection, and the download started over from zero. 38 00:04:12,879 --> 00:04:20,934 Some installers even fetched gigabytes more in the middle of installing, long after the download seemed done. 39 00:04:21,135 --> 00:04:33,196 The best one brr found was Microsoft's updater for Office on the Mac: pause, cancel, progress, speed, time remaining, and graceful resumption. 40 00:04:33,488 --> 00:04:35,646 Are you surprised it was Microsoft? 41 00:04:36,019 --> 00:04:40,987 Brand reputation isn't always tied to engineering prowess. 42 00:04:41,686 --> 00:04:44,145 The core advice fits in one line. 43 00:04:44,356 --> 00:04:51,088 If you can tell that bytes are flowing, and they are, leave them alone, no matter how slow. 44 00:04:51,288 --> 00:04:56,696 When a request does fail, wait longer before the next try, not less. 45 00:04:56,780 --> 00:05:02,501 Find out what's actually broken, and tell the person what's happening. 46 00:05:02,702 --> 00:05:14,705 Break big transfers into small pieces that can resume, and keep a plain download link for anyone who'd rather use a tool that can. 47 00:05:14,905 --> 00:05:23,518 The bar, brr says, is the web browser itself, which already pauses, resumes, and shows its progress. 48 00:05:24,217 --> 00:05:34,130 Everything in this film comes back to the Performance Law: send less data, less often, from nearby, and only when needed. 49 00:05:34,330 --> 00:05:37,927 Twenty megabytes of JavaScript breaks the first part. 50 00:05:38,010 --> 00:05:46,286 A deadline that throws away finished work breaks the second, because the next try sends it all again. 51 00:05:46,487 --> 00:05:49,424 Most of your visitors aren't at the South Pole. 52 00:05:49,424 --> 00:05:55,564 But on any given day, some of them are on a link that behaves like it. 53 00:05:55,764 --> 00:06:01,730 Good engineers build not just for the happy path, but account for extremes. 54 00:06:02,126 --> 00:06:15,197 Considering access from the bottom of the world is truly an extreme, but know that if you can make something work under those conditions, it will absolutely fly in better ones.